07 — Slash Commands

A slash command is a named recipe. Type one word; get a consistent, structured workflow. Good for anything you find yourself asking Claude the same way more than twice.

The Core Idea

When you ask Claude something ad-hoc, the quality of the response depends on how well you phrased the question that day. Slash commands remove that variability. You encode the prompt once — the framing, the constraints, the expected output format — and invoke it by name from then on.

Think of it as the difference between asking a chef to "make something with chicken" versus handing them a recipe card. Same ingredients, much more consistent result.

When to Write a Command

Write one when:

• You've typed essentially the same prompt three or more times
• A task has a specific sequence of steps that should always run in order
• You want Claude to pause and wait for confirmation at a specific point
• You're onboarding someone else to a workflow and want it repeatable

Don't write one when:

• The task is genuinely one-off
• The ask changes significantly each time
• A direct question gets you there faster

Where Commands Live

~/.claude/commands/
├── plan.md
├── commit.md
└── review.md

Each .md file defines one slash command. The filename is the command name: plan.md → /plan. Commands can accept arguments via $ARGUMENTS.

Anatomy of a Good Command

A command file is a prompt template. It should:

1. State the goal — what this command does in one sentence
2. Define the steps — the exact sequence Claude should follow
3. Set constraints — what Claude should not do (e.g., don't write code until confirmed)
4. Specify output format — what a good result looks like

You are running the plan workflow for: $ARGUMENTS

Steps:
1. Restate the requirements in your own words
2. Identify risks and unknowns
3. Break the work into phases with clear dependencies
4. Estimate complexity: High / Medium / Low
5. Present the plan and WAIT for the user to confirm before touching any code

Do not write, edit, or delete files until the user explicitly approves the plan.

The key line is that last one. Commands are where you enforce guardrails that are easy to forget in a live session.

Built-in Commands Worth Knowing

Claude Code ships with a few commands by default:

• /compact — summarizes the current session and compresses context. Run this when a long session starts degrading response quality.
• /clear — wipes the current context entirely. Fresh start.

These exist because the underlying need is universal: every session eventually gets too long, and you need a way to reset without losing your place entirely.

The "Runbook" Framing

The most useful way to think about commands: they're runbooks you give Claude.

A good runbook is specific enough that two different people (or two different sessions) following it produce the same outcome. A good slash command works the same way — specific enough that Claude doesn't have to infer what you meant, flexible enough to handle $ARGUMENTS that vary.

If you find yourself editing a command file more than twice to fix the output, the problem is usually vagueness in the steps or a missing constraint at the end.

A Simple Starting Point

If you're new to commands, start with one for your most common repeatable workflow. Write it as if you were explaining the process to a capable junior engineer who doesn't know your preferences. Be specific about what "done" looks like. Add one explicit "do not proceed until" gate if the task is risky.

That's it. The rest is iteration.