Claude Code Slash Commands Guide

Claude Code Slash Commands — This guide to Claude Code slash commands covers the built-in commands, custom skills, plugin commands, and MCP prompts that let you control Claude directly from the prompt.

Claude Code Slash Commands: What You’ll Learn

In this guide to Claude Code Slash Commands, you’ll work through practical, hands-on steps with real examples. Claude Code Slash Commands is explained from the ground up so you can apply it immediately in your own projects.

Slash commands provide the quickest way to steer Claude Code’s behavior during an interactive session. Simply type / at any prompt to view the complete list, or type a few characters to narrow it down. This lesson covers the built-in commands you’ll rely on daily.

Discovering Commands

Type / at the prompt and a menu appears with all available commands. Start typing to filter — /co narrows to /compact, /color, /config, /context, /cost, /copy. Arrow keys navigate, Enter selects. Commands that aren’t available for your current setup are hidden automatically, so you only see what works.

New to Claude Code? Try /powerup — it runs interactive lessons with animated demos that walk you through key features right inside the CLI.

Some commands accept arguments directly: /compact focus on the API layer, /model opus, /effort high, /rename auth-refactor. Others like /context, /cost, and /status run immediately with no arguments.

/compact focus on the payment service

Command Categories

Built-in commands group into a few categories. Knowing the categories helps you find the right command without memorizing all of them.

Context Management

These commands control how much of the conversation Claude can see.

• /context — shows a visual grid of your context usage
• /compact — compresses the conversation. Pass instructions to control what’s preserved: /compact keep the migration plan, drop the debugging
• /clear — starts completely fresh

Session Tools

These commands let you manage and revisit work.

• /rename my-feature — gives the session a readable name
• /resume — picks up a previous session
• /branch — creates a parallel conversation to explore an alternative without losing your current state
• /rewind — rolls back to an earlier point. /undo is an alias for /rewind.
• /export — saves the session to a file or clipboard
• /recap — generates a one-line summary of what happened in the session. Also runs automatically when you return to the terminal after stepping away.

Configuration

These commands adjust Claude’s behavior mid-session.

• /model — switches between available models such as Sonnet, Opus, Haiku, and other aliases like best or opusplan
• /effort — sets reasoning depth: low, medium, high, xhigh, max (session-only), or auto
• /permissions — manages what Claude can do without asking
• /config — opens the settings menu
• /theme (new in v2.1.118) — creates and switches between named custom themes. Themes are stored as JSON files in ~/.claude/themes/ and can also be hand-edited directly.
• /tui — switches between classic and flicker-free fullscreen rendering mid-conversation. Also available as a tui setting.
• /focus — toggles focus view for distraction-free input.
• /fewer-permission-prompts — scans your recent transcripts for common read-only Bash and MCP tool calls, then proposes an allowlist to add to .claude/settings.json to reduce future permission prompts.

Diagnostics

These commands help when something isn’t working.

• /cost — shows session cost, duration, code changes, and token usage
• /usage-credits (new in v2.1.144) — view and manage usage credits on your account. Renamed from /extra-usage; the old name still works.
• /status — shows version, model, and account info
• /doctor — checks installation health
• /diff — opens an interactive viewer for uncommitted changes, useful for reviewing what Claude has done before committing

Pre-Ship Reviews

These commands check your work before it leaves your branch.

• /code-review — reviews the current diff for correctness bugs and reports findings without editing files. Accepts an effort level (/code-review high returns broader coverage; /code-review low returns fewer, higher-confidence findings) and --comment to post findings as inline comments on the current GitHub PR. Pass a path or PR reference to review a specific target. This is the bundled skill (formerly /simplify before v2.1.147); /code-review --fix applies the findings to your working tree. From v2.1.154, /simplify is a separate cleanup-only skill that applies fixes without hunting for bugs — use /code-review to find bugs.
• /code-review ultra — runs a deep, multi-agent code review in a cloud sandbox using parallel analysis and critique. With no arguments it reviews your current branch; pass a PR number (/code-review ultra 123) to fetch and review a GitHub PR. /ultrareview is an alias. Pro and Max include a few free runs, after which it draws on usage credits.
• /review — read-only deeper pass on the change set
• /security-review — security-focused review of pending changes

/context
/compact keep the auth refactor plan
/model opus
/effort high
/cost
/code-review high
/code-review --comment

Real-World Code Examples: Slash Commands

Example 1: Git Commit Command

A slash command that automatically creates conventional commits using live git context:

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*)
argument-hint: [message]
description: Create a git commit with context
---

## Context

