/commands

A slash command is a prompt you've saved as a file. Put markdown in .claude/commands/review.md, and /review in any Claude Code session expands it — arguments and all — into the conversation. It is the smallest possible piece of automation infrastructure: no framework, no deployment, a prompt that stopped being retyped. Most teams underuse commands badly, because they look like a convenience feature and are actually a quality mechanism. This lesson: why saved beats retyped, the anatomy of commands worth keeping, and where commands sit among the three homes for standing text.

Why saved prompts beat retyped prompts

Speed is the obvious reason and the least important one.

Iteration compounds. A retyped prompt is born and dies in one session; nobody improves it. A command file accretes fixes: every time the output misses, you sharpen the file — one more boundary, one more anti-instruction — and every future invocation inherits every lesson ever learned. Six months in, your /review embodies fifty review sessions' worth of refinement. It has become a small product with a version history, which is exactly what git log .claude/commands/review.md will show you.

Quality stops varying. Your Friday-afternoon version of "review this for security issues" is not your Monday-morning version. The command is identical on both days. For anything that's a procedure — reviews, release prep, triage — consistency of the asking is consistency of the result, and the file is what makes the asking consistent (the same variance-killing argument as lesson 4, applied to procedures).

The team inherits the best version. Committed under .claude/commands/, the whole repo gets it: your sharpest reviewer's checklist, embodied, is now what happens when anyone types /review. This is the mechanism by which individual prompting skill (lesson 1) becomes organizational capability — one file at a time.

Anatomy of a command worth keeping

Commands take arguments — $ARGUMENTS for the whole tail, $1, $2 positional — and front matter for a description and tool restrictions. The craft is the body, and the bar is higher than an interactive prompt, because a command runs without its author present to steer:

---
description: Review a PR diff for problems that matter.
---
Review the diff of $1 for issues that matter: correctness
bugs, security problems, race conditions, silent failure
paths, and API-contract breaks.

Do NOT comment on formatting, naming taste, or anything a
linter catches.

For each finding: file:line, the problem in one sentence,
the concrete failure it causes, and a suggested fix.

If the diff is clean, say so plainly. Do not invent
findings to seem thorough.

Every lesson-1 technique appears — outcome, boundaries, output shape — plus the signature move of good command-writing: the anti-instruction tuned to this task's characteristic failure. Review prompts invite invented findings (the model wants to seem useful); so the command forbids exactly that. Every task has such a failure; finding it takes two or three real runs; encoding it is what turns a saved prompt into a reliable instrument. Write every command as if it will run unattended — because that's also the training for lessons 14 and 18, where your prompts really do run without you.

Two structural rules from hard experience:

• One command, one job. /fix-and-deploy-and-announce fails in ways you can't attribute — which step went wrong? Small commands compose; composite commands confound.
• If invocations keep needing extra typed instructions, the body is missing a paragraph. The variable part belongs in arguments; the invariant part belongs in the file. Repeatedly typing the same rider after a command is the same signal as repeatedly correcting an agent (lesson 8): the environment is asking for an edit.

The three homes for standing text

You now have three places to put words that outlive a session, and the boundaries between them are worth having crisp:

Home	Loaded	Best for
CLAUDE.md (8)	always, every turn	facts and rules that apply constantly
Command (9)	when a human types /name	procedures with a deliberate "do it now"
Skill (14)	when the model judges it relevant	procedures that should fire even unasked

Two implications fall out of the middle row. First, economics: a command's body costs zero context until invoked — a fifty-command library is free until used, which makes commands the right home for long, detailed procedures that would bloat CLAUDE.md (lesson 2's overhead discipline, lesson 20's arithmetic). Second, and easy to miss: human invocation is a feature, not a limitation. For procedures with judgement or stakes attached — releases, migrations, anything irreversible — you want activation to be a deliberate human act. Automate the text; keep the trigger in human hands. When you later meet skills, the choice between command and skill is exactly the choice of who should hold the trigger — and "a person" is often the right answer.

Where to start: mine your history

The catalog already exists — it's the prompts you've typed more than twice. Classic first wins:

• /review $1 — as above, tuned to what your linter doesn't catch.
• /test-loop — "run the suite; fix failures one at a time; re-run until green; summarize what changed and why." (Lesson 6's closed-loop habit, packaged.)
• /pr — "stage relevant changes; write a conventional commit; open a PR describing what and why. Never --force. Never push to main." (Boundaries in the file, so they can't be forgotten under deadline.)
• /explain $1 — architecture explanation in the shape you like: entry points first, data flow, then the weird parts.

Ten minutes each to write; then they improve for as long as the repo lives. That arc — effort placed once, upstream, compounding across every future use — is the shape of everything worthwhile in this course, and commands are the smallest, cheapest place to practice it.