Claude Code custom slash commands: the ones I actually use every day

Claude Code ships with built-in slash commands (/help, /clear, /cost). But the real power is in custom commands — project-specific shortcuts that encode your workflow.

Here are the exact ones I use on every project, with copy-paste CLAUDE.md config.

---

How custom slash commands work

Custom commands live in .claude/commands/ in your project root (or ~/.claude/commands/ for global ones).

Each command is a markdown file. The filename becomes the command name.

.claude/
  commands/
    review.md
    deploy.md
    debug.md
    test.md

Run them with /project:review, /project:deploy, etc.

Global commands use /user:commandname.

---

The commands I actually use

1. /project:review — code review before every PR

.claude/commands/review.md:

Review the staged git changes (`git diff --cached`) for:

1. **Bugs**: logic errors, off-by-one, null pointer risks
2. **Security**: injection, auth bypass, exposed secrets
3. **Performance**: N+1 queries, missing indexes, sync where async needed
4. **Style**: consistency with the existing codebase patterns

Format your response as:
- CRITICAL (must fix before merge)
- WARNING (should fix, non-blocking)
- SUGGESTION (optional improvement)

Be terse. Skip praise. Only flag real issues.

Why it works: The git diff --cached instruction means Claude always looks at what's actually staged — not the whole repo. Terse output means I read it instead of skimming.

---

2. /project:debug — structured debugging

.claude/commands/debug.md:

Debug the issue described below using this process:

1. **Reproduce**: Identify the exact inputs/conditions that trigger the bug
2. **Isolate**: Narrow to the specific function/line causing the problem  
3. **Root cause**: Explain WHY it's happening, not just WHAT
4. **Fix**: Write the minimal code change that resolves it
5. **Verify**: Show how to confirm the fix worked

Do NOT rewrite surrounding code. Minimal surgical fix only.

Issue: $ARGUMENTS

The $ARGUMENTS placeholder passes whatever I type after the command. So /project:debug undefined is not a function on line 47 gives Claude the full context.

---

3. /project:test — write tests for the current file

.claude/commands/test.md:

Write comprehensive tests for the file I specify.

Requirements:
- Use the existing test framework in this project (detect from package.json)
- Cover: happy path, edge cases, error conditions
- Mock external dependencies (DB, API calls, filesystem)
- Each test should have a clear description of what it tests
- Aim for 80%+ branch coverage

File: $ARGUMENTS

After writing tests, run them and fix any failures.

---

4. /project:explain — onboard new devs fast

.claude/commands/explain.md:

Explain this codebase to a new developer joining the team.

Cover:
1. **Architecture**: How is the code organized? What are the main modules?
2. **Data flow**: How does data move through the system?
3. **Key abstractions**: What are the most important classes/functions to understand?
4. **Entry points**: Where does execution start for the main use cases?
5. **Gotchas**: What are the non-obvious things a new dev would stumble on?

Focus on $ARGUMENTS if specified, otherwise give a full overview.

---

5. /user:commit — my global commit message generator

~/.claude/commands/commit.md (global, works in every project):

Generate a conventional commit message for the staged changes.

Run `git diff --cached` to see what's staged.

Format:

():

[optional body: what changed and why, not how]

[optional footer: breaking changes, issue refs]

Types: feat, fix, docs, style, refactor, test, chore

Rules:
- First line max 72 characters
- Description is imperative mood ("add" not "added")
- Body explains the WHY, not the WHAT (the diff shows the what)
- No period at end of first line

Then run: `git commit -m "<message>"` — don't ask me to confirm.

This one saves me the most time. I stage my changes, type /user:commit, and Claude reads the diff, generates the right conventional commit, and commits it. Zero thinking required.

---

Setting up the directory

# Per-project
mkdir -p .claude/commands

# Global (works everywhere)
mkdir -p ~/.claude/commands

Add .claude/ to your .gitignore if you don't want to share commands. Or commit it to share with your team — they get the same shortcuts.

---

Power tip: chain with CLAUDE.md

In your CLAUDE.md, you can tell Claude WHEN to use commands automatically:

## Workflow rules
- Before any git commit: run /project:review automatically
- When asked to fix a bug: use /project:debug structure
- When writing new functions: offer to run /project:test after

This turns slash commands from manual shortcuts into automatic workflow enforcement.

---

The API angle

If you're running Claude Code against your own API endpoint (via ANTHROPIC_BASE_URL), custom commands work exactly the same — they're just prompts that Claude executes. The model doesn't care where the API call routes.

I use SimplyLouie as my ANTHROPIC_BASE_URL — it's a flat-rate Claude API at $2/month. Slash commands, subagents, hooks — all of it works the same. The only difference is I'm not paying per-token for every /project:review run.

Setup:

export ANTHROPIC_BASE_URL=https://simplylouie.com/api
export ANTHROPIC_API_KEY=your-key-here
claude  # that's it

---

TL;DR

Command	Does	Lives in
/project:review	Reviews staged diff	.claude/commands/
/project:debug	Structured bug investigation	.claude/commands/
/project:test	Writes tests for a file	.claude/commands/
/project:explain	Onboards new devs	.claude/commands/
/user:commit	Generates commit messages	~/.claude/commands/

The commit message generator alone is worth the 5 minutes it takes to set this up.

---

Got a custom slash command I should know about? Drop it in the comments.