ask-matt

Name: ask-matt
Author: tt-a1i

16stars3forks

How to install ask-matt?

tt-a1i/matt-skills-with-to-goal/ask-matt

$npx -y skills add tt-a1i/matt-skills-with-to-goal --skill ask-matt

Installs into the current project.

Summary

Ask which skill or flow fits your situation. A router over the skills in this repo.

Files · 1

View on GitHub

SKILL.md

1	# Ask Matt
2
3	You don't remember every skill, so ask.
4
5	A flow is a path through the skills. Most paths run along one main flow, and two on-ramps merge onto it. Everything else is standalone, or a vocabulary layer that runs underneath.
6
7	## The main flow: idea → ship
8
9	The route most work travels. You have an idea and want it built.
10
11	1. `/grill-with-docs` — sharpen the idea by interview. Start here when you have a codebase: it's stateful, retaining what it learns in `CONTEXT.md` and ADRs. (No codebase? Use `/grill-me` — see Standalone. Both run the same `/grilling` primitive; `grill-with-docs` is the one that leaves a paper trail.)
12	2. Branch — can you settle every question in conversation? If a question needs a runnable answer (state, business logic, a UI you have to see), detour through a prototype, bridged by `/handoff` in both directions (see Crossing sessions):
13	- `/handoff` out, then open a fresh session against that file,
14	- `/prototype` to answer the question with throwaway code,
15	- `/handoff` back what you learned, and reference it from the original idea thread.
16	3. Branch — is this a multi-session build?
17	- Yes → `/to-spec` (turn the thread into a spec), then `/to-tickets` to split it into tracer-bullet tickets, each declaring its blocking edges. On a local tracker that's one file per ticket under `.scratch/<feature>/issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed. Run `/to-goal` for the current frontier ticket, then open a fresh session and kick off `/implement` (or paste the goal into a goal loop). Clear context between tickets and regenerate the goal from the new frontier each time. Use `/to-goal --all` only for a persistent harness that can renew context across tickets.
18	- No → `/implement` right here, in the same context window.
19
20	Either way, `/implement` builds each issue by driving `/tdd` internally — one red-green slice at a time — then closes out by running `/code-review`, a two-axis review (Standards + Spec) of the diff, before committing. Reach for `/tdd` on its own when you just want to build a concrete behaviour test-first without a full spec, and `/code-review` on its own whenever you want to review a branch or PR against a fixed point.
21
22	### Context hygiene
23
24	Keep steps 1–3 in one unbroken context window — don't compact or clear until after `/to-tickets` and `/to-goal` — so the grilling, spec, tickets, and execution goal build on the same thinking. Each `/implement` then starts fresh, working from the ticket-scoped goal.
25
26	The limit on this is the [smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone): the window (~120k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `/to-tickets`, don't push on degraded — `/handoff` and continue in a fresh thread.
27
28	## On-ramps
29
30	A starting situation that generates work, then merges onto the main flow.
31
32	- Bugs and requests piling up → `/triage`. It moves issues through triage roles and produces agent-ready issues. Run `/to-goal` on the selected ready issue, then start `/implement` in a fresh session.
33
34	Triage is only for issues you didn't create — bug reports, incoming feature requests, anything that arrives raw. Tickets that `/to-tickets` produced are already agent-ready, so don't triage them. `/to-goal` consumes either kind of ready ticket without repeating triage or interviewing the user.
35
36	- Something's broken → `/diagnosing-bugs`. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression that crept in between two known-good states. It refuses to theorise until it has a tight feedback loop — one command that already goes red on this bug — then fixes with a regression test. Its post-mortem hands off to `/improve-codebase-architecture` when the real finding is that there's no good seam to lock the bug down.
37
38	- A huge, foggy effort — a greenfield project or a huge feature build, too big for one session → `/wayfinder`, the most cognitively demanding flow here. When the way from here to the destination isn't visible yet, it charts a shared map of decision tickets on the issue tracker and resolves them one at a time — producing decisions, not deliverables — until the fog is pushed back and the way is clear. Where `/grill-with-docs` sharpens an idea you can hold in one session, wayfinder is for the idea you can't — and it's slower and denser, so save it for exactly that, never a well-scoped feature.
39
40	When the map clears, it hands off, it doesn't build: merge onto the main flow at `/to-spec`, which collapses

People who liked this also viewed

6 picks

Type

ask-matt

16stars3forks

View on GitHub

How to install ask-matt?

tt-a1i/matt-skills-with-to-goal/ask-matt

$npx -y skills add tt-a1i/matt-skills-with-to-goal --skill ask-matt

Installs into the current project.

Summary

Ask which skill or flow fits your situation. A router over the skills in this repo.

Files · 1

View on GitHub

SKILL.md

1	# Ask Matt
2
3	You don't remember every skill, so ask.
4
5	A flow is a path through the skills. Most paths run along one main flow, and two on-ramps merge onto it. Everything else is standalone, or a vocabulary layer that runs underneath.
6
7	## The main flow: idea → ship
8
9	The route most work travels. You have an idea and want it built.
10
11	1. `/grill-with-docs` — sharpen the idea by interview. Start here when you have a codebase: it's stateful, retaining what it learns in `CONTEXT.md` and ADRs. (No codebase? Use `/grill-me` — see Standalone. Both run the same `/grilling` primitive; `grill-with-docs` is the one that leaves a paper trail.)
12	2. Branch — can you settle every question in conversation? If a question needs a runnable answer (state, business logic, a UI you have to see), detour through a prototype, bridged by `/handoff` in both directions (see Crossing sessions):
13	- `/handoff` out, then open a fresh session against that file,
14	- `/prototype` to answer the question with throwaway code,
15	- `/handoff` back what you learned, and reference it from the original idea thread.
16	3. Branch — is this a multi-session build?
17	- Yes → `/to-spec` (turn the thread into a spec), then `/to-tickets` to split it into tracer-bullet tickets, each declaring its blocking edges. On a local tracker that's one file per ticket under `.scratch/<feature>/issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed. Run `/to-goal` for the current frontier ticket, then open a fresh session and kick off `/implement` (or paste the goal into a goal loop). Clear context between tickets and regenerate the goal from the new frontier each time. Use `/to-goal --all` only for a persistent harness that can renew context across tickets.
18	- No → `/implement` right here, in the same context window.
19
20	Either way, `/implement` builds each issue by driving `/tdd` internally — one red-green slice at a time — then closes out by running `/code-review`, a two-axis review (Standards + Spec) of the diff, before committing. Reach for `/tdd` on its own when you just want to build a concrete behaviour test-first without a full spec, and `/code-review` on its own whenever you want to review a branch or PR against a fixed point.
21
22	### Context hygiene
23
24	Keep steps 1–3 in one unbroken context window — don't compact or clear until after `/to-tickets` and `/to-goal` — so the grilling, spec, tickets, and execution goal build on the same thinking. Each `/implement` then starts fresh, working from the ticket-scoped goal.
25
26	The limit on this is the [smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone): the window (~120k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `/to-tickets`, don't push on degraded — `/handoff` and continue in a fresh thread.
27
28	## On-ramps
29
30	A starting situation that generates work, then merges onto the main flow.
31
32	- Bugs and requests piling up → `/triage`. It moves issues through triage roles and produces agent-ready issues. Run `/to-goal` on the selected ready issue, then start `/implement` in a fresh session.
33
34	Triage is only for issues you didn't create — bug reports, incoming feature requests, anything that arrives raw. Tickets that `/to-tickets` produced are already agent-ready, so don't triage them. `/to-goal` consumes either kind of ready ticket without repeating triage or interviewing the user.
35
36	- Something's broken → `/diagnosing-bugs`. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression that crept in between two known-good states. It refuses to theorise until it has a tight feedback loop — one command that already goes red on this bug — then fixes with a regression test. Its post-mortem hands off to `/improve-codebase-architecture` when the real finding is that there's no good seam to lock the bug down.
37
38	- A huge, foggy effort — a greenfield project or a huge feature build, too big for one session → `/wayfinder`, the most cognitively demanding flow here. When the way from here to the destination isn't visible yet, it charts a shared map of decision tickets on the issue tracker and resolves them one at a time — producing decisions, not deliverables — until the fog is pushed back and the way is clear. Where `/grill-with-docs` sharpens an idea you can hold in one session, wayfinder is for the idea you can't — and it's slower and denser, so save it for exactly that, never a well-scoped feature.
39
40	When the map clears, it hands off, it doesn't build: merge onto the main flow at `/to-spec`, which collapses

People who liked this also viewed

6 picks

Type