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

  1. 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.md
  2. Create 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.md
  3. Inspect discovery

    Start Claude Code with project settings and inspect `/help`; this UI check is documentation-based in this audit.

  4. 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.

/mcp

Connect external tools when repository files are not enough.

Read guide

Task 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.

CommandDescription
/initGenerate a starter CLAUDE.md for the repository.
/memoryEdit durable project memory and instructions.
/planSwitch into plan mode before large edits.
/contextInspect what is filling the context window.
/compactSummarize the conversation to free context space.
/diffOpen an interactive diff viewer for current changes.
/code-reviewReview the diff for bugs, cleanup, and security issues.
/rewindRoll code and conversation back to a checkpoint.
/doctorRun 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.

CommandDescription
/tasksList background work and finished subagents in the session.
/backgroundDetach the session so it keeps running in the background.
/batchDecompose a large change into parallel worktree-based units.
/branchFork the conversation to try a different direction.
/resumeReturn to an earlier conversation or branch.

Slash command checklist

Related topics