Commands — Frozen Workflows
Slash commands that run your favourite rituals
Skills are helpers Claude summons on its own when your words match. A is the opposite — a ritual you pull out on purpose, typed as /review, /ship, /plan. Same markdown-file format as a skill; different when it runs.
By the end of this chapter you'll have a working /review command you can invoke before any PR, plus a catalogue of twelve more you can install piece by piece.
You'll have a working `/review` slash command installed in your repo that gives you a structured blockers / discussion / fine summary of any diff. Plus a library of 12 more commands you can steal as you need them.
Commands are rituals you invoke by name
Every developer has rituals — the structured questions you ask yourself before merging, the pre-shipping checklist, the "have I done all the things?" process. They're valuable because they're repeatable— same framework, every time. But they're fragile because they live in your head, and when you're tired or rushed, you skip steps.
A slash command is your ritual, written once, stored as a file. Claude runs the framework for you — same steps, same output format, every single time — so you don't have to remember them. You just type /review and the ritual happens.
The best commands start with "read these files first" and end with a strict output template. Claude is free to interpret the middle; the boundaries stay locked.
We'll install /review — a structured diff review that returns three sections: blockers, items worth discussing, and a clean bill of health. Use it before every PR.
Make the commands directory
mkdir -p .claude/commands
Create review.md
The filename (without .md) becomes the command name. So a file named review.md becomes /review.
--- description: Review the current diff for bugs, edge cases, and style issues --- # /review You are reviewing the current git diff for problems I might ship by accident. Be direct. ## Read 1. Run `git diff --cached --no-color` (staged) or `git diff --no-color` (unstaged) to see the changes. 2. Read the affected files for surrounding context. ## Report in this format **Blockers** — things that MUST be fixed before merge - <one bullet per blocker, with file:line reference> **Worth discussing** — judgement calls, potential issues - <one bullet per item> **Fine** — one-liner confirming nothing else stood out ## Rules - If the diff is empty, say so and stop. - Never invent issues to look thorough. Empty blocker list is fine. - Cite file:line for every finding. No vague "this function feels off". - Check for: secret leaks, unhandled error paths, unused imports, missing null checks, console.log in prod, TODO comments left in.
Stage something small, then invoke it
Make any tiny change to a file (one character is fine), then stage it:
git add .
Now start a Claude Code session and type /review. Claude will autocomplete — matching your installed commands — and then fire the ritual.
/review
You should see the structured three-section output defined in the command body — Blockers / Worth discussing / Fine — not Claude's default prose. That's the command doing its job.
Twelve commands drawn from the daily workflow of someone who ships production apps. Pick two or three that match work you do weekly. Don't install all twelve — commands you never use become noise in your autocomplete.
Each card below is a one-liner: what the command does plus why it earns its keep. The full .md files ship as downloadables with the course (via the bootstrap CLI) — for now, use the descriptions to decide which ones to write yourself.
Pre-build evaluation: feasibility, scope, risks, suggested approach
Use before starting any feature that'll take more than a day.
Post-implementation audit: migrations, error logging, quota resets, tests
The single skill most likely to save you from a production incident.
Orchestrates /feature-check + /theme-check + /security-audit in one pass
Run before every PR.
Structured diff review: blockers / worth discussing / fine
The starter command you just installed.
Launches the Plan sub-agent to propose 1–2 approaches before editing
Prevents Claude from freestyling architecture.
Spawns 3 parallel Explore sub-agents on the topic
When you need breadth fast without blowing the main context.
Proposes a project_<feature>.md memo from recent session context
After a gnarly debug, use this to bank what you learned.
Scaffolds a new .md prompt file with required-token validator
For apps that load prompts from files (see Ch 10).
Sweeps the repo for unguarded billable AI calls
Load-test mode protection — run before any big test push.
Chains env-check + schema-parity + RLS-audit
Weekly-ish. Catches config drift.
Structured postmortem template: timeline, root cause, fix, prevention
After any incident >30 min. Bank the lesson.
Greps diff for light-mode-breaking patterns (hardcoded colors, raw rgba)
If you support both themes, this stops 80% of regressions.
From rituals to context that survives
You've now written a rule (CLAUDE.md), a recipe (skill), and a ritual (command). All three live in files, all three persist across sessions, all three compound over time.
Chapter 6 covers the last information-at-rest primitive: — the mechanism that stops you re-explaining your repo to Claude every time you sit down. Because nothing kills momentum faster than having to say "oh right, also, our auth flow works like this" for the forty-third time.