- Current git status: !`git status`
- Current git diff: !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -10`

## Your task

Based on the above changes, create a single git commit.
If a message was provided via arguments, use it: $ARGUMENTS
Otherwise, analyze the changes and create an appropriate commit message
following conventional commits format (feat:, fix:, docs:, refactor:, test:, chore:).

Example 2: Code Optimization Analyzer

A skill that reviews code for performance issues and suggests optimizations:

---
description: Analyze code for performance issues and suggest optimizations
---

# Code Optimization

Review the provided code for the following issues in order of priority:

1. Performance bottlenecks - identify O(n-squared) operations, inefficient loops
2. Memory leaks - find unreleased resources, circular references
3. Algorithm improvements - suggest better algorithms or data structures
4. Caching opportunities - identify repeated computations
5. Concurrency issues - find race conditions or threading problems

Format your response with:
- Issue severity (Critical/High/Medium/Low)
- Location in code
- Explanation
- Recommended fix with code example

Example 3: Pull Request Preparation

A comprehensive slash command for PR preparation with restricted tool access:

---
description: Clean up code, stage changes, and prepare a pull request
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(npm test:*), Bash(npm run lint:*)
---

# Pull Request Preparation Checklist

1. Run linting: prettier --write .
2. Run tests: npm test
3. Review git diff: git diff HEAD
4. Stage changes: git add .
5. Create commit message following conventional commits
6. Generate PR summary including what changed, why, testing, and impacts

Pro Tips

• Use skills over legacy commands. Skills (.claude/skills/) support directory structure, auto-invocation, and bundled reference files. Legacy .claude/commands/ still works but skills are the current standard.
• Always include trigger terms in your description. A description like “Fix lint errors” is too vague. Write “Run the linter, parse errors, and fix all reported issues. Use when the user mentions linting, code style, or ESLint.” — this helps Claude auto-invoke when appropriate.
• Use disable-model-invocation: true for side-effect commands. Commands like /deploy or /commit should never be auto-triggered by Claude. This frontmatter field ensures only the user can invoke them.
• Inject dynamic context with !`command`. Rather than hardcoding state, use shell substitutions like !`git status` or !`git log --oneline -5` so Claude always sees current repository state.
• Keep each command focused on one task. A /commit command should only commit. If you also need pushing, create a separate /push-all command. Single-responsibility commands are easier to maintain and compose.

Hands-On Challenge: Build Your First Custom Slash Command

Task: Create a custom /lint-check slash command (as a skill) that runs your project’s linter, reports errors, and asks Claude to fix them automatically.

Steps

1. Create the directory .claude/skills/lint-check/ in your project
2. Add a SKILL.md file with YAML frontmatter (name: lint-check, a clear description, and allowed-tools: Bash(npm *))
3. In the body, instruct Claude to: (a) run your linter with dynamic context via !`npm run lint 2>&1`, (b) parse the output, (c) fix each error, and (d) re-run the linter to confirm a clean pass
4. Save the file and invoke /lint-check in a new Claude Code session
5. Verify Claude runs the linter, reads the output, and proposes fixes

Expected Outcome

Typing /lint-check should trigger Claude to run your linter, display the results, and offer to fix any reported issues — all without you pasting lint output manually.

Hint: Use the !`command` syntax in your SKILL.md body to inject live shell output. For example: - Lint output: !`npm run lint 2>&1`. Claude sees the result, not the command.

Knowledge Check: Slash Commands in Claude Code

Test your understanding with these quiz questions. Try to answer each question before revealing the answer.

1. What are the four types of slash commands in Claude Code?

1. Built-in, skills, plugin commands, MCP prompts
2. Built-in, custom, hook commands, API prompts
3. System, user, plugin, terminal commands
4. Core, extension, macro, script commands

Correct Answer: A. Claude Code has built-in commands (like /help, /compact), skills (SKILL.md files), plugin commands (namespaced plugin-name:command), and MCP prompts (/mcp__server__prompt).

2. How do you pass all user-provided arguments to a skill?

1. Use ${args}
2. Use $ARGUMENTS
3. Use $@
4. Use $INPUT

Correct Answer: B. $ARGUMENTS captures all text after the command name. For positional args, use $0, $1, etc.

3. How do you inject live shell output into a skill’s prompt?

1. Use $(command) syntax
2. Use !`command` (backtick with !) syntax
3. Use @shell:command syntax
4. Use {command} syntax

Correct Answer: B. The !`command` syntax runs a shell command and injects its output into the skill prompt before Claude sees it.

4. What is the correct directory structure for a new custom skill called “deploy”?

1. .claude/commands/deploy.md
2. .claude/skills/deploy/SKILL.md
3. .claude/skills/deploy.md
4. .claude/deploy/SKILL.md

Correct Answer: B. Skills live in a directory under .claude/skills/ with a SKILL.md file inside. The directory name matches the command name.

5. How do plugin commands avoid name conflicts with user commands?

1. They use a plugin-name:command-name namespace
2. They have a special .plugin extension
3. They are prefixed with p/
4. They override user commands automatically

Correct Answer: A. Plugin commands use a namespace like pr-review:check-security to avoid conflicts with standalone user commands.

Additional Resources

Claude Code Slash Commands gives you a solid, repeatable workflow. Bookmark this Claude Code Slash Commands guide and revisit the steps whenever you need them.

Building a Custom Slash Command: A Step-by-Step Walkthrough

The fastest way to understand Claude Code Slash Commands is to build one. This walkthrough creates a /pr-prep command that stages changes, runs your test suite, and drafts a commit message — the kind of repetitive pre-ship routine that’s worth turning into a reusable command instead of retyping every time.

1. Create the skill directory. Skills live under .claude/skills/, one directory per command. Run mkdir -p .claude/skills/pr-prep inside your project root.
2. Write the SKILL.md file. Inside that directory, create SKILL.md with YAML frontmatter describing the command and the tools it’s allowed to touch:

   ---
   name: pr-prep
   description: Stage changes, run tests, and draft a commit message before opening a PR. Use when the user mentions shipping, preparing a PR, or wrapping up a change.
   allowed-tools: Bash(git add:*), Bash(git status:*), Bash(npm test:*)
   argument-hint: [scope]
   ---

3. Inject live repository state. Below the frontmatter, use the !`command` syntax so the command always sees current state instead of a stale snapshot:

   ## Context
   - Git status: !`git status`
   - Test results: !`npm test 2>&1`
   
   ## Task
   Stage the relevant files, and if $ARGUMENTS was provided, scope the commit to that area. Draft a conventional-commit message summarizing the change.

4. Pass arguments for reuse. $ARGUMENTS captures whatever text follows the command name, so /pr-prep auth module scopes the routine to a specific area without editing the file.
5. Test it in a fresh session. Start a new Claude Code session in the project, type /pr-prep, and confirm it appears in the menu — Claude Code Slash Commands built as skills are picked up automatically, no restart or registration step required.
6. Restrict side effects deliberately. Because allowed-tools only grants git add, git status, and npm test, the command physically cannot run git commit or git push on its own — you stay the one who approves the final commit.

If the command doesn’t appear in the / menu, the most common cause is a missing or malformed frontmatter block — SKILL.md requires the opening and closing --- delimiters, and a broken YAML value silently drops the command instead of raising an error. Run claude doctor to confirm your skills directory is being read correctly.

Once the command works, commit .claude/skills/pr-prep/ to git so the rest of the team gets the same shortcut. This is the general pattern behind every custom slash command: a directory, a frontmatter block that scopes tools and describes intent, and a body that mixes live shell context with instructions — the same shape used by the built-in /code-review and /security-review commands referenced earlier in this guide.

Claude Code Slash Commands: Common Mistakes to Avoid

Even experienced developers trip over the same issues when they start with Claude Code Slash Commands. Watch for these and you will save real debugging time.

• Forgetting that custom skills appear as slash commands, and re-typing the same long prompt instead of saving it.
• Hard-coding values that should be arguments, which makes a command far less reusable across tasks.
• Installing plugin commands without reading what they execute, which is a security and reliability risk.
• Letting command output dump entire files when a focused diff would be faster to review and safer to apply.

Claude Code Slash Commands: Best Practices

• Type / to discover available commands, skills, and plugin commands in context.
• Group reusable prompts into custom skills instead of pasting the same instructions repeatedly.
• Pass arguments to commands to make them dynamic rather than hard-coding values.
• Namespace plugin commands clearly so they never collide with built-ins.
• Document your custom commands in CLAUDE.md so teammates can reuse them.

Claude Code Slash Commands: Frequently Asked Questions

What’s the difference between a skill and a legacy command?

Both appear as Claude Code Slash Commands in the / menu, but skills (.claude/skills/) support directories, auto-invocation, and bundled reference files, while legacy commands (.claude/commands/) are single markdown files without those extras.

Can Claude invoke a slash command automatically?

Yes, if the description field describes when to use it and disable-model-invocation isn’t set to true. Side-effect commands like /deploy should set that field so only a human can trigger them.

How many arguments can a command accept?

As many as you pass after the command name. $ARGUMENTS captures everything as one string, or use $0, $1, and so on for positional access to individual arguments.

Do plugin slash commands ever collide with my own?

No — plugin commands are namespaced as plugin-name:command, so a plugin’s /review command never overwrites a project’s own /review command.

Where should I store commands I want the whole team to use?

In .claude/skills/ or .claude/commands/ inside the project, then commit them to git — anyone who clones the repository gets the same commands immediately.