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. If a ticket moves a module boundary rather than filling one in, check it against the floor plan first (Section 10).

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. Several unblocked tickets waiting? Give each agent its own worktree and run them side by side (Section 11) — same folder, and they overwrite each other.

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. Mind the name collision: this /review is the skill from Section 2's skill sets. Claude Code ships a native /review of its own — if both are installed, confirm which one answered.

5

Harden it before it's real

/security-review — Claude Code's native security pass, which looks only for vulnerabilities and has no name collision (Section 9). It's a fast first opinion, not the pipeline's scanners. Then make the one check no scanner makes for you: does this change give the agent a new mouthful of untrusted text — a customer's booking note, a scraped page, an inbound email? To a model that's all just text, which is why prompt injection tops the LLM risk list, and why the defence is structural: never let one session hold private data, untrusted content and a way to send things out.

6

Ship it — deploy, then release

It rides the pipeline, never a manual push (Section 8): a preview deploy on the pull request, merged dark behind a feature flag, released to a small slice first — the canary — while the error budget watches, then ramped. Rollback stays one flag flip away, and you have performed it once already while nothing was on fire. Deploying and releasing are two separate events, and nothing — not even a one-line hotfix — skips a station.

7

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.

How closely you stand over each of these moves isn't a constant — it's Section 14's trust dial: turned up for money paths and unfamiliar ground, down for the routine, and moved on evidence rather than mood.

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

All nine are skills — the sets you installed in Section 2, not part of Claude Code itself. Claude Code also ships native slash commands, and one name collides: the built-in /review is not the skill listed above. The security pass the harden move uses, /security-review, is native and collides with nothing — which is why it isn't on this list.

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 or a backup restore (Section 8's slower half — the ship move above is its daily one). 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.