Slash Commands | Operating Manual

Slash commands are special / prefixed instructions you type at the prompt to control session state or trigger repeatable workflows. Built-ins handle housekeeping (clearing context, switching models, managing MCP servers), while custom commands let you codify any prompt you run repeatedly into a single invokable name.

Custom commands are just markdown files. The filename becomes the command name. When you run the command, Claude reads the file as its prompt, so everything you know about writing good prompts applies here.

How you use it day-to-day

Reset context fast. /clear wipes the conversation and starts fresh. /compact compresses history to save tokens while keeping the key context. Use it before a long coding stretch.
Switch models mid-session. /model lets you change the active Claude model without restarting. Useful when you want a cheaper model for a grunt task, then back.
Surface what's available. /help lists every command (built-in and custom) and /permissions shows what tools are currently allowed.
Ask a side question without derailing the run. /btw (or Cmd/Ctrl+; on desktop) opens a side chat while Claude is still working. Type your question, get a one-shot answer in an overlay, dismiss it, and the main response keeps generating with its context untouched. It reuses the prompt cache, so the aside costs almost nothing.
Create a project command. Drop a .md file in .claude/commands/, e.g. .claude/commands/review.md, and /review appears for everyone on the project. Check these into git so the team shares them automatically.
Create a personal command. Put the file in ~/.claude/commands/ instead, and it travels with you across all projects.
Shepherd a PR with built-in skills. /simplify cleans up a change for reuse and readability without hunting for bugs; /batch runs a set of edits across many targets. Boris Cherny (Claude Code's creator) flagged both as daily drivers for taking a pull request to production. See also Skills.
Lock down a command's tools. Add frontmatter to restrict what the command can touch: allowed-tools: Read, Grep, Glob. Good discipline for commands that should never write.
Inject live context. Prefix a shell expression with ! inside the command file to run it at invocation time, e.g. !`git diff HEAD` injects the current diff before Claude sees the prompt. Use @filename to inline a file's contents the same way.
Pass arguments. Use $ARGUMENTS (all args as one string) or $1, $2, ... (positional) inside the file. Set argument-hint in frontmatter to remind yourself what to pass.

Gotchas

Filename = command name. Rename or move the file and the command changes with it. Subdirectories are fine for organization but don't affect the command name; only the file stem does.
No output preview before run. The ! shell expansions happen at invocation; you don't see what they produce until Claude responds. Keep them side-effect-free (reads, not writes).
Project overrides user. If .claude/commands/foo.md and ~/.claude/commands/foo.md both exist, the project-level one wins. Be deliberate about where you put shared commands.
/btw is a single-shot aside. One question, one answer, no follow-ups in that thread, and it has no tool access; it answers from the existing conversation only. For anything that needs tools or back-and-forth, use the main prompt, not the side chat.
/config and /vim are session-only toggles. They don't persist to your settings.json. Use /update-config or edit the file directly for permanent changes.

Team tip: the highest-ROI commands to write first are the ones you already run by pasting the same prompt repeatedly: code review, changelog generation, migration scaffolding. If you've typed it more than three times, make it a command.