Claude Code Custom Slash Commands: 8 Examples to Copy

Published 2026-10-22 · 7 min read · by AgentKit Co

A custom slash command is a Markdown file that turns a prompt you type over and over into /something. Type /commit and Claude Code reads the file, fills in your arguments and any live data you asked for, and runs it as the prompt.

One thing changed that trips people up: custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Old command files keep working, but Anthropic recommends the skill folder for new work because it can hold supporting files. Everything below works in either format, and we show both.

These examples were checked against Anthropic's skills and commands docs on 2026-10-22. Claude Code changes quickly, so re-check anything you rely on.

Where the files go

If the same name exists twice, a personal skill beats a project skill, and a skill beats a .claude/commands/ file with the same name.

The four pieces you'll use most

1. Arguments. $ARGUMENTS is everything you typed after the command. $0, $1, $2 are single arguments, and they start at zero, so $1 is the second word, not the first. You can also name them with arguments: [issue, branch] in the frontmatter and write $issue and $branch.
2. Live data. A line like !`git diff HEAD` runs before Claude sees the file, and the output replaces the line. The ! must be at the start of a line or after a space.
3. Pre-approved tools. allowed-tools: Bash(git add *) Bash(git commit *) lets Claude run those without asking, for that one turn only.
4. Manual only. disable-model-invocation: true means only you can start it. Use it for anything with side effects (commits, deploys, messages), so Claude never decides on its own that it's time to ship.

1. /commit: write the message from the real diff

.claude/skills/commit/SKILL.md:

---
description: Write a commit message from the staged diff and commit. Use when asked to commit changes.
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---

## Current state
- Status: !`git status --short`
- Diff: !`git diff HEAD`

## Your task
Write a commit message: a summary line under 72 characters in the
imperative mood, a blank line, then 1-3 lines on why. Stage the changed
files and commit. Don't push. If the diff mixes unrelated changes, say so
and suggest how to split it instead of committing.

2. /fix-issue 123: work a GitHub issue end to end

.claude/skills/fix-issue/SKILL.md:

---
description: Fix a GitHub issue by number, with a test, and stop before committing.
argument-hint: [issue-number]
disable-model-invocation: true
allowed-tools: Bash(gh issue view *)
---

Fix GitHub issue $ARGUMENTS.

1. Read it with `gh issue view $ARGUMENTS --comments`.
2. Find the code involved and explain the cause in two sentences.
3. Make the smallest change that fixes it and add a test that fails without it.
4. Run the tests. Stop and report; don't commit or push.

argument-hint is what the / menu shows next to the name, so you remember it wants a number.

3. /review-diff: a second opinion that can't touch your files

---
description: Review the current uncommitted diff for bugs, missing error handling and security issues.
disable-model-invocation: true
context: fork
agent: Explore
---

## Changes
!`git diff HEAD`

## Your task
Review only these changes. List real problems first (bugs, missing error
handling, security issues, broken tests), each with file and line. Then
at most three optional suggestions. Say "No blocking issues" if there are none.

context: fork runs the command in its own subagent, so the review doesn't fill your main conversation. The subagent doesn't see your chat history, so the file has to say everything it needs. Don't name this one review: /review is an alias of the bundled /code-review command, and the docs say an alias never runs your skill.

4. /test-for src/utils/price.ts: named arguments

---
description: Write unit tests for one file, matching the project's existing test setup.
argument-hint: [file] [focus]
arguments: [file, focus]
---

Write unit tests for $file. Focus on: $focus.
Match the test framework and file layout the project already uses.
Cover the normal case, edge cases and one failure case. Run them.

Type /test-for src/utils/price.ts "rounding and currency". Quotes keep a multi-word value together as one argument.

5. /standup: your own command for every repo

Personal, so it lives at ~/.claude/skills/standup/SKILL.md:

---
description: Turn my commits since yesterday into a short standup update.
disable-model-invocation: true
---

## My commits since yesterday
!`git log --since=yesterday --author="$(git config user.email)" --oneline`

## Your task
Turn these into a three-part standup: Yesterday, Today (best guess from
the work in progress), Blockers (say "None" if nothing looks stuck).
Plain sentences, no commit hashes.

6. /changelog: a cheap model for a simple job

---
description: Draft user-facing release notes from commits since the last tag.
disable-model-invocation: true
model: haiku
---

## Commits since the last tag
!`git log $(git describe --tags --abbrev=0)..HEAD --oneline`

## Your task
Group these into Added, Changed and Fixed for users, not developers.
Skip merge commits and chores.

model applies only to the turn the command runs in; your normal model comes back on your next message. If the repo has no tags yet, git describe fails, and a failed ! command stops the whole command (see the fixes below).

7. /preflight: several commands at once

---
description: Check lint, git status and runtime versions for anything that would block a pull request.
disable-model-invocation: true
---

## Environment
```!
node --version
git status --short
npm run lint --silent || true
```

## Your task
Tell me in a short list what would block a pull request: lint errors,
uncommitted files, or anything odd. Don't fix anything yet.

A ```! block runs several lines. The || true matters: lint exits non-zero when it finds problems, and without it the whole command aborts.

8. The same thing in the old command format

If your team already has .claude/commands/, keep it. This file works exactly like example 2:

.claude/commands/fix-issue.md:

---
description: Fix a GitHub issue by number, with a test, and stop before committing.
argument-hint: [issue-number]
disable-model-invocation: true
---

Fix GitHub issue $ARGUMENTS. Read it with `gh issue view $ARGUMENTS`,
make the smallest fix, add a test, run the tests, and stop before committing.

Command files accept the same frontmatter as skills except name and paths.

Why your command won't show up or run

1. "Shell command failed for pattern ..." One of your ! commands exited non-zero, so the whole command was cancelled and Claude never saw it. Add || true to commands that exit 1 on purpose (linters, checkers). The docs exempt exit code 1 from search and comparison commands, but not most others.
2. "Shell command permission check failed ..." A ! command never asks for permission while it runs; if your permission rules don't already allow it, the command is cancelled. Add it to allowed-tools.
3. Your ! line printed as plain text. The ! has to start the line or follow a space. KEY=!...`` isn't run.
4. $1 got the wrong word. Indexes start at $0. And an indexed placeholder with no argument at that position stays in the prompt as literal text.
5. The description is ignored but /name still works. The frontmatter YAML is broken, so Claude Code loads the body with empty metadata. Run claude --debug to see the parse error, or claude plugin validate .claude/skills on recent versions.
6. It's missing from the / menu. Check the file or folder name for odd characters (a no-break space, a double space, < or >). Claude Code refuses those names, and claude --debug logs which one under [names].
7. A different command runs. Something else has the same name: a personal skill beats a project one, a skill beats a command file, and built-in aliases keep running the built-in.
8. Claude runs it when you didn't ask. Add disable-model-invocation: true. Without it, Claude can start the command on its own when the description matches what you're doing.

Commands, subagents or hooks?

• A command or skill is a prompt you start (or Claude picks) for a job you repeat.
• A subagent is a separate helper with its own instructions and tools, good for work you want out of your main conversation.
• A hook runs every time an event happens, whether anyone remembers or not. Use one when "always" really means always.

If you want more ready-made skills, our free agent skills are MIT-licensed SKILL.md files you can drop into .claude/skills/, and SKILL.md explained covers the format across tools.

Want helpers already written for the jobs commands hand off to? The Claude Code Subagent Pack ($29, 30-day refund) has 18 subagents for review, testing, debugging, code changes, research and docs, with an installer that won't overwrite files you already have.

Keep reading