Claude Code Slash Commands That Stick: Reusable Command Bodies

What a Claude Code Slash Command Really Is

A Claude Code slash command is a saved prompt file that runs when you type a slash and its name. The file sits under .claude/commands, holds a prompt body, and accepts typed input through an arguments token. Type /review and Claude injects the whole saved prompt instead of making you retype it.

Most guides on Claude Code slash commands teach the wrapper and stop. The Anthropic docs cover the frontmatter and the $ARGUMENTS token as reference. The claudedirectory.org guide walks the mechanics. A BioErrorLog walkthrough shows one example. They all answer the question of how to make a command file. None answer the harder one: what goes inside it so the command earns a permanent spot in your workflow?

That's the gap. Syntax is easy. A command body that produces the same useful shape every run is the actual work.

Why Most Slash Commands Get Deleted Within a Week

You write a /review command. The first run is great. The second run formats the findings differently. The third run buries the critical bug under three paragraphs of praise. By Friday you've gone back to typing the prompt by hand because at least then you control it.

The command didn't fail because of syntax. It failed because the body was a task description, not a contract. "Review this code and suggest improvements" tells the model what to do but nothing about what to give back. So it improvises, and improvisation drifts.

A command body that sticks does two things the throwaway version doesn't. It frames a tight role, and it locks an output shape the model must return. Those two together are why some saved prompts survive a year and others don't survive a week.

What You Can Turn Into a Slash Command

The commands worth saving are the jobs you repeat:

• Context mapping. A /map command that turns a file tree into a one-line-per-area summary you can paste into a fresh session.
• Code review. A /review command that returns findings at a fixed severity scale, not free-form prose.
• Test scaffolding. A /tests command that emits cases for a function against a fixed table format.
• Commit messages. A /commit command that reads a diff and returns a single conventional-commit line.
• Onboarding summary. A /onboard command that explains an unfamiliar module in a fixed three-part shape.

Each of these is a candidate for a saved body with a contract. The job repeats, so the prompt should be frozen and reused, not rewritten.

Anatomy of a Command Body That Sticks

The pattern has three parts, in order.

Role:     two lines, no backstory.
Task:     what to do with $ARGUMENTS.
Contract: the exact shape of the output, last.

Here's a /review command that holds up across runs:

You are a senior reviewer. You flag defects, not style preferences.

Review the code or diff in $ARGUMENTS.

Return findings as a markdown table with columns:
Severity (blocker / major / minor) | File:line | Issue | Fix.
List blockers first. If there are none, write "No blockers."
No summary paragraph, no praise.

The contract is at the bottom on purpose. On a long pasted diff, the model weights the most recent tokens, so a format spec at the top gets outvoted by the code in the middle. Put the shape last and it survives the paste.

One more thing the throwaway version skips: the empty case. A review command with no "No blockers" clause will manufacture a finding rather than admit the code is clean, because the prompt asked for findings and the model obliges. That's not the model being unhelpful. It's the prompt not giving it permission to return nothing. Add the clause and a clean diff returns "No blockers" instead of an invented nitpick. Small line, big difference in how much you trust the command's output over a few hundred runs.

How the Same Body Reuses Across Models

A good command body isn't Claude-only. The same role-task-contract structure ports to ChatGPT and Cursor with small tweaks.

The takeaway: write the body once with the contract last and a refusal clause for the empty case, and it survives the jump between tools. That portability is why a saved command library beats per-tool snippets you maintain three times.

Variables You'll Set

Getting Started

1. List the prompts you retype more than twice a week. Those are your candidates.
2. For each, write a two-line role and the task against $ARGUMENTS.
3. Add the output contract last, as a fixed shape the model must return.
4. Add a refusal clause for the empty case ("write No blockers").
5. Save each as a markdown file under .claude/commands.
6. Run it on a real input and tighten the contract where the output drifts.
7. For a ready-made library, start with the Repo Context Map Pack.

Some commands need a policy behind them, not just a contract. A review command gets sharper when it reads a fixed rule set. The Code Review Policy System Prompt is the body to paste into a /review command when you want the same standard applied across every repo.

A slash command library is only as good as the bodies inside it. Freeze the role, lock the contract, and you stop rewriting the same prompt every day. For the file that configures the agent before any command runs, see how to write an AGENTS.md file with AI. And when you're deciding which saved prompts are worth keeping, how to choose a reusable AI prompt pack uses the same contract test.