Claude Code Commands

If you find yourself pasting the same instruction into Claude Code over and over — "review this against our conventions," "scaffold a component like the others" — you're prompting when you should be using a command. Commands turn a repeated prompt into a reusable, shareable workflow. This page covers slash commands, custom commands, and how to standardize them across a team.

Slash commands vs custom commands

• Slash commands — quick, invokable actions (built-in or project-defined) you trigger with /. Fast entry points into a defined task.
• Custom commands — your own workflows, defined as files in the project so the whole team gets them. This is where the leverage is: encode a recurring task once, run it forever.

How to create a custom command

A custom command is a Markdown file in your project's commands directory. The file name becomes the command; the contents become the instruction the agent runs. Commit it, and every teammate has the same command available:

# .claude/commands/review.md
Review the current diff against our conventions:
- check it follows the patterns in our context tree
- flag anything we've tried and reverted before
- tag the owner of any module it touches

Now anyone runs /review and gets the same review, the same way. That's the difference between a prompt (yours, once) and a command (the team's, always).

Anatomy of a command file

The plain Markdown file above is the 80% case. The other 20% — the part that turns a command from a saved prompt into a small program — lives in three features: frontmatter, arguments, and context injection. Here's a command that uses all three to scaffold a component to spec:

---
description: Scaffold a new component matching our conventions
argument-hint: <ComponentName>
allowed-tools: Read, Write, Edit
---
Create a new component named $1.

Match the structure of an existing one for reference:
@src/components/Button.tsx

Follow the conventions documented in our context tree, and
register the component the same way the others are. Current
components on disk:
!`ls src/components`

Four mechanics are doing the work, and they're worth knowing by name:

• Frontmatter — the --- block sets metadata. description is what shows in the / menu; allowed-tools scopes what the command may touch (here it can't run arbitrary shell); argument-hint documents the expected input.
• Positional arguments — $1, $2, … capture individual words after the command, so /scaffold Modal drops Modal into $1. Use $ARGUMENTS instead when you want the entire trailing string as one blob.
• File references — @path/to/file pulls a file's contents inline, so the agent reasons from the real reference component, not a description of it.
• Bash injection — a line beginning with ! runs a shell command and splices its output into the prompt, so the agent sees the actual current state of the directory before it acts.

That's the whole spec. A command is a Markdown file, optionally with a frontmatter header, that can take typed arguments and pull in live context. Nesting matters too: a file at .claude/commands/test/unit.md becomes /test:unit, so you can namespace a growing library instead of drowning in a flat list.

Five commands worth committing first

The fastest way to get value is to commit a handful of commands that map to work your team already does every day, then let the library grow from real friction. These five are the mainstream starting set — each one replaces a prompt people currently retype, and each is a single Markdown file under .claude/commands/:

• /reviewReview the current diff against your conventions before it goes up as a PR.
• /testRun the suite, read the failures, and fix them — the command teams reach for most.
• /fix-ciPull the failing CI logs for the current branch and make the build green.
• /scaffoldGenerate a new module, component, or endpoint that matches the existing ones.
• /changelogSummarize the merged changes since the last release into a changelog entry.

Keep each one short and single-purpose. A command that tries to do five things is a command nobody trusts; five commands that each do one thing are five things your whole team can run without thinking. When a command earns its keep, the natural next move is to wire it into a loop so it runs without a human pressing go.

Commands make the loop repeatable

A command is an entry point into the agent loop — it starts a defined cycle with the right setup, so you're not re-describing the task each time. Commands are how the shift from prompting to looping becomes repeatable across a team instead of living in one person's habits.

The piece commands can't carry: context

A command captures the workflow, but not your team's decisions. The /review command above only works if the agent actually knows your conventions and what you've rejected — and that knowledge can't live in the command file without going stale. It belongs in a shared, owned context tree the command's loop reads each run — the same memory the rest of your agent workflow coordinates around.

Commands, a tight CLAUDE.md, and shared context are the setup behind Claude Code best practices for teams — and the foundation of running AI agent teams that stay consistent.

}