Claude Code Commands: The Complete Guide

What are Claude Code commands?

Claude Code commands are slash-prefixed shortcuts that execute predefined tasks inside your terminal session. Type /help and you'll see them listed, but the real story isn't the built-in ones. It's the custom commands you can create yourself.

There are two types of claude code commands:

1. Built-in commands: Ship with Claude Code. Things like /compact, /clear, /config, and /help. You can't modify these.
2. Custom commands: Markdown files in .claude/commands/ that you write. When you type the command name, Claude loads the file and follows the instructions inside it.

The built-in commands handle housekeeping. Custom commands are where the real productivity gains live. If you're not using custom commands yet, you're missing the most powerful feature Claude Code has.

Built-in commands reference

Here's every built-in command that ships with Claude Code, and when you'd actually use each one:

Command	What it does	When to use it
/help	Lists all available commands (built-in + custom)	When you forget what's available
/compact	Compresses conversation context, preserving key info	When context usage exceeds 80%
/clear	Resets conversation context completely	Between unrelated tasks in the same session
/config	Opens Claude Code settings	Changing model, theme, or permissions
/cost	Shows token usage and costs for the current session	Monitoring spend on API-based plans
/doctor	Runs diagnostics on your Claude Code installation	When something feels broken
/exit	Exits Claude Code	End of session
/add-dir	Adds a directory to the current context	Working across multiple project folders
/context	Shows current context files and usage	Understanding what Claude "knows" right now
/hooks	Lists active hooks and their status	Debugging hook behavior
/agents	Shows running sub-agents	Monitoring background tasks
/fast	Toggles speed-optimized API settings	When you want faster responses during iteration
/simplify	Reviews recent changes for code quality	After finishing a feature, before committing
/batch	Orchestrates large-scale parallel changes	Refactoring across many files at once
/export	Exports conversation as markdown	Sharing session context with teammates

Most developers only use /compact and /clear regularly. The rest are situational but valuable when you need them.

How custom commands work

Custom commands are markdown files stored in specific directories. When you type a slash command, Claude Code looks for a matching file and loads its contents as instructions.

There are three levels:

# Project-level (shared with team via git)
.claude/commands/my-command.md

# User-level (personal, across all projects)
~/.claude/commands/my-command.md

# MCP server commands (from connected servers)
# These appear automatically when MCP servers are configured

The file name becomes the command name. A file at .claude/commands/review.md becomes /review. Simple.

Anatomy of a command file

A command file is just markdown with optional YAML frontmatter:

---
description: Run a code review on recent changes
allowed-tools:
  - Read
  - Bash(git:*)
  - Grep
---

Review the most recent changes in this repository.

1. Run `git diff HEAD~1` to see what changed
2. Check for security issues, performance problems, and code quality
3. Report findings in a structured format

Focus on actionable feedback, not style nitpicks.

The frontmatter controls:

• description: Shows up in /help output
• allowed-tools: Which tools the command can use (security boundary)
• argument-hint: Placeholder text for commands that take arguments

The body is the prompt. Write it like you'd instruct a senior developer.

5 commands every project should have

These aren't hypothetical. These are commands that solve real workflow problems.

1. /start, Begin your work session

---
description: Load project context and begin work session
allowed-tools:
  - Read
  - Bash(date:*)
---

Read the following files to restore context:
1. CLAUDE.md (project instructions)
2. .claude/memory.md (what we were working on)
3. Task Board.md (current priorities)

Then summarize: what's in progress, what's blocked, what's next.

This replaces the first 5 minutes of every session where you're re-explaining what you were doing yesterday. Claude reads your state files and picks up where you left off.

2. /review, Code review with context

---
description: Review recent changes for bugs, security, and quality
allowed-tools:
  - Read
  - Bash(git:*)
  - Grep
  - Glob
---

Run a thorough code review on recent changes:

1. `git diff --cached` for staged changes, or `git diff HEAD~1` for last commit
2. Check for:
   - Security vulnerabilities (injection, auth bypass, data exposure)
   - Performance issues (N+1 queries, unnecessary re-renders, large payloads)
   - Error handling gaps (unhandled promises, missing try/catch)
   - Logic errors (off-by-one, race conditions, null checks)
3. Report findings with file:line references and suggested fixes

Better than a human review for catching mechanical issues. Won't replace architectural review, but catches the bugs that slip through tired eyes.

3. /sync, Mid-day context refresh

---
description: Refresh context and update project state
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash(date:*)
---

Mid-session sync:
1. Re-read CLAUDE.md and memory.md
2. Check what's changed since last sync
3. Update memory.md with current progress
4. Flag anything that looks stale or contradictory

