commands for coding agents

Slash commands control your coding agent from inside a session. Type / and a name to switch models, clear context, review code, manage MCP servers or run a saved prompt. In Claude Code you write your own as a Markdown file, and custom commands are now part of skills. This guide covers the built-ins worth knowing and how to write your own. We checked the docs on 31 October 2026.

Quick facts

Built-in commands worth learning

Claude Code lists dozens. You do not need them all. These cover most days, grouped by job. Every one below appears in the commands reference we checked.

Control the session

Choose model, effort and mode

Review and verify code

Do big or repeated work

Extend Claude Code

Usage and account

/usage shows session cost, plan usage limits and stats, and /cost and /stats are aliases. /login, /logout, /status and /upgrade do what they say. /install-github-app and /install-slack-app set up the GitHub and Slack integrations. /terminal-setup installs a Shift+Enter binding for newlines in terminals such as the VS Code one.

Some commands in older tutorials are gone. The docs mark /pr-comments as removed in v2.1.91 (ask Claude to view PR comments directly), /vim as removed in v2.1.92 (use /config and Editor mode), and /ultraplan as removed (use plan mode). If a blog post tells you to use them, check the version.

Bundled skills vs built-in commands

The commands table marks some entries as Skill. That matters.

• Most built-in commands run fixed logic. /clear, /model and /compact do the same thing every time.
• Bundled skills are prompts. /code-review, /debug, /batch and /loop hand Claude detailed instructions and let it use its tools. They behave a bit differently on each run, and they cost tokens.
• Some run only when you call them. The docs say /verify is one, to keep long-running checks under your control.

You can switch bundled skills off with the disableBundledSkills setting. See our skills guide for how skills load.

Write your own command

The simple way

Create a Markdown file in .claude/commands/ (project) or ~/.claude/commands/ (personal). The filename becomes the command. A file at .claude/commands/deploy.md creates /deploy.

Anthropic's docs say a command file and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way, and that existing command files keep working. For new work, prefer a skill, because skills also support supporting files.

A real example

---
description: Draft a pull request description from the current branch
argument-hint: [base-branch]
disable-model-invocation: true
allowed-tools: Bash(git diff *) Bash(git log *)
---

Compare the current branch to $ARGUMENTS (default: main).

1. Run `git log --oneline` and `git diff` against that base.
2. Write a title under 70 characters.
3. Write a body with Summary, Test notes and Rollback.
4. Print it. Do not run `gh pr create`.

Run it as /pr-description main. See our PR description command in the kit for a fuller version.

Arguments

Indexed arguments use shell-style quoting, so /my-skill "hello world" second makes $0 equal hello world. If no placeholder receives an argument, Claude Code appends them as ARGUMENTS: <value>. To write a literal dollar before a digit, escape it with a backslash, as in \$1.00.

Dynamic context

