Claude Code slash commands
Slash commands control a running Claude Code session. They are most useful when you want predictable transitions: setup, planning, context inspection, review, parallel execution, or recovery.
- Last verified
- Applies to
- Claude Code 2.1.x. CLI spellings were checked on local version 2.1.198; official docs may describe newer 2.1.x behavior.
- Verification method
- The current Commands and Skills pages were reviewed. The former slash-commands URL now resolves to Skills because custom commands are merged into skills; interactive invocation was not exercised.
- Official sources
- Commands referenceSkillsChangelog
Reproducible practice
Audit a project command before migrating it to a skill
Preserve an existing command while proving its name, scope, inputs, and tool boundary in a disposable repository.
Prerequisites
- A POSIX shell and a disposable temporary directory.
- No production command files or secrets in the fixture.
- Claude Code available for an optional `/help` inspection.
Steps
Create an isolated legacy command
Use a unique temporary repository so no real project command is changed.
Step 1 COMMAND_LAB=$(mktemp -d "${TMPDIR:-/tmp}/claude-command.XXXXXX") printf '%s\n' "$COMMAND_LAB" cd "$COMMAND_LAB" && git init -q mkdir -p .claude/commands printf '%s\n' 'Summarize git status and do not edit files.' > .claude/commands/status-check.mdCreate the skill form beside it
Use explicit frontmatter and a new name to avoid an ambiguous collision.
Step 2 mkdir -p .claude/skills/status-audit printf '%s\n' '---' 'description: Report repository status without editing files.' 'disable-model-invocation: true' 'allowed-tools: Bash(git status --short)' '---' '' 'Run git status --short and summarize the result.' > .claude/skills/status-audit/SKILL.mdInspect discovery
Start Claude Code with project settings and inspect `/help`; this UI check is documentation-based in this audit.
Retire only after parity
Invoke `/status-audit` in the disposable repo, verify no edit occurred, then remove the legacy fixture only if behavior matches.
Expected result
The legacy command remains available during comparison and the new skill has a distinct name, explicit invocation control, and a narrow tool contract.
Validation
- Parse frontmatter visually and confirm the directory-derived command name.
- Run `git status --short` before and after the optional invocation.
- Use `/help` to distinguish built-in commands, bundled skills, and project skills.
Failure handling
Skill is missing
Check the `SKILL.md` filename, directory scope, description, and workspace trust.
Names collide
Rename the skill before deleting the legacy command; do not rely on undocumented precedence.
Cleanup or rollback
- Return to the original directory and remove only the printed COMMAND_LAB path.
- Keep the original command until the skill passes the same acceptance check.
Boundaries and when not to use it
- Custom commands remain compatible, but new reusable procedures should use skills.
- Skills are prompt content, not a hard security boundary; permissions and hooks still govern tools.
Setup commands
Early in a repository, commands such as initialization, memory editing, MCP setup, and permission configuration help establish the operating rules before code changes begin.
/init and /memory
Seed and refine project instructions before broad edits.
Read guide/mcp
Connect external tools when repository files are not enough.
Read guide/permissions
Set allow, ask, and deny rules for the repository.
Read guideGetting started
Complete first-session setup in a real repo before large changes.
Read guideTask control commands
During implementation, commands for planning, model selection, effort level, context inspection, and compaction help keep long sessions readable and intentional.
Review commands
Before shipping, diff and code review commands help inspect what changed. They are not a replacement for tests, but they make it easier to catch logic issues, cleanup opportunities, and security-sensitive changes.
Recovery commands
Recovery commands are useful when a session drifts, a change is too broad, or context becomes overloaded. Rewind, clear, resume, and branch-style workflows help regain control without losing all prior work.
High-value slash commands
These commands appear throughout a typical workflow: setup at the start, planning during implementation, review before shipping, and recovery when something goes wrong.
| Command | Description |
|---|---|
/init | Generate a starter CLAUDE.md for the repository. |
/memory | Edit durable project memory and instructions. |
/plan | Switch into plan mode before large edits. |
/context | Inspect what is filling the context window. |
/compact | Summarize the conversation to free context space. |
/diff | Open an interactive diff viewer for current changes. |
/code-review | Review the diff for bugs, cleanup, and security issues. |
/rewind | Roll code and conversation back to a checkpoint. |
/doctor | Run setup diagnostics and apply fixes when needed. |
Parallel and background work
Slash commands also control subagents, background sessions, and large parallel changes across the codebase.
| Command | Description |
|---|---|
/tasks | List background work and finished subagents in the session. |
/background | Detach the session so it keeps running in the background. |
/batch | Decompose a large change into parallel worktree-based units. |
/branch | Fork the conversation to try a different direction. |
/resume | Return to an earlier conversation or branch. |
Slash command checklist
Use setup commands first
Initialize memory, permissions, and integrations before asking Claude Code to perform large edits.
Read guideInspect context during long work
Use context and compaction commands when the session becomes long or starts losing focus.
Read guideReview before handoff
Run diff or review commands before treating a change as ready for commit or pull request.
Read guideRecover instead of restarting
Try rewind, branch, or compact before abandoning a long session entirely.
Read guide