Ask Matt

You don't remember every skill, so ask.

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.

The main flow: idea → ship

The route most work travels. You have an idea and want it built.

1. /grill-with-docs — sharpen the idea by interview. Start here whenever you are working in a working directory: it's stateful, retaining what it learns in CONTEXT.md and ADRs. (No working directory? Use /grill-me — see Standalone. Both run the same /grilling primitive; grill-with-docs is the one that leaves a paper trail, which makes it the better of the two whenever a repo is there to leave it in.)
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 (a prototype lives in its own directory, which is exactly what /handoff is for — see Phase boundaries):
   • /handoff out, then open a fresh session against that file,
   • /prototype to answer the question with throwaway code,
   • /handoff back what you learned, and reference it from the original idea thread.
3. Branch — how should implementation cross the context boundary?
   • Small, already clear, no durable spec needed → /implement right here, in the same context window.
   • The approved spec fits one execution session and this thread is coherent → /to-spec, then run /execute-spec-in-fork in Codex App. It creates a same-directory fork, launches /spec-executor, routes decisions back here, validates the returned receipt, and archives a clean completion. Without Codex App task tools or Codex Task Messenger, fork manually from the final SPEC READY, run /spec-executor, and paste its receipt back.
   • Multi-session, parallel, cross-agent, delayed, or context already noisy → /to-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 on the current frontier ticket and execute that goal in a clean session, regenerating from the next frontier after each slice. Use /to-goal --all only for a persistent harness that must renew context across tickets.