A line that starts with ` ! ` and holds a shell command runs before Claude sees the prompt, and its output replaces the line. That is how a command can include git diff HEAD` without waiting for the model to run it. The docs call this dynamic context injection.

Frontmatter that matters for commands

A command file accepts the same fields as a skill, except name and paths.

Names that will not load

Claude Code refuses a command name containing a zero-width space, a control character, an unassigned or icon-font character, odd spacing, or < or >. If a command is missing from the menu, run claude --debug and search the log for [names].

Three more commands worth writing

The pull request example shows the shape. These follow the same frontmatter fields from the table above. They are our own sketches, so change the wording to fit your repository.

A fix-the-tests loop with a limit

---
description: Run the tests and fix failures, one failing test at a time
argument-hint: [test-command]
allowed-tools: Bash(npm test *) Bash(git diff *)
---

Run $ARGUMENTS (default: npm test).

If everything passes, say so and stop.
Otherwise pick the first failing test, find the cause, make the smallest fix,
and run the tests again. Stop after three failed attempts and report what
you learned. Never edit a test just to make it pass; explain if a test looks wrong.

A release-notes draft that cannot publish anything

---
description: Draft release notes from commits since the last tag
disable-model-invocation: true
allowed-tools: Bash(git log *) Bash(git describe *)
---

Find the last tag with `git describe --tags --abbrev=0`, list the commits
since then, and group them as New, Improve and Fix. One short line each.
Print the notes. Do not tag, push or publish.

An explain-this-change command for reviewers

---
description: Explain a diff for a reviewer who has not seen the code
argument-hint: [base-branch]
allowed-tools: Bash(git diff *) Bash(git log *)
---

Compare the current branch with $ARGUMENTS (default: main).
Explain in plain words what changed and why it probably changed, then list
the three riskiest edits and what to check in each. Do not suggest style changes.

Each one has the same three features that make a command safe. It has a clear stopping point, it names the tools it may use, and it says what it must not do. The release-notes command sets disable-model-invocation, so the model cannot decide to run it on its own, which is the right setting for anything near publishing.

Testing a command before you share it

A command is a small program written in English, and it deserves a small test. Before you commit one to a shared folder:

1. Run it on a clean branch where you can discard the result, and read exactly what it did.
2. Run it with no argument, with a normal argument and with a strange one, such as a branch that does not exist. A good command fails clearly.
3. Check the permission prompts. If it asks for a tool you did not list, either add it on purpose or fix the prompt.
4. Try to make it misbehave. Ask it to do the forbidden thing in the arguments, such as "and push it". It should refuse or ignore that.
5. Run it twice. The second run should give a similar result, and should not leave files or state that change the first.
6. Have a colleague run it from their machine. Missing paths and unset variables show up fast.

If a command needs more than a page of instructions, it is probably a skill with supporting files, or two commands. Split it.

Naming, folders and housekeeping

• Use verbs and short names. /review-diff beats /code-review-assistant-v2. People type these.
• Prefix by area in large teams. A folder structure such as commands/release/ groups commands, and the docs describe how nested folders appear in the menu, so check how yours renders.
• Put personal commands in your home folder and shared ones in the project, so the project does not fill with one person's habits.
• Keep a short index in the CLAUDE.md or README that lists the shared commands and what each does.
• Delete commands nobody has run in a quarter. Old commands drift from the project and teach the agent stale habits.
• Review changes to commands in pull requests, since a command can pre-approve tools for a whole team.

Other agents

Gemini CLI

Custom commands are TOML files. A file at ~/.gemini/commands/test.toml becomes /test. A file at <project>/.gemini/commands/git/commit.toml becomes the namespaced /git:commit, with subfolders turning into colons. Arguments use {{args}}, and shell output uses !{...} blocks. After creating or editing files, reload commands in the CLI.

prompt = "Please provide a code fix for the issue described here: {{args}}."

Codex

Codex has a documented list of built-in slash commands, including /init, /mcp, /review and /status, plus flags. Codex's current customisation story is skills and plugins, covered in our skills guide.

Cursor

Cursor's docs describe reusable workflows as skills, with /create-skill to make one. Skills load from .cursor/skills/, .agents/skills/, and Claude and Codex folders. [VERIFY: current status of Cursor's .cursor/commands folder]

Compatibility at a glance

Where to find commands

When you install someone else's command, read it first. Anything with allowed-tools or a shell injection line can run commands on your machine.

Habits that pay off

1. Gate side effects. Add disable-model-invocation: true to anything that deploys, commits or messages.
2. Keep commands short. Move long reference into supporting files in a skill folder.
3. Add a check. End with what to run to prove the result.
4. Name by verb. /review-pr, /fix-lint, /release-notes.
5. Share by commit. Put project commands under version control so the team gets them.
6. Audit now and then. /skill-doctor shows what each skill costs in context and how often it is used.
7. Learn the keys too. See our Claude Code cheat sheet for shortcuts and flags.

Our take

This guide is based on the documentation. We did not time or benchmark any command.

The most useful change is the merge of commands and skills. You can keep a pile of old .claude/commands/ files and they still work, then move the ones that grow into folders with supporting files. There is no migration cliff.

If you learn five built-ins, make them /clear, /compact, /context, /model and /plan. They manage the one resource you always run out of, which is context. If you learn three bundled skills, we would pick /code-review, /debug and /loop.

One caution: bundled skills spend tokens like any prompt, and /batch and /ultrareview can fan out into many agents. Check /usage after the first run.

Frequently asked questions

How do I create a custom slash command in Claude Code? A Markdown file at .claude/commands/name.md, or a skill folder. Both create /name.

Are custom commands and skills different now? They were merged. Skills add supporting files and invocation controls.

How do I pass arguments? $ARGUMENTS for all, $0 and $1 for positions, or named arguments.

What is the difference between a built-in command and a bundled skill? Built-ins run fixed logic; bundled skills are prompts Claude orchestrates.

Can I use the same commands in Gemini CLI? No, Gemini CLI uses TOML files in .gemini/commands/.

*Product names are used descriptively. We are not affiliated with Anthropic, Google, OpenAI or Cursor.*