The one-line pipeline
Four stages, in order
Every feature moves through the same four stages. You never skip ahead. Each stage makes the next one cheaper and safer.
Agree on the plan
Claude interviews you until the plan has no fuzzy spots left.
Write it down
The interview becomes one clean document everyone can trust.
Chop it up
The spec gets sliced into small, complete, buildable pieces.
Build each piece fresh
One fresh chat per ticket. Tests first, then commit.
The front door
Not sure where to start? Ask Matt.
/ask-matt looks at what you are trying to do and routes you to the right skill. It is the front desk of the whole system.
No single skill runs the whole pipeline for you, and that is on purpose. The human makes the decisions. The agent does the work. Every stage ends with you looking at the result before the next stage begins.
The main highway
Idea to shipped feature
This is the standard route. Most work should follow these five steps.
-
1
/grill-with-docs: the interviewClaude interviews you one question at a time, and every question comes with a recommended answer. It keeps going until the plan has no fuzzy spots. It looks up facts in the codebase itself, so it only asks you about real decisions, never things it could read on its own.
Along the way it saves your project vocabulary in
CONTEXT.mdand records big decisions as ADRs. Nothing gets built until you both confirm you share the same picture. If there is no codebase yet, use/grill-meinstead. It is the same interview without the code lookups.Prototype detour. Some questions need a runnable answer, like "does this UI feel right?" Use/handoffto save the chat to a file, open a fresh chat, build a throwaway version with/prototype, then/handoffthe answer back into the interview. -
2
/to-spec: one clean documentTurns the finished interview into a single spec: the problem, the solution, a long list of user stories, the decisions you made, a testing plan, and a clear statement of what is out of scope.
-
3
/to-tickets: tracer bulletsChops the spec into "tracer bullet" tickets. Each ticket cuts one thin but complete path through the whole app, from the database to the screen, with tests included. Each one is small enough for a single fresh chat, and each one lists which other tickets block it.
-
4
/implement: one fresh chat per ticketOpen a brand new chat for each ticket. Claude builds test-first with
/tdd(red, green, refactor), runs the full test suite, then reviews its own work with/code-reviewon two axes: does it follow repo standards, and does it match the spec. Then it commits. -
5
Repeat until the ticket list is empty
Each ticket ships a working slice. When the list is done, the feature is done.
Keep grilling through tickets in ONE unbroken chat. Then every /implement starts clean. A fresh chat per ticket keeps context small and sharp, so the agent stays fast and accurate.
Pick your door
Which door do you enter? Wayfinder or Grill
These are two different doors into the same highway, not two steps in a row. You pick one based on how foggy the idea is.
or
Door 1: clear enough
Start at /grill-with-docs
The idea fits in your head, and one chat can settle it. The interview resolves every decision right there, and you roll straight on to the spec.
Door 2: too foggy
Start at /wayfinder
The idea is too big or too foggy for one session: a brand new project, a huge feature, lots of unknowns. Wayfinder writes the unknowns down as investigation tickets on your tracker. You resolve them one at a time across many chats, and each ticket produces a decision, not code. When the fog clears, it merges into the highway at /to-spec, usually skipping the grill step because wayfinding already answered the questions the grill would have asked.
Could you answer Claude's grilling questions today, in one sitting? Yes: grill. No, half your answers would be "I don't know yet": wayfind first.
On-ramps
Different starting points, same highway
Not everything starts as a fresh idea. These three routes merge onto the main highway.
Something is broken
/diagnosing-bugs
Refuses to guess. First it builds a one-command reproduction of the bug, so the failure is provable. Only then does it fix the bug, and it locks the fix in with a regression test.
Reports piling up
/triage
Sorts raw bug reports and feature requests into clean, agent-ready issues. Later, /implement picks them up one at a time.
Huge foggy idea
/wayfinder
For ideas too big for one session. It maps the unknowns as investigation tickets, resolves them one at a time until the path is clear, then merges into /to-spec.
Maintenance and helpers
The support crew
These run beside the highway. They keep the codebase, your context, and your project language in good shape.
Spare moments
/improve-codebase-architecture
Scans for cleanup opportunities. Its findings become new ideas that feed back into the highway.
Need facts
/research
A background agent reads docs and primary sources, then leaves a cited markdown file while you keep working on something else.
Chat getting full
/handoff
The bridge between chats. Saves everything important to a file so a fresh chat can pick up right where the old one stopped.
Always underneath
/domain-modeling and /codebase-design
Vocabulary layers that run under everything else. They keep your project language and module shapes sharp and consistent.
Run /setup-matt-pocock-skills once per project. It asks where tickets should live: GitHub issues or a local tickets.md file. For solo projects, the local file is simplest.
Cheat sheet
Three shortcuts to remember
New idea?
/grill-with-docs
Broken thing?
/diagnosing-bugs
Not sure?
/ask-matt