What are Claude Code slash commands?
Claude Code slash commands are commands that start with / and control Claude Code from inside a session. Type / to see every command available to you, or / plus a few letters to filter. There are two kinds: built-in commands that ship with Claude Code, like /clear, /compact and /model, and custom commands you write yourself.
Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Old command files keep working, but the official docs recommend skills for new work. This guide covers the built-ins worth knowing, then how to write your own.
Built-in commands that matter
There are dozens of built-in commands. These are the ones most people use every week. The full list is in the commands reference.
| Command | What it does |
|---|---|
/init |
Generate a starter CLAUDE.md from your codebase |
/memory |
Edit CLAUDE.md files and turn auto memory on or off |
/clear |
Start a new conversation with empty context. Aliases: /reset, /new |
/compact [instructions] |
Summarize the conversation to free context, optionally with a focus |
/context |
Show what is filling the context window |
/btw [question] |
Ask a side question without adding it to the conversation |
/plan [description] |
Enter plan mode, optionally starting on a task |
/model [model] |
Switch the model |
/effort [level] |
Set how much reasoning Claude applies |
/permissions |
Manage allow, ask and deny rules |
/rewind |
Roll code and conversation back to a checkpoint. Aliases: /checkpoint, /undo |
/resume [session] |
Return to an earlier conversation |
/diff |
Review the changes in your working tree, including Claude's edits |
/code-review |
Review the current diff for bugs. Alias: /review |
/security-review |
Check your branch's changes for security problems |
/mcp |
Manage MCP server connections and sign-ins |
/hooks |
Browse configured hooks |
/skills |
List available skills |
/agents |
Points you to .claude/agents/ for creating subagents |
/plugin |
Browse and install plugins |
/usage |
Show session cost and plan usage. /cost is an alias |
/doctor |
Diagnose installation and configuration problems |
/help |
Show help and available commands |
Some entries in the official list are marked as bundled skills, such as /code-review, /debug, /loop and /simplify. They behave like skills you write yourself: a prompt handed to Claude, rather than behavior coded into the CLI.
A command only works at the start of your message. Text after the command name becomes its arguments. If you send a command while Claude is responding, it runs after the current turn, except for a few like /status and /usage that run immediately.
How do custom slash commands work?
A custom command is a skill. Each one is a folder with a SKILL.md file inside. The folder name, or the name field if you set one, becomes the command you type.
| Where you save it | Who gets it | Example command |
|---|---|---|
.claude/skills/deploy/SKILL.md |
Everyone working in this repo | /deploy |
~/.claude/skills/deploy/SKILL.md |
You, in every project | /deploy |
.claude/commands/deploy.md (older format) |
Everyone working in this repo | /deploy |
.claude/commands/frontend/component.md (older format) |
Everyone working in this repo | /frontend:component |
A plugin's skills/review/SKILL.md |
Wherever the plugin is enabled | /my-plugin:review |
The older .claude/commands/ files accept the same frontmatter as skills, except name and paths. Skills add three things command files do not have: a folder for supporting files like scripts and templates, control over whether you or Claude can trigger them, and the option for Claude to load them on its own when your request matches. If a skill and a command file share a name, the skill wins.
Create a custom command in four steps
- Make the folder:
mkdir -p .claude/skills/fix-issue
- Write
.claude/skills/fix-issue/SKILL.md:
---
name: fix-issue
description: Fix a GitHub issue by number
argument-hint: "[issue-number]"
disable-model-invocation: true
---
Fix GitHub issue $ARGUMENTS following our coding standards.
1. Run `gh issue view $ARGUMENTS` to read the issue.
2. Find the relevant code and make the smallest fix.
3. Write or update a test that covers the bug.
4. Run the tests and the linter.
5. Commit with a message that references the issue.
- Start Claude Code in the repo. Claude Code watches the skills folders and picks up new or edited skills mid-session. If the
.claude/skills/folder did not exist when the session started, run/reload-skillsonce. - Run it:
/fix-issue 123. Claude receives the instructions with123in place of$ARGUMENTS.
Commit the folder and everyone on the team gets the same command.
How do command arguments work?
Anything typed after the command name is passed in as arguments.
| Placeholder | Expands to |
|---|---|
$ARGUMENTS |
Everything after the command name, as typed |
$ARGUMENTS[0] or $0 |
The first argument |
$1, $2 |
The second, third argument, and so on |
$name |
A named argument declared in the arguments frontmatter list |
Arguments split like a shell, so wrap multi-word values in quotes: /my-skill "hello world" second makes $0 equal hello world. If you pass arguments but the file has no placeholder, Claude Code appends ARGUMENTS: <your input> to the end so Claude still sees it.
A command with positional arguments:
---
name: migrate-component
description: Migrate a component from one framework to another
argument-hint: "[component] [from] [to]"
---
Migrate the $0 component from $1 to $2.
Keep all existing behavior and tests passing.
/migrate-component SearchBar Vue React fills in all three.
Useful frontmatter fields
All fields are optional, but description is recommended because it tells Claude when the command is relevant.
| Field | Why you would use it |
|---|---|
description |
What the command does and when to use it |
argument-hint |
Shown in autocomplete, like [issue-number] |
arguments |
Names for positional arguments, used as $name |
disable-model-invocation |
true means only you can run it. Use for deploys, commits, messages to other people |
user-invocable |
false hides it from the / menu so only Claude uses it, for background knowledge |
allowed-tools |
Tools Claude can use without asking during this command, like Bash(git *) |
model |
Run this command on a specific model for the rest of the turn |
context |
fork runs the command in a subagent so its work stays out of your context |
Pull live data into a command
An !`command` placeholder at the start of a line or after a space runs a shell command before Claude sees the file, and the output replaces the placeholder. This lets a command arrive with real data already inside:
---
name: pr-summary
description: Summarize the current pull request
allowed-tools: Bash(gh *)
---
## Pull request
- Diff: !`gh pr diff`
- Comments: !`gh pr view --comments`
## Task
Summarize what this PR changes, list open review comments, and flag risks.
For several commands, use a fenced block that opens with three backticks followed by !. Administrators can turn this off with the disableSkillShellExecution setting.
Three more examples
A commit command only you can trigger:
---
name: commit
description: Stage and commit current changes with a clear message
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *) Bash(git diff *)
---
## Current changes
!`git status --short`
!`git diff HEAD`
Write a one-line commit message in the imperative, under 72 characters,
then stage and commit. If the changes cover unrelated topics, stop and
suggest how to split them.
A review command that runs in a separate context:
---
name: review-security
description: Review the current diff for security issues
context: fork
---
Review `git diff` for injection, auth and authorization flaws, secrets in
code and unsafe data handling. For each finding give the file, the line,
the risk and the fix. Report only real issues.
A release notes command with a named argument:
---
name: release-notes
description: Draft release notes since a tag
arguments: [since]
---
List commits since $since with `git log $since..HEAD --oneline`.
Group them as New, Improved and Fixed. One plain sentence per change,
written for users. Skip refactors and dependency bumps.
MCP prompts and plugin commands
Two other things show up in the / menu:
- MCP prompts. A connected MCP server can expose prompts. They appear as
/servername:promptname (MCP)and also run as/mcp__servername__promptname, for example/mcp__github__pr_review 456. - Plugin skills. Commands from plugins are namespaced with the plugin name, like
/my-plugin:review, so two plugins can ship areviewcommand without clashing.
Where to go next
If you are writing many commands, the SKILL.md guide covers how to write descriptions Claude actually picks up. The free SKILL.md generator turns any prompt into a valid skill file in your browser.
Commands are easy to lose once you have a few dozen across projects. Kipt keeps your prompts and skills in one private GitHub repo you own: paste a prompt to save it, use Promote to skill when you want it as a /command, and install every skill on a new machine with npx skills add https://github.com/<you>/<repo>.git.
Sources: Commands and Extend Claude with skills in the Claude Code docs.