Claude Code Slash Commands: A Practical Guide

Claude Code slash commands are the fastest way to steer a coding session without leaving the prompt. Type a forward slash, pick a command, and you can clear the conversation, switch models, kick off a project setup, or run a workflow you defined yourself. If you spend your day in Claude Code (Anthropic's agentic coding CLI and IDE tool), learning the slash command system pays for itself almost immediately. This guide walks through the built-in commands and how to write your own custom commands as markdown files. Claude Drops is an independent project and is not affiliated with Anthropic.

What are Claude Code slash commands?

A slash command is a special instruction you type at the start of the Claude Code prompt, beginning with a /. A command is only recognized at the start of your message; any text after the command name is passed to it as arguments. Instead of being sent to the model as ordinary text, a command triggers specific behavior: some act on the session directly (like clearing history), while others expand into a prompt the model then acts on. Start typing / and Claude Code shows an autocomplete menu of everything available, both the built-ins and any custom commands it discovers in your project.

Claude Code slash commands matter because a coding session has state: a growing context window, a selected model, a working directory, and the task at hand. They give you precise, low-friction control over that state, so you spend less time re-typing boilerplate and more time shipping. For the exact, current list of built-ins, always defer to the official Claude Code documentation, since the set evolves between releases.

Built-in slash commands

Claude Code ships with a large set of built-in slash commands that cover common session-management needs. Rather than over-specify an exact list (it changes across releases, see the Claude Code changelog), it helps to think of them in a few broad categories. The official docs include a full commands reference with every command and its arguments.

Managing context

The single most useful habit is resetting your context between unrelated tasks. There's a command to clear the conversation and start fresh, dropping accumulated history that's no longer relevant, which both sharpens responses and reduces token usage. There's also a compact command that summarizes a long conversation in place when you want to free up context but keep going. When you switch from, say, debugging an API route to writing documentation, clearing or compacting first keeps the model focused on the new task instead of dragging along stale details.

Switching the model

Claude Code lets you change which Claude model is handling the session on the fly. A lightweight model is great for quick edits and fast iteration; a more capable model is worth it for gnarly refactors, architecture decisions, or tricky debugging. A slash command makes that switch instant, so you can match the model to the difficulty of the moment instead of committing to one for the whole session. Some models also let you tune an effort level from the same picker.

Getting help and initializing a project

There's a help command that lists what's available and explains usage, your first stop when you're unsure. There's also an initialize command that scaffolds a CLAUDE.md file by scanning your repository, capturing conventions, architecture notes, and commands so future sessions start with shared context. Running it once on a new project is one of the highest-leverage things you can do.

Beyond these, built-ins cover things like reviewing changes, managing permissions and configuration, signing in and out, inspecting cost or usage, and visualizing how your context window is being spent. The exact names and arguments belong in the docs, not your memory.

Custom slash commands

The real power shows up when you write your own. Custom slash commands in Claude Code are just markdown files. Drop a file into a commands directory and Claude Code turns it into a slash command whose body becomes a reusable prompt. This is perfect for any workflow you run repeatedly: a code review checklist, a PR description generator, a test-writing routine, or a release-notes drafter.

Project vs. personal commands

There are two homes for custom commands. Project commands live in .claude/commands/ inside a repository, so you can commit them and your whole team shares the same workflows. Personal commands live in your home directory under ~/.claude/commands/ and follow you across every project. Use project commands for team conventions and personal commands for your own habits.

Creating your first command

To make a command called /review, create a file named review.md: the filename (without the extension) becomes the command name. The markdown body is the prompt that runs when you invoke it.

# from your project root
mkdir -p .claude/commands
cat > .claude/commands/review.md <<'EOF'
Review the staged changes for correctness, edge cases,
and security issues. Group findings by severity and
suggest concrete fixes. Be concise.
EOF

Now typing /review runs that prompt. Commands can also accept arguments you pass after the name. Claude Code substitutes the full argument string into the $ARGUMENTS placeholder in the prompt body, which is handy for templating things like an issue number or a filename. Claude Code also supports per-command YAML frontmatter (for a description and other options). The official docs have the precise syntax, which is worth copying exactly rather than guessing.

# Example: a command that takes an argument
# file: .claude/commands/fix-issue.md

Fix issue $ARGUMENTS. Read the linked issue, reproduce
the bug, write a failing test, then make it pass.

# usage:  /fix-issue 482

Tips for good custom commands

• Keep each command focused on one job. Small, composable prompts beat one giant catch-all.
• Write the body as if briefing a teammate: state the goal, the constraints, and the output you want.
• Commit project commands to version control so the whole team benefits and they stay in sync.
• Name commands by the verb you'll reach for, like /test, /review, or /release, so they're easy to recall.
• Use $ARGUMENTS for the parts that change (an issue number, a path) and hardcode the parts that don't.

Slash commands and skills

Claude Code also has skills, and the relationship between the two has been converging. A skill is a packaged capability (a SKILL.md with instructions, and optionally scripts and supporting files) that you can invoke by typing /skill-name, and that Claude can also load on its own when a task matches its description. The official docs note that custom commands have effectively merged into skills: the same /name can come from a command file or a skill directory.

The useful mental model is who you want to invoke it. For a workflow you want to run on demand with deterministic timing (a deploy, a commit, a release routine), you typically restrict it to manual invocation so Claude won't trigger it automatically. For background knowledge or expertise you'd rather Claude apply whenever it's relevant, you let it be model-invocable. Claude Code exposes frontmatter options to control exactly this. If you're going deeper, our companion guides on Claude Code skills and Claude Code hooks cover when each one fits best.

Putting it together

A productive Claude Code setup usually combines all of it: built-in commands to manage context and models, a handful of custom commands in .claude/commands/ (or skills) for your team's recurring workflows, and model-invocable skills for expertise you'd rather Claude reach for on its own. Start small. Add one custom command for the thing you re-type most often, commit it, and grow from there.

Claude Code's command set keeps expanding with each release, so it's worth watching what changes. Browse the Claude Code changelog to see new commands and capabilities as they land, or get the Claude Drops app for a push notification the moment a new Claude Code release ships. For exact, current syntax, the official Claude Code docs are always the source of truth.