Slash commands are the fastest way to control a Claude Code session without writing a sentence of prompt. Type /clear and the context resets. Type /model and you switch models mid-session. Type /review — if you have built one — and a full code review kicks off with your team's exact standards baked in. They are shortcuts, but they are also programmable: anyone can define new ones as plain markdown files.
This guide covers every commonly used built-in command, how custom commands actually work under the hood, and where they fit next to hooks, skills, and subagents — the other three ways to extend Claude Code.
Built-In Slash Commands
These ship with Claude Code and work in any project:
/clear— wipes the conversation and starts a fresh context window. Use this between unrelated tasks so old context doesn't bleed into new work./compact— summarizes the current conversation to free up context space without losing the thread entirely. Slower and lossier than/clear, but keeps continuity./model— switches the active model for the session (for example, moving from a fast model to a more capable one for a hard refactor)./agents— lists available subagent types, both built-in and custom, defined in.claude/agents/./hooks— shows configured hooks and which events they fire on./mcp— lists connected MCP servers and their tools./permissions— reviews or adjusts what the current session is allowed to do without asking./cost— shows token usage and spend for the session so far./init— generates a starterCLAUDE.mdfor a project by scanning its structure./memory— opens the project or user memory files for editing./doctor— diagnoses installation and configuration problems./bug— files feedback directly from inside a session./help— lists every available command, built-in and custom, for the current project.
None of these require you to write a prompt. That is the entire point — a slash command is a zero-ambiguity trigger for a specific, repeatable action.
Custom Slash Commands: How They Work
A custom command is a markdown file. Drop one in .claude/commands/review.md and /review becomes available in that project. The body of the file is the prompt that gets sent to Claude when the command runs — nothing more exotic than that.
---
description: Review the current diff against team standards
allowed-tools: Read, Grep, Glob
---
Review the currently staged git diff. Check for:
- Missing error handling at system boundaries
- Unnecessary abstractions for one-time logic
- Inconsistent naming vs. the surrounding file
Report findings as a bulleted list, most severe first.
The frontmatter is optional but does real work. description is what shows up in /help and command autocomplete. allowed-tools restricts what that specific command is permitted to touch — a review command that should never write files can be scoped to Read, Grep, Glob only, and no amount of clever prompting inside the command body can override that restriction.
Passing Arguments with $ARGUMENTS
Commands can accept input at call time using the $ARGUMENTS placeholder:
---
description: Investigate a specific bug report
---
Investigate this bug: $ARGUMENTS
Start by searching for related error messages, then check
recent commits that touched the affected files.
Running /investigate login button does nothing on Safari substitutes that entire string in for $ARGUMENTS. This turns a command file into a reusable template rather than a single hardcoded prompt — one file, unlimited inputs.
Project vs. Personal Scope
Commands in a project's .claude/commands/ directory are checked into the repo and shared with every teammate who clones it — the whole team gets /review, /deploy-check, or whatever standard workflows the project needs. Commands in the user-level config directory are personal: they follow you across every project, regardless of which repo you're in. Use project scope for anything that encodes team or repo-specific standards. Use personal scope for habits that are yours alone — a personal /summarize-day command has no business living inside a shared repo.
Slash Commands vs. Hooks vs. Skills vs. Subagents
These four extension points get confused constantly because they all live under .claude/, but they solve different problems:
- Slash commands are explicit, user-triggered prompts. You type them on purpose, every time.
- Hooks are automatic shell commands that fire on lifecycle events (a tool call, a session start) — no typing required, they just run.
- Skills are capabilities Claude decides to load on its own, based on relevance to the current task — you don't invoke them directly.
- Subagents are delegated, isolated agent loops — used when a task needs its own context window, not just its own prompt.
If you find yourself typing the same multi-paragraph prompt more than twice, that is the signal to turn it into a slash command. If you find yourself wanting something to happen automatically without typing anything, that's a hook. If you want Claude to reach for a capability on its own, that's a skill.
Practical Commands Worth Building
A few patterns pull their weight in almost any codebase:
/commit— stages relevant files, drafts a commit message from the diff, and stops short of pushing./pr-review— pulls a PR's diff and comments, and checks it against a fixed rubric./test-failing— runs the test suite, isolates failures, and proposes fixes for each one without touching passing tests./onboard— walks a new contributor's session through the repo's structure, using$ARGUMENTSfor the area they're starting in.
None of these are complicated to build. The value is in never having to retype the setup again.