Every time you re-type the same prompt in Claude Code — “review this diff for bugs,” “write a commit message for these changes,” “run the tests and tell me what broke” — you’re leaving one of the tool’s most powerful features completely unused. Claude Code has a full system for turning repeated prompts into one-keystroke workflows. Built-in slash commands give you instant control over your session. Custom commands let you save any prompt as a reusable shortcut. And skills take that further still, auto-detecting the right workflow to load based on what you’re asking without you having to type anything at all.
The gap between beginners and power users in Claude Code often comes down to this one system. Beginners use Claude Code like a chat window — new prompt, new response, repeat. Power users have built a personal library of commands and skills that turns their most common workflows into six-keystrokes. This guide shows you the full picture: what slash commands are, which built-in commands matter most, how to build your own, and when to upgrade from a simple command to a full skill. By the end, you’ll have everything you need to stop typing the same things twice.
## 📋 TL;DR
– Slash commands are typed shortcuts inside a Claude Code session — type
/and a command name to trigger them instantly.
– Built-in commands ship with Claude Code and handle session management: clearing context, checking costs, switching models, entering Plan Mode, and more.
– Custom commands are Markdown files you create in.claude/commands/— the filename becomes the command name. Any prompt you type repeatedly is a candidate.
– Skills are the newer, more powerful version of custom commands. They live in.claude/skills/, can auto-trigger without you typing anything, and support supporting files, arguments, and permission scoping.
– Thedescriptionfield in a skill’s frontmatter is what triggers auto-invocation — vague descriptions mean the skill never fires automatically.
– Custom commands and skills both live at two levels: project-level (shared with your team via Git) and personal-level (~/.claude/, applies to all your projects).
– Start with custom commands for simple prompt shortcuts. Graduate to skills when you need auto-triggering, multiple files, or permission control.
Table of Contents
- What Are Slash Commands — And Why Do They Matter?
- The Built-in Commands You’ll Use Every Day
- Custom Commands — Save Any Prompt as a Shortcut
- Skills — The Smarter Evolution of Custom Commands
- How to Write a SKILL.md File
- Commands vs Skills — When to Use Each
- Real Examples — Commands and Skills Worth Building Now
- Common Beginner Mistakes and How to Fix Them
- Quick Reference Cheatsheet
- What to Learn Next
- Key Takeaways
What Are Slash Commands — And Why Do They Matter?
A slash command is a shortcut you type inside a Claude Code session. You start with a forward slash (/), type a command name, and press Enter. An autocomplete menu appears as soon as you type / — it shows every available command and filters as you keep typing.
There are three types of slash commands in Claude Code, and understanding the difference matters:
Built-in commands are hardcoded into Claude Code itself. They run fixed logic — things like clearing your conversation, compressing context, or switching the AI model. They don’t use tokens and execute instantly. Examples: /clear, /compact, /plan, /cost, /model.
Bundled skills also ship with Claude Code, but they work differently. They’re prompt-based — when you invoke them, Claude receives a detailed instruction playbook and carries out the task intelligently using its tools. They look identical to built-in commands when you type them, but under the hood they’re just very well-written prompt files. Examples: /review, /run, /verify.
Custom commands and skills are ones you create yourself. These are the subject of most of this guide — the personally built shortcuts that turn your repetitive workflows into reusable, one-line invocations.
Why does this matter? A slash command is a saved prompt — sometimes a couple of lines, sometimes a whole playbook — that you invoke by typing /name in a session. Claude reads the file, executes whatever it says, and the work happens. Every developer has prompts they type repeatedly. Every repeated prompt is wasted time and inconsistent output. A slash command fixes both: you type the prompt once, save it, and from then on a single command triggers it exactly the same way every time.
/ — showing built-in commands, bundled skills, and custom commands all listed together
What Are Slash Commands in Claude Code?
The Built-in Commands You’ll Use Every Day
You don’t need to install or configure anything to use built-in commands — they’re available the moment you open a Claude Code session. These are the ones that make a real difference in everyday use:
Context management
/clear — Wipes your entire conversation history and starts fresh. Use this when you’re switching to a completely different task and don’t want the previous session’s context bleeding into the new one. Aliases: /reset, /new.
/compact [instructions] — Compresses older parts of your conversation into a summary, freeing up context space. Use this when you’re approaching context limits on a task you want to continue. You can add focus instructions: /compact retain the authentication flow and the error messages tells Claude what to keep in detail when it summarizes. Use /compact when context usage exceeds about 80% but you want to keep working on the same task.
/context — Shows you a visual breakdown of how much of your context window is currently in use. Run this when sessions start feeling sluggish or responses feel less precise — it tells you whether context pressure is the cause.
Planning and review
/plan — Switches Claude into Plan Mode, where it maps out what it’s going to do before making any changes. Covered in depth in the How Claude Code Works guide — essential for any task touching multiple files or anything hard to reverse.
/diff — Shows you every file change Claude has made in the current session before you decide whether to commit. A fast way to audit what’s happened before you go to Git.
Cost and model control
/cost — Shows your token usage and spend for the current session. Useful if you’re on API billing. Run it periodically during long sessions to catch unexpectedly high usage before it adds up.
/model — Lists available models and lets you switch mid-session. The main options as of mid-2026: Claude Sonnet 4.6 is the everyday default — strong on most tasks. Claude Haiku 4.5 is faster and cheaper, good for mechanical tasks (formatting, simple checks). Claude Opus is for the hardest problems: complex architecture decisions, subtle multi-file bugs, deep reasoning tasks.
/effort [low|medium|high] — Controls reasoning depth. low is fast with minimal reasoning. high triggers deep reasoning for complex problems. Default is medium. Switching to low for repetitive tasks saves significant tokens without hurting output quality.
Utilities
/help — Lists every available command — built-in, bundled skills, and your custom ones. This is the source of truth for what’s actually in your version of Claude Code. Type /help rather than relying on any guide (including this one) when you need the definitive current list.
/permissions — Shows and lets you adjust what Claude is allowed to do in the current session.
/memory — Opens your CLAUDE.md file for quick editing without leaving the session.
💡 Pro Tip: The power pair for long sessions is
/contextfollowed by/compact [instructions]. Check how full your context is, then compress with explicit instructions about what to keep. The focus instructions in/compactare what separate a useful compaction from a lossy one — always include them.
[Built-in Slash Commands — Full Reference]
Custom Commands — Save Any Prompt as a Shortcut
Custom commands are the fastest way to stop re-typing prompts. The mechanism is beautifully simple: one Markdown file equals one reusable prompt. The body of the file is the text Claude reads. The filename becomes the command you type after the slash.
How to create a custom command
Step 1: Create the commands directory (if it doesn’t exist yet):
mkdir -p .claude/commands
Step 2: Create a Markdown file named after the command you want to type:
# This creates the /review command
touch .claude/commands/review.md
Step 3: Write your prompt in that file:
Review the current git diff for:
- Logic errors and edge cases
- Security vulnerabilities (injection, auth issues, data exposure)
- Performance problems (N+1 queries, missing indexes)
- Anything inconsistent with the patterns in this codebase
Provide specific line references and concrete suggested fixes.
Do not comment on formatting — the linter handles that.
That’s it. The next time you’re in a Claude Code session, type /review and Claude will execute that prompt exactly.
Two levels: project and personal
Like CLAUDE.md, custom commands work at two levels:
Project commands live at .claude/commands/ inside your repository. They’re committed to Git, so every developer on your team gets the same commands automatically. Perfect for team standards: your code review checklist, your PR description format, your deployment verification steps.
Personal commands live at ~/.claude/commands/ in your home folder. They’re available in every project on your machine, but not shared with anyone else. Use these for personal workflow preferences — your own commit message style, your debugging approach, prompts that only make sense for how you specifically work.
Passing arguments
You can make commands dynamic using $ARGUMENTS (captures everything the user types after the command name) or positional variables $0, $1, $2, and so on.
# .claude/commands/fix-issue.md
Fix GitHub issue #$0 with priority level $1.
Read the issue, understand the context, then implement the fix.
Run the tests. Write a clear commit message referencing the issue number.
This makes /fix-issue 247 high expand to “Fix GitHub issue #247 with priority level high.”
💡 Pro Tip: Build your slash command library by picking the single most-typed paragraph from your last week of sessions. Not the second-most or the one you think you’ll type a lot — the one you already type constantly. Save that one first. Run it once. If it produces what you wanted, commit it. The whole loop takes under five minutes. Then find the next-most-typed paragraph. After a week, look at
.claude/commands/and notice how much of your day is now/somethinginstead of typing.
How to Create Your First Custom Slash Command
[How to Pass Arguments to Slash Commands]
Skills — The Smarter Evolution of Custom Commands
Custom commands are great for simple prompt shortcuts. But they have one significant limitation: you always have to type them. Claude can’t decide on its own that now is the right time to run your /review command. You have to remember it exists, remember its name, and remember to invoke it.
Skills solve this. A skill can auto-trigger. When Claude detects that your request matches what a skill is designed to handle, it loads the skill’s instructions automatically — without you typing anything.
Claude matches your request against the description in each skill’s YAML frontmatter. At startup, only the name and description of every skill load into context. When your task semantically matches a description, Claude loads the full SKILL.md body and follows it.
Here’s a concrete example of what that means. You create a skill called debug-failing-tests with a description: “Use when the user runs the test suite and tests fail.” Now, in a session, you run your tests and they fail. You paste the error output and say “help.” Claude recognizes the situation, matches it against the skill description, loads your debugging playbook, and starts following it — without you typing /debug-failing-tests.
Skills also support things custom commands can’t:
- Supporting files** — a skill can include templates, example outputs, checklists, and other files in the same directory
- Permission scoping** — you can restrict which tools a skill is allowed to use
- Model and effort overrides** — run specific skills with a different model or reasoning depth
disable-model-invocation** — for destructive or expensive skills, prevent auto-triggering so they only run when you explicitly invoke them
As of Claude Code v2.1.101, custom commands (files in .claude/commands/) and skills (folders in .claude/skills/) have been unified. Both create a slash command you can type. Both support frontmatter. If a skill and a command share the same name, the skill takes precedence. Your existing .claude/commands/ files keep working without changes.
[What Are Skills in Claude Code?]
How to Write a SKILL.md File
A skill is a folder. Inside that folder is a file called SKILL.md. That file has two parts: a YAML frontmatter block at the top (between --- markers) and a Markdown body below it that contains the actual instructions Claude follows.
The basic structure
.claude/skills/code-review/
└── SKILL.md
---
name: code-review
description: "Review code for bugs, security issues, and performance problems. Use when the user asks to review, audit, or check code, or when a diff is ready for inspection."
---
## Code Review Checklist
Review the provided code or current diff for:
1. **Logic errors** — Check boundary conditions, null handling, off-by-one errors
2. **Security issues** — SQL injection, XSS, authentication gaps, secrets in code
3. **Performance** — N+1 queries, unnecessary loops, missing indexes
4. **Consistency** — Does this match the patterns used elsewhere in the codebase?
For each issue found: give the file name, line number, a clear description of the problem, and a concrete suggested fix.
Do NOT comment on formatting or style — the linter handles that.
The most important frontmatter fields
name — The command name. This determines what you type: name: code-review means you type /code-review. Keep it short, lowercase, and use hyphens for spaces.
description — This is the auto-trigger. The description field in the SKILL.md frontmatter isn’t documentation — it’s the trigger. Claude does fuzzy matching against that string when deciding whether to load the skill, so a vague description means the skill silently never fires. Write the description to lead with the trigger phrase a user would actually type. “Create, update, or list scheduled tasks” triggers reliably. “Helps with task management” does not. Include example phrasings of the requests that should fire this skill.
disable-model-invocation: true — Prevents Claude from auto-triggering this skill. Use this for any skill with destructive or expensive consequences — deployment scripts, database operations, anything you want to always invoke explicitly.
allowed-tools — Restricts which of Claude’s tools this skill can use. For a read-only code review skill, you might set allowed-tools: [Read, Grep, Glob] to make it impossible for the skill to accidentally edit files.
effort — Sets the reasoning depth for this specific skill. effort: high for architecture reviews. effort: low for commit message generation. Controls both quality and cost.
model — Overrides the session model for this skill only. Useful for setting a cheaper model for routine tasks: model: claude-haiku-4-5 for a git commit message skill that doesn’t need deep reasoning.
Where to store skills
Project skills: .claude/skills/skill-name/SKILL.md — committed to Git, shared with your team.
Personal skills: ~/.claude/skills/skill-name/SKILL.md — available in all your projects, not shared.
[How to Create a Skill (SKILL.md Guide)]
[Skill Frontmatter Explained]
Commands vs Skills — When to Use Each
Both custom commands and skills create a /command-name shortcut. The question is when to use which.
Use a custom command when:
- You want the simplest possible setup (one file, done)
- The prompt is short and never needs to auto-trigger
- You always want to invoke it explicitly — you want full control over when it runs
- You don’t need supporting files, permission restrictions, or model overrides
- It’s a personal workflow shortcut that doesn’t need to scale to a team
Use a skill when:
- You want Claude to detect when to use this workflow automatically
- The workflow has multiple steps that benefit from a detailed playbook
- You want to include supporting files (templates, checklists, example outputs)
- You need to restrict which tools the workflow can use (safety)
- You want to run this specific workflow at a different cost/speed tradeoff than your session default
- You’re building something your whole team will use and benefit from discovering automatically
A practical rule of thumb: start with a custom command. If you find yourself wishing Claude would just use it automatically when the context is right — upgrade it to a skill by converting it to a folder structure and adding proper frontmatter with a specific, keyword-rich description.
The transition is easy. Take your .claude/commands/review.md file, create a .claude/skills/review/ folder, move the content into SKILL.md, add frontmatter — and you now have a skill that Claude can invoke automatically.
[Slash Commands vs Skills — When to Use Each]
Real Examples — Commands and Skills Worth Building Now
These are the most common starting points for developers building their first command and skill library. Each one solves a real, repeated pain point.
Custom command: /commit
Generates a clear, consistent Git commit message from the current diff. Save this as .claude/commands/commit.md:
Look at the current git diff (`git diff --staged` or `git diff`).
Write a commit message following the Conventional Commits format:
<type>(<scope>): <short summary>
Types: feat, fix, docs, style, refactor, test, chore
Keep the summary under 72 characters.
Add a body paragraph if the change needs explanation.
Do not add a body if the change is self-explanatory.
Now /commit generates a properly formatted message every time. No more staring at a blank commit prompt.
Custom command: /pr
Writes a pull request description from the current branch’s commits:
Look at the commits on this branch compared to main.
Write a pull request description with:
- A one-sentence summary of what changed and why
- A bullet list of the key changes
- Any testing notes or things the reviewer should check
- Any breaking changes or migration steps required
Keep the tone direct and factual.
Skill: code-review (auto-triggering)
A full code review skill that fires automatically when you ask Claude to look at code. The key is the description — it includes the exact phrases that should trigger it:
---
name: code-review
description: "Review, audit, or check code for bugs, issues, and improvements. Use when the user asks to review code, look for bugs, check a diff, or audit a file. Do NOT use for formatting-only requests."
effort: high
allowed-tools: [Read, Grep, Glob]
---
Review the specified code or current diff for:
1. Logic errors — boundary conditions, null handling, off-by-one errors, incorrect assumptions
2. Security vulnerabilities — injection, auth bypass, sensitive data exposure, missing validation
3. Performance issues — N+1 queries, unnecessary re-renders, missing indexes, blocking operations
4. Consistency — does this match the patterns used elsewhere in this codebase?
For each issue: file name, line number, clear problem description, concrete fix.
Skip formatting and style — the linter handles that.
Rank issues by severity: Critical → High → Medium → Low.
[Creating a Code Review Slash Command]
[Creating a Git Commit Message Skill]
Common Beginner Mistakes and How to Fix Them
Mistake 1: Writing a vague skill description and wondering why it never auto-triggers
The problem: You create a skill with description: "Helps with code quality." Claude never loads it automatically. You assume auto-triggering doesn’t work.
The fix: The description is the trigger signal. Write it as if you’re telling Claude exactly which user sentences should fire this skill. “Use when the user asks to review, audit, or check code, or when a diff is ready for inspection” gives Claude concrete matching criteria. A precise description is critical — fuzzy matching against a vague string means the skill silently never fires. Rewrite your description to lead with the trigger phrases, and include specific words users actually type.
Mistake 2: Forgetting that the filename (or folder name) is the command name
The problem: You create .claude/commands/CodeReview.md and type /codereview in your session. Nothing happens.
The fix: The command name comes directly from the filename, case included. CodeReview.md creates /CodeReview. Use lowercase with hyphens for command names that are easy to type: code-review.md creates /code-review. Check your exact filename with ls .claude/commands/ if a command isn’t appearing.
Mistake 3: Not knowing whether to use a command or a skill
The problem: You look at the two options and feel paralyzed by the choice, so you don’t build anything.
The fix: Default to a custom command. One file, paste your prompt, done — you have a working shortcut in two minutes. Only upgrade to a skill when you specifically want auto-triggering, supporting files, or permission control. Most people’s first ten “should this be a command or skill?” decisions are command. Build it simple, upgrade later if you need to.
Mistake 4: Building commands for prompts you don’t actually repeat
The problem: You speculatively build a library of twenty commands for workflows you imagine you’ll use. You use three of them. The rest get ignored and clutter your /help list.
The fix: Only build commands for prompts you have already typed at least three times this week. The prompt that already exists in your muscle memory is the right candidate. A command you build speculatively is a command you’ll forget exists.
Mistake 5: Putting everything in a command when the skill’s frontmatter would help
The problem: You have a deployment command that runs destructive operations. You invoke it by accident mid-session. Something breaks.
The fix: For any command with serious consequences — deployment, database operations, file deletion — convert it to a skill and add disable-model-invocation: true to the frontmatter. This prevents Claude from ever auto-triggering it. You can also add allowed-tools: [Bash] to restrict it to only the tools it actually needs, so it can’t accidentally read files it shouldn’t. The frontmatter is a safety layer; use it for the risky stuff.
Quick Reference Cheatsheet
| **Topic** | **The answer** | ||
|---|---|---|---|
| Open command autocomplete | Type `/` inside any Claude Code session | ||
| See all available commands | `/help` | ||
| Clear conversation history | `/clear` (aliases: `/reset`, `/new`) | ||
| Compress context (keep working) | `/compact [optional: what to retain]` | ||
| Check context window usage | `/context` | ||
| Enter Plan Mode | `/plan` | ||
| View current diff | `/diff` | ||
| Check session cost | `/cost` | ||
| Switch model mid-session | `/model` | ||
| Set reasoning depth | `/effort [low\ | medium\ | high]` |
| Edit CLAUDE.md from session | `/memory` | ||
| Custom command location (project) | `.claude/commands/command-name.md` | ||
| Custom command location (personal) | `~/.claude/commands/command-name.md` | ||
| Skill location (project) | `.claude/skills/skill-name/SKILL.md` | ||
| Skill location (personal) | `~/.claude/skills/skill-name/SKILL.md` | ||
| Pass arguments to a command | Use `$ARGUMENTS` or `$0`, `$1` in the file body | ||
| Auto-trigger a skill | Write a specific, keyword-rich `description` in frontmatter | ||
| Prevent auto-triggering (safe skills) | Add `disable-model-invocation: true` to frontmatter | ||
| Restrict tools in a skill | `allowed-tools: [Read, Grep, Glob]` in frontmatter | ||
| Override model for one skill | `model: claude-haiku-4-5` in frontmatter | ||
| Override reasoning for one skill | `effort: high` (or `low`) in frontmatter | ||
| When skill and command share a name | Skill takes precedence | ||
| Verify a command exists | `ls .claude/commands/` or `ls ~/.claude/commands/` |
What to Learn Next
This guide gives you the full map. These articles go deep on each piece:
Understanding the foundations:
- What Are Slash Commands in Claude Code? — A focused explainer on what slash commands are, how the autocomplete works, and the three types.
- [Built-in Slash Commands — Full Reference] — The complete, up-to-date reference for every built-in command with detailed usage guidance.
- [Slash Commands vs Skills — When to Use Each] — A decision guide with concrete examples of when each approach is the right choice.
Building custom commands:
- How to Create Your First Custom Slash Command — Step-by-step walkthrough for building and testing your first custom command.
- [How to Pass Arguments to Slash Commands] — Everything about
$ARGUMENTS, positional arguments, and making commands dynamic.
Going deeper with skills:
- [What Are Skills in Claude Code?] — A conceptual introduction to skills: why they exist, how auto-triggering works, and what problems they solve.
- [How to Create a Skill (SKILL.md Guide)] — The hands-on guide to creating your first skill folder, writing SKILL.md, and testing auto-invocation.
- [Skill Frontmatter Explained] — Every YAML frontmatter field, what it does, and when to use it.
Real-world examples to copy:
- [Creating a Code Review Slash Command] — Build a code review command from scratch, with a complete prompt you can use immediately.
- [Creating a Git Commit Message Skill] — Build a commit message skill with auto-triggering, so Claude writes your commit messages automatically when you stage changes.
Key Takeaways
- Slash commands turn repeated prompts into reusable shortcuts.** Every prompt you type more than once is a candidate for a command. The mechanism is simple: one Markdown file, one command name. Type
/and the filename to invoke it.
- Built-in commands handle session management** — clearing context, compressing conversation history, switching models, checking costs, and entering Plan Mode. Learn the handful you’ll use daily (
/clear,/compact,/context,/cost,/model,/plan) and your sessions will run significantly smoother.
- Custom commands live in
.claude/commands/** at the project level (shared with your team via Git) or~/.claude/commands/for personal use. The filename is the command name. Keep them simple — a paragraph or two of clear instructions is usually all you need.
- Skills are the evolution of custom commands.** They live in
.claude/skills/skill-name/SKILL.md, support a YAML frontmatter block, and — most importantly — can auto-trigger based on semantic matching against theirdescription. The description field isn’t documentation; it’s the trigger signal. Write it specifically.
- Start simple, upgrade as needed.** Build a custom command first. When you find yourself wishing Claude would use it automatically, convert it to a skill with a well-crafted description. When you need safety controls on a destructive workflow, add
disable-model-invocation: trueandallowed-toolsto lock it down. The system is designed to grow with you.
Last updated: July 2026. Claude Code ships updates frequently — type /help inside any session to see the definitive list of what’s available in your exact version.