There are tasks you ask Claude to do in almost every session: write a commit message, review the diff before committing, explain a confusing piece of code, open a PR. You could retype these requests every time. Or you could turn them into slash commands.
Slash commands in Claude Code are Markdown files that become reusable prompts. Type /commit and Claude runs your commit workflow. Type /review-pr 142 and Claude fetches and reviews PR #142. The command is the prompt — no code required.
How slash commands work
A slash command is a Markdown file in .claude/commands/ at your project root (or ~/.claude/commands/ for commands available in all projects). The filename determines the command name: commit.md becomes /commit, review-pr.md becomes /review-pr.
When you type /commit in a Claude Code session, Claude reads the file and uses its contents as your prompt. Everything in the Markdown file is treated as instructions to Claude.
Project-level commands (.claude/commands/) are available to everyone who uses Claude Code in that repo — great for team standards. User-level commands (~/.claude/commands/) are yours alone — for personal shortcuts that apply across projects.
Your first slash command
Create .claude/commands/commit.md:
Look at the current git diff (both staged and unstaged changes). Write a commit message following the Conventional Commits format:
- `feat:` for new features
- `fix:` for bug fixes
- `refactor:` for code refactoring with no behavior change
- `docs:` for documentation changes
- `test:` for test additions or changes
- `chore:` for maintenance tasks
The subject line should be under 72 characters. Add a body paragraph if the change needs explanation beyond the subject.
Show me the commit message before committing, and ask for confirmation.
Now in any session, typing /commit tells Claude to inspect the diff and write a proper commit message. It asks for confirmation before committing — useful when you want to review the message first.
Parameterized commands with $ARGUMENTS
Most interesting commands need to accept input. The $ARGUMENTS variable captures everything you type after the command name:
/review-pr 142
# $ARGUMENTS = "142"
/explain src/auth/middleware.ts
# $ARGUMENTS = "src/auth/middleware.ts"
/debug "TypeError: cannot read property 'id' of undefined"
# $ARGUMENTS = "TypeError: cannot read property 'id' of undefined"
Create .claude/commands/review-pr.md:
Review the GitHub pull request #$ARGUMENTS in this repository.
Fetch the PR diff and review it for:
1. Correctness — does the code do what it claims to?
2. Security issues — especially in auth, input handling, and data exposure
3. Missing error handling
4. Tests — are the changes adequately tested?
5. Breaking changes to the existing API contract
Post your findings as a PR review with inline comments on specific lines where relevant. End with a summary verdict: approve, request changes, or comment-only.
Now /review-pr 142 expands to a detailed review prompt with $ARGUMENTS replaced by 142.
You can reference $ARGUMENTS multiple times in the same file, or use it as part of a path:
Read the file $ARGUMENTS and explain what it does. Then identify:
- Its dependencies (what it imports)
- What depends on it (search the codebase for imports of $ARGUMENTS)
- Any obvious code quality issues
Practical slash commands to build
/commit — Write and confirm a commit message (shown above)
/pr — Open a pull request:
Create a pull request for the current branch targeting main.
1. Run `git log main..HEAD --oneline` to see the commits included
2. Summarize the changes in a PR description with:
- What changed and why
- How to test the changes
- Any breaking changes or migration steps
3. Use the GitHub MCP server to create the PR with this description
4. Output the PR URL
/explain — Explain a file or function:
Read $ARGUMENTS. Explain:
- What it does at a high level
- How it fits into the larger system (look at what imports it and what it imports)
- Any non-obvious implementation decisions
- Potential failure modes or edge cases
Write for a developer who is new to this codebase.
/test — Write tests for a file:
Write comprehensive unit tests for $ARGUMENTS.
Before writing:
1. Read $ARGUMENTS to understand what it does
2. Look at existing tests in the project to match the testing style and framework
3. Check for any test utilities or fixtures already defined
Test every exported function. Cover:
- Happy path
- Edge cases (empty inputs, boundary values)
- Error cases (invalid inputs, external failures)
Create the test file in the appropriate location. Run the tests after writing them.
/debug — Debug an error:
I'm getting this error: $ARGUMENTS
Trace the error:
1. Identify which file and line is throwing
2. Read the relevant code
3. Trace backwards through the call stack if needed
4. Identify the root cause
5. Propose a fix
Don't implement the fix yet — explain it first and ask for confirmation.
/review — Review the current diff before committing:
Review my changes before I commit them.
1. Run `git diff` to see unstaged changes, `git diff --staged` for staged changes
2. Review for:
- Accidental debug code (console.log, TODO comments, hardcoded values)
- Missing error handling
- Any obvious bugs
- Changes that should be split into separate commits
3. Give me a summary: is this ready to commit, or are there issues to address first?
Slash commands vs regular prompts: when each wins
Slash commands are worth creating when:
- You repeat the same request multiple times per week
- The prompt is long enough that retyping it is annoying
- You want to standardize a workflow across your team (commit format, PR template)
- The task takes parameters (PR numbers, file paths) that change each time
Stick with a regular prompt when:
- It's a one-off task
- The task is too context-specific to generalize
- You're experimenting and don't know yet what the right prompt is
The economic question: does the time saved typing outweigh the time to write the command file? For anything you do more than a few times a week, the answer is usually yes.
Team slash commands
Commands in .claude/commands/ are committed to your repo. That means your /commit command enforces the same commit message format for everyone on the team. Your /review-pr command makes sure PR reviews cover the same quality bar every time.
This is one of the more underrated features: you can encode your team's engineering standards into commands that Claude follows automatically. New developers who join the team pick up your conventions immediately because the commands guide them.
Some teams commit a set of "starter commands" covering:
/commit— conventional commits format/pr— PR description template/review— pre-commit quality check/test— test writing guidelines/deploy— deployment checklist
These commands are documentation that Claude acts on, not just documentation that humans read and sometimes ignore.
Commands and the /memory slash command
Claude Code ships with built-in slash commands alongside your custom ones. The most useful built-in is /memory, which lets you update CLAUDE.md during a session:
/memory "Add: We now use Vitest instead of Jest for all new tests"
The custom commands you create don't interfere with built-in ones — they're in separate namespaces. If you name a custom command memory.md, it would conflict with the built-in /memory command, so avoid names that match Claude Code's built-in commands.
The next lesson covers skills — structured multi-step workflows that go beyond what a single slash command can handle. If a slash command is a reusable prompt, a skill is a reusable orchestrated workflow.