After 3-4 hours of work, your context drifts. This regrounds Claude in the actual project state instead of the state from hours ago.

4. /audit, Quality gate

---
description: Run quality review on completed work
allowed-tools:
  - Read
  - Grep
  - Glob
  - Bash(git:*)
---

Audit the most recent completed task:

1. Verify all requirements were met
2. Check for regressions - did anything break?
3. Verify downstream files were updated (docs, tests, types)
4. Look for shortcuts that will cause problems later
5. Rate confidence: HIGH / MEDIUM / LOW with reasoning

Run this after finishing any non-trivial task. It catches the things you forgot, the test you didn't update, the type export you missed, the documentation that's now stale.

5. /safe-clear, Flush context safely

The built-in /clear wipes everything. A custom /safe-clear preserves your state first:

---
description: Safely flush context and resume fresh
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash(date:*)
---

Before clearing context:
1. Read current memory.md and today's daily note
2. Distill what was done, what remains, key decisions
3. Write a handoff to the daily note with file paths and next action
4. Update memory.md if priorities changed

Then resume work by re-reading the handoff and continuing.

This is the difference between "I lost my context" and "I compressed and resumed seamlessly." If you're hitting context limits regularly, this command alone justifies the setup time.

Building a command library

Individual commands are useful. A library of commands that work together is transformational.

Here's what a mature command library looks like:

.claude/commands/
├── start.md          # Begin session, load context
├── sync.md           # Mid-day refresh
├── wrap-up.md        # End session, persist state
├── safe-clear.md     # Flush context safely
├── audit.md          # Quality review
├── review.md         # Code review
├── onboard.md        # Scan new codebase
├── unstick.md        # Debug when blocked
├── standup.md        # Generate daily standup
└── deploy.md         # Push with verification

Each command reads from and writes to shared state files (memory.md, Task Board.md, Daily Notes/). The commands form a workflow, /start at the beginning, /sync in the middle, /wrap-up at the end. State flows between them automatically.

This is what separates a "Claude Code user" from someone who has an actual operating system built on Claude Code.

Commands with arguments

Commands can accept arguments. Use $ARGUMENTS in the command body:

---
description: Research a topic before implementing
argument-hint: "[topic]"
allowed-tools:
  - Read
  - WebSearch
  - Grep
---

Research the following topic before we implement anything:

Topic: $ARGUMENTS

1. Search for existing solutions and patterns
2. Check our codebase for related code
3. Summarize findings with pros/cons of each approach
4. Recommend an approach with reasoning

Now /research auth middleware migration passes the topic directly into the prompt. No back-and-forth needed.

Commands vs. hooks vs. skills

Claude Code has three extension mechanisms. Here's when to use each:

Mechanism	What it is	When to use
Commands	Markdown prompts invoked with /name	Workflows you trigger manually
Hooks	Shell scripts that run at lifecycle events	Automated enforcement (block dangerous actions, log changes)
Skills	Domain knowledge loaded on demand	Reference material Claude reads when relevant

Commands are for workflows. Hooks are for guardrails. Skills are for knowledge. They complement each other, a well-built system uses all three.

For example: you run /deploy (command), which triggers a pre-push safety check (hook), while Claude references your deployment procedures (skill).

Common mistakes with commands

Writing commands that are too vague. "Review my code and make it better" gives Claude no structure. Specific steps with clear outputs work better than open-ended instructions.

Not setting allowed-tools. Without allowed-tools, commands can use any tool, including destructive ones. Always scope down to what the command actually needs.

Putting code in commands instead of instructions. Commands are prompts, not scripts. Write what you want done, not how to do it. Let Claude figure out the implementation.

Not testing commands after writing them. Run the command on a real task before trusting it. The first version is never right. Iterate based on what actually happens.

How many commands do you need?

For most projects, 5-8 commands cover 90% of workflows. The five listed above (start, sync, review, audit, safe-clear) are a strong foundation. Add domain-specific commands as patterns emerge from your actual work.

The key is not quantity, it's that the commands you have actually get used daily. Five commands you use every session beat fifty you forget exist.

If you want to skip building from scratch, Claudify ships with 21 production-tested commands: daily workflows, quality gates, code review, deployment checks, retrospectives, and more. They're the same commands we use internally across real projects. One command to install: npx create-claudify.

What to build next

Start with /start and /review. Use them for a week. You'll naturally discover what other commands you need based on what you keep repeating manually.

The best command libraries aren't planned upfront: they grow from real friction. Every time you find yourself giving Claude the same instructions twice, that's a command waiting to be written.

For a deeper dive into extending Claude Code, check out our guides on hooks, memory systems, and CLAUDE.md configuration.

Get Claudify, 21 commands, 9 agents, 1,727 skills. Installed in one command.