Claude Code Custom Slash Commands: 7 Copy-Paste Examples

Published Oct 15, 2026 · 9 min read

Short answer: a custom slash command in Claude Code is a Markdown file. Save it as .claude/commands/deploy.md and you can type /deploy. The file contents become the prompt, $ARGUMENTS is replaced with whatever you type after the command, and optional YAML frontmatter sets a description, argument hint and allowed tools. Commands in ~/.claude/commands/ work in every project.

Custom commands have since been merged into skills: .claude/commands/deploy.md and .claude/skills/deploy/SKILL.md both create /deploy and accept the same frontmatter. Your existing command files keep working, and for a short, single-file prompt the commands folder is still the quickest option. This guide shows the format and seven commands that earn their place in a repo.

Where command files live

If a skill and a command share a name, the skill wins. Type / in a session to see every command your build actually has, built-ins included.

The anatomy of a command

---
description: Fix a GitHub issue end to end
argument-hint: [issue-number]
allowed-tools: Bash(gh issue view:*), Bash(npm test:*), Read, Edit
---

Fix GitHub issue #$ARGUMENTS.

1. Run `gh issue view $ARGUMENTS` and restate the problem in one sentence.
2. Find the relevant code and write a failing test that reproduces it.
3. Fix the code until the test passes. Run the full suite.
4. Summarize the change and propose a commit message. Do not commit.

• description: shown in the / menu. Without it, Claude uses the first line of the file.
• argument-hint: tells you (and teammates) what to type after the command.
• allowed-tools: pre-approves tools for this command so you aren't prompted for every git diff.
• $ARGUMENTS: everything after the command name. Positional placeholders such as $0 and $1 pick out individual arguments.
• !`command`: runs a shell command first and pastes the output into the prompt.
• @path/to/file: includes a file's contents in the prompt.

7 slash commands worth adding

1. /commit-msg: a conventional commit from staged changes

---
description: Write a conventional commit message for staged changes
allowed-tools: Bash(git diff:*)
---

## Staged diff
!`git diff --staged`

Write one conventional commit message (feat|fix|refactor|test|docs|chore).
Subject under 72 characters, imperative mood. Add a body only if the "why" isn't obvious.
Output the message only.

2. /standup: yesterday's work in 30 seconds

---
description: Draft a standup update from recent commits
allowed-tools: Bash(git log:*)
---

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

Turn these commits into a standup update with three headings:
Yesterday, Today (infer next steps), Blockers (say "none" if nothing is obvious).
Plain language, no commit hashes.

3. /fix-issue: issue to failing test to fix

Shown above in the anatomy section. The key is step 2: forcing a failing test first stops Claude from "fixing" a bug it never reproduced.

4. /explain: a file or function in plain English

---
description: Explain a file or symbol for a newcomer
argument-hint: [path or symbol]
allowed-tools: Read, Grep
---

Explain $ARGUMENTS to a developer who is new to this codebase:
- What it does, in two sentences
- Who calls it and what it calls
- Inputs, outputs and side effects
- One thing that is easy to get wrong

5. /review: a quick pre-push review

---
description: Review the diff against main before pushing
allowed-tools: Bash(git diff:*), Read
---

!`git diff main...HEAD`

Review the diff above. For each issue give file:line, severity (high/med/low) and a fix.
Check: error handling, missing tests, secrets in code, N+1 queries, breaking API changes.
End with APPROVE or REQUEST CHANGES.

For a stricter review, delegate to a read-only reviewer subagent that literally cannot edit files.

6. /new-component: scaffolding with your conventions

---
description: Scaffold a React component with test and story
argument-hint: [ComponentName]
---

Create a component named $ARGUMENTS following @docs/conventions.md:
- src/components/$ARGUMENTS/$ARGUMENTS.tsx (typed props, no default export)
- src/components/$ARGUMENTS/$ARGUMENTS.test.tsx (render + one interaction)
- Export it from src/components/index.ts
Run the new test file and report the result.

7. /pr: a personal command for every repo

---
description: Draft a PR title and description from this branch
allowed-tools: Bash(git log:*), Bash(git diff:*)
---

!`git log --oneline main..HEAD`
!`git diff main...HEAD --stat`

Write a PR title (under 70 chars) and a description with:
What, Why, Changes (bullets), How to test, Risk.

Save it as ~/.claude/commands/pr.md so it works everywhere.

Built-in commands you should know

Command or skill: which should you write?

Write a command when the prompt fits in one file and you always trigger it yourself. Write a skill when you need supporting scripts or reference docs, want Claude to pick it up automatically when relevant, or want it to run in a forked context. Since both create the same /name, you can start with a command and promote it to a skill later without changing how anyone types it.

Sharing commands with a team

Commands in .claude/commands/ are just files, so they travel with the repo. A few habits keep a shared command library useful instead of cluttered:

• Name commands by verb. /review, /explain, /release. Anyone can guess what they do from the menu.
• Use folders to group them. .claude/commands/db/ and .claude/commands/frontend/ keep the / menu readable once you pass ten commands.
• Write a description for every command. It's the only thing teammates see in the menu, and Claude relies on it too.
• Review command changes in PRs. A changed allowed-tools line changes what Claude may run without asking on everyone's machine.
• Keep personal commands personal. Your /pr template might not match the team's; put it in ~/.claude/commands/.

Once a library grows past a dozen commands or needs to be shared across several repos, package it as a plugin so every project gets the same versions.

Tips for commands that behave

1. Inject state, don't describe it. !`git diff --staged` beats "look at my staged changes".
2. Scope allowed-tools tightly. Bash(git diff:*), not Bash.
3. End with an explicit output format. "Output the message only" removes chatty preambles.
4. Say "do not commit" or "wait for approval" in anything that touches git.
5. Guard against disasters with hooks. Commands can be ignored; a PreToolUse hook that blocks rm -rf cannot.