Commands

What slash commands are

A slash command is a reusable prompt you invoke by typing /name. Two kinds matter:

• Built-in commands ship with Claude Code (/help, /clear, etc.).
• Custom commands are Markdown files you write. They are the right tool when you find yourself pasting the same prompt every day.

The built-in commands you will reach for

Exact names can change between versions — run /help in a current session for the authoritative list. The categories that almost always exist:

• Session control — clear context, compact a long conversation, list sessions.
• Model / mode — switch the model or the operating mode.
• Init — scaffold a CLAUDE.md from the codebase.
• Help — list available commands, including your custom ones.

When to write your own

Write a custom command when a prompt is:

• Repeated — you run it every day or on every PR.
• Shared — your whole team should run the exact same review or scaffolding step.
• Parameterized — it takes a target file, branch, or ticket id.

If a prompt is one-off or exploratory, just type it — a command adds friction, not value.

How custom commands work

Custom commands are Markdown files with optional YAML frontmatter. They live in one of three places (lowest to highest scope):

• Project commands — .claude/commands/*.md in the repo. Shared with the team. Label shown in /help: (project).
• Personal commands — ~/.claude/commands/*.md on your machine. Available in every project. Label: (user).
• Plugin commands — plugin-name/commands/*.md, available when that plugin is installed.

The file’s frontmatter can declare a description, an argument hint, and the tools the command is allowed to use. Arguments are substituted into the body via $ARGUMENTS or $1, $2.

Two generic examples

Example A — a scoped code review.

A file .claude/commands/review-pr.md:

---
description: Review the diff on the current branch
argument-hint: [base-branch]
allowed-tools: Read, Bash(git:*)
---

Review the commits on this branch against `$1`. Focus on logic errors, missing
edge cases, and tests. Do not comment on style the linter already enforces.

Invoke with /review-pr main.

Example B — a scaffold.

---
description: Scaffold a new repository pattern
allowed-tools: Read, Write
---

Create a repository class for $ARGUMENTS following the pattern in
src/repositories/UserRepository.php. Include the interface and a test stub.

Pitfalls

• Over-parameterizing. If your command takes five $N arguments it is harder to use than typing the prompt. Keep it to one or two.
• Granting broad tools. A command with allowed-tools: Bash can run anything. Scope it to Bash(git:*) or the specific commands it needs.
• Duplicating what a skill should do. Commands are invoked manually; skills are auto-discovered. If you want the behavior to trigger on its own, it is a skill — see Skills.