ReferenceA day in the life — quick reference

Everything above explained one move at a time. This is the same loop as a five-minute cheat sheet for the moment you've forgotten which skill comes next.

1

Align on today's work

/grill-me for a new idea, or /grill-with-docs if it builds on something already documented — until the fuzzy parts are nailed down (Section 3).

2

Freeze it into tickets

/to-prd, then /to-issues — turn the aligned idea into a PRD and small tracer-bullet tickets (Section 4). UI or taste-heavy? Run /prototype first.

3

Build one ticket, test-first

/tdd — a separate agent writes the failing test, another makes it pass, red-green-refactor (Section 5). Stuck on a bug instead of building? /diagnose.

4

Get a second opinion before merging

/review for an adversarial pass on the diff (Section 6), then watch the demo reel and check the definition-of-done gates (Sections 6–7) before it goes anywhere near main.

5

End of session, or things feel sloppy

/handoff to compress state into a fresh session (Section 12) — don't push an agent through the dumb zone hoping it holds together.

Every command in this guide, at a glance

  • /grill-me — interview you on a new idea until it's specific. Section 3
  • /grill-with-docs — same, but reads your existing docs first. Section 3
  • /to-prd — turn a grilled idea into a destination document. Section 4
  • /to-issues — break a PRD into small, independent tracer-bullet tickets. Section 4
  • /prototype — throwaway UI/state variations to pick from before committing. Section 4
  • /tdd — red-green-refactor with a tester agent independent of the coder. Section 5
  • /diagnose — a disciplined reproduce → minimise → fix loop for a stuck bug. Section 5
  • /review — adversarial reviewer agents check a diff against spec and standards. Section 6
  • /handoff — compress session state so a fresh agent picks up cleanly. Section 12
Not every day — the slower rhythm

Some things don't belong in the daily loop but need a real cadence of their own: running production-readiness-protocol.md in full before a real launch or a major milestone, a periodic Tech Radar review (Section 13), and an occasional "game day" rehearsal of a disaster-recovery playbook (Section 8). Put these on an actual calendar — a good practice with no trigger to run it quietly stops happening.

And two one-time detours for the moments they apply: Setup, part two the first time a project goes live (repo host, CI, staging, backend), and Existing code: adopt and rescue when the day starts from a codebase you didn't build with this loop.