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, choose the matching path:

   • State or business logic — detour through /prototype, bridged by /handoff when it lives in another directory or harness.
   • Visual direction — once product intent, audience, flows, content, constraints, and platform are resolved, invoke /frontend-design. It creates three runnable directions, captures evidence, grills the human on reactions, and records the approved docs/design/<feature>/DESIGN.md. If those prerequisites are still foggy, stay in /grill-with-docs or use /wayfinder; the design skill will not invent them.

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.
   • No → /implement right here, in the same context window.

   Either way, /implement builds each issue by driving /tdd internally and invokes /frontend-build when an approved design contract governs the UI. It closes out with /code-review: independent Standards and Spec lanes plus /frontend-review when UI changed. Reach for these model-invoked skills directly when only that discipline is needed.