Ask me

You don't remember every skill, so ask.

A flow is a path through the skills. Most paths run along one main flow, and three on-ramps merge onto it. Everything else is standalone, or a vocabulary layer that runs underneath. Past engineering, buying something has a short flow of its own, and the vault, writing and UI skills are picked by situation (see Beyond engineering).

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 GLOSSARY.md and ADRs. (No working directory? Use /grill-me, covered under 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: is this a multi-session build?
   • 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. Kick off /implement per ticket, /clearing context between each one. Each ticket is self-contained, so the last one's context is disposable. Or run /implement-spec for the whole spec in one go: it reads the tickets as a task graph, runs implementer subagents across the ready frontier in parallel, each in its own worktree, and lands everything on one integration branch. Reach for it when you'd rather orchestrate the build than drive each ticket yourself. It holds the same gates as /implement (claim, review, live acceptance, checklist), once for the whole spec.
   • No → /implement right here, in the same context window.