Claude Code Slash Commands Examples: 4 Verified Commands You Can Copy Today

#What are Claude Code slash commands?

A slash command is anything you type into a Claude Code session that starts with /. There are two kinds, and the distinction matters:

• Built-in commands ship with the CLI and execute fixed logic directly — /help, /compact, /model, /permissions. You can't edit them.
• Custom commands are plain markdown files you write. Drop a file at .claude/commands/deploy.md in your repo and /deploy appears in your session, with the file's contents becoming the prompt Claude follows.

One important update from the official docs: custom slash 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. Your existing .claude/commands/ files keep working — nothing breaks — but skills add optional extras: a directory for supporting files, frontmatter that controls whether you or Claude invokes them, and automatic loading when Claude decides they're relevant. Anthropic's docs now recommend the skills format for new work, and Claude Code skills follow the open Agent Skills standard.

So when this post says "slash command," read it as: a markdown file that gives you a /name shortcut for a repeatable workflow. That definition covers both the classic .claude/commands/*.md format (which every example below uses, because that's what real open-source repos ship today) and the newer SKILL.md format.

The payoff is simple: instead of re-typing "look at my staged changes, split them into atomic commits, use conventional commit format..." every time, you type /commit. The prompt lives in your repo, versioned with your code, identical for every teammate.

#Built-in vs custom — which do you actually use?

Here's a working Claude Code commands list — the built-ins you'll actually touch, from the official commands reference:

Note the third column: some "commands" are actually bundled skills — prompts handed to Claude that orchestrate work with its tools — while true built-ins execute fixed logic coded into the CLI.

In practice the split is clean. Built-ins are session controls: you use /compact, /model, and /permissions constantly, but they manage Claude Code itself. Custom commands are where your actual workflow lives — committing, opening PRs, fixing issues, updating changelogs. If you're using Claude Code daily and have zero custom commands, you're re-typing prompts that should be files. (Same logic applies to MCP servers for external tools — see the verified MCP directory — but commands are the lower-effort starting point: one markdown file, no server, no config.)

#How to write a custom command — file location, frontmatter, $ARGUMENTS (with 4 real examples)

#The mechanics

File location. Two options, both live-reloaded for skills:

• Project scope (shared with your team via git): .claude/commands/<name>.md or .claude/skills/<name>/SKILL.md
• Personal scope (all your projects): ~/.claude/skills/<name>/SKILL.md

The file or directory name becomes the command: .claude/commands/deploy.md → /deploy.

Frontmatter. Optional YAML between --- markers at the top. All fields are optional; description is the one Anthropic recommends. The ones you'll actually use:

---
description: What this does and when to use it
argument-hint: "[issue-number]"
allowed-tools: Bash(git add *) Bash(git commit *)
disable-model-invocation: true
---

• description — how Claude decides when to load it automatically
• argument-hint — autocomplete hint, e.g. [issue-number]
• allowed-tools — tools Claude may use without a permission prompt during the turn that invokes the command (the grant clears when you send your next message)
• disable-model-invocation: true — only you can trigger it. Use this for anything with side effects, like committing or deploying; you don't want Claude deciding to /deploy because your code "looks ready"

Command files in .claude/commands/ support the same frontmatter as skills, except name and paths, which are ignored there.

Arguments. The $ARGUMENTS placeholder receives everything typed after the command name. For positional access, use $ARGUMENTS[N] or the $N shorthand — and note it's 0-based: $0 is the first argument. Multi-word values need quotes (/my-command "hello world" second → $0 is hello world). If your file never mentions $ARGUMENTS, Claude Code appends ARGUMENTS: <your input> to the end so Claude still sees it.

Dynamic context. A line like !`git diff HEAD` runs the shell command before Claude reads the file and inlines its output — so Claude sees your actual diff, not instructions to go fetch one.

#Example 1: /fix-github-issue — the cleanest $ARGUMENTS demo

From kotlinter-gradle (a widely-used Kotlin linter Gradle plugin, 708 stars). This is the whole file — nine lines that replace re-explaining every bug by hand:

Please analyze and fix the GitHub issue: $ARGUMENTS.

Follow these steps:

1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Ensure code passes linting and type checking
7. Create a descriptive commit message

Remember to use the GitHub CLI (`gh`) for all GitHub-related tasks.

Run /fix-github-issue 142 and Claude reads issue 142 itself via gh, fixes it, tests it, and commits. Requires the GitHub CLI authenticated in your project. Full verified source: /commands/fix-github-issue.

#Example 2: /commit — conventional commits on autopilot

From the Tevm monorepo (open-source Ethereum dev toolkit, 442 stars, MIT). It runs pre-commit checks (pnpm lint, pnpm build, pnpm generate:docs — swap in your own), inspects the staged diff, and writes emoji conventional-commit messages. The part that makes it better than most hand-written commits: it detects when a diff covers multiple concerns and splits it into atomic commits instead of one messy blob.

/commit              # full flow with pre-commit checks
/commit --no-verify  # skip the checks

Output looks like ✨ feat: add user authentication system or 🐛 fix: resolve memory leak in rendering process. Full command file (it's ~110 lines of well-organized rules): /commands/commit.

#Example 3: /create-pr — branch to open PR in one step

From a contributor's fork of Giselle (open-source AI agentic-workflow builder, 549 stars, Apache-2.0). No arguments needed — it reads your working tree and does the whole dance:

# Create Pull Request Command

Create a new branch, commit changes, and submit a pull request.

## Behavior
- Creates a new branch based on current changes
- Formats modified files using Biome
- Analyzes changes and automatically splits into logical commits when appropriate
- Each commit focuses on a single logical change or feature
- Creates descriptive commit messages for each logical unit
- Pushes branch to remote
- Creates pull request with proper summary and test plan

Swap the Biome step for your own formatter. Pair it with /commit as an end-of-task ritual: "done coding" to "PR open" in two commands. Source: /commands/create-pr.

#Example 4: /add-to-changelog — multi-argument commands done right

From blockdoc-python (a small MIT-licensed Python library — 3 stars, and proof a command doesn't need a famous repo to be useful). It takes three positional arguments:

/add-to-changelog <version> <change_type> <message>

/add-to-changelog 1.1.0 added "New markdown to BlockDoc conversion feature"
/add-to-changelog 1.0.2 fixed "Bug in HTML renderer causing incorrect output"

The command file tells Claude to create CHANGELOG.md if it's missing, find or create the version section, and format the entry per Keep a Changelog conventions. Its last step (bumping the version in __init__.py and setup.py) is Python-specific — drop or adapt it. Source: /commands/add-to-changelog.

Bonus for the branch-naming-averse: /commands/update-branch-name looks at your actual diff against main and renames your wip branch to something a teammate can parse.

All five of these are hand-verified against their real source files — actual content, not paraphrases. Browse the full verified collection to copy them into your own .claude/commands/ folder.

#Slash commands vs skills vs subagents vs hooks — when to use which

These four extension points overlap just enough to confuse everyone. Here's the map:

The honest version of "commands vs skills": it's no longer either/or — commands are now a subset of skills. Same engine, same frontmatter (minus name and paths), same $ARGUMENTS. Skills add three things commands lack: a directory for supporting files that load only when needed, disable-model-invocation / user-invocable to control who triggers them, and automatic invocation when the description matches what you're doing. If a skill and a command share a name, the skill wins.

Decision rules that hold up in practice:

• You want to trigger it manually, it's one file → a command file is still fine, and it's what most public examples use
• Claude should apply it without being asked (coding conventions, API patterns) → skill with a strong description
• It has side effects (deploy, commit, send a message) → either format, but set disable-model-invocation: true
• It's long-running research or bulk work → skill with context: fork (runs in a subagent, results return to your conversation), or a dedicated subagent
• It must happen every time, no model discretion → hook. A skill can even register hooks from its frontmatter

Going deeper: how skills work, how agents and subagents fit together, and the verified skills collection.

#What breaks — wrong folder, frontmatter gotchas, commands not showing up

The failure modes are mundane, which is exactly why they eat an afternoon. The complete checklist:

1. Wrong folder shape. Commands are flat files: .claude/commands/deploy.md. Skills are directories: .claude/skills/deploy/SKILL.md. A SKILL.md dropped directly into .claude/skills/ without its own subdirectory won't load, and deploy.md inside .claude/skills/ won't either. Also check the pluralization — .claude/command/ (singular) silently does nothing.

2. The directory didn't exist when the session started. Claude Code live-reloads changes within watched skill directories, but if you create a top-level skills directory mid-session, restart Claude Code so it can watch the new directory.

3. You used the settings file instead of --add-dir. The permissions.additionalDirectories setting grants file access only — it does not load skills or commands from those directories. The --add-dir flag and /add-dir command do load them (and added-directory command files aren't watched, so edits there need a session restart).

4. Name collisions resolve against you. Personal (~/.claude/skills/) overrides project (.claude/skills/). A skill beats a same-name command file. Your custom skill can override a bundled skill's primary name (/code-review) but never its alias (/review).

5. name and paths are ignored in command files. In .claude/commands/*.md, the command name comes from the file name, period. Renaming via frontmatter only works in plugin skills.

6. $0 is the first argument. Positional placeholders are 0-based — $0 is the first argument, $1 the second. Shell muscle memory will off-by-one you. An indexed placeholder with no matching argument stays in the content as literal text.

7. A failed injected command kills the whole invocation. If !`some-command` exits non-zero, the entire command aborts and Claude never sees the content. Append || true to anything expected to exit non-zero (like check scripts that exit 1 on findings). These injected commands also never prompt for permission — if a permission rule would have asked, the invocation aborts instead; pre-approve them with allowed-tools.

8. Windows without Git Bash. Injected ! commands default to shell: bash; without Git Bash installed the invocation fails with "requires bash... but Git Bash was not found." Set shell: powershell in frontmatter or install Git Bash.

9. The allowed-tools grant is one turn only. It clears when you send your next message, even though the command's content stays in context for the session. If Claude starts prompting for permissions again mid-task, that's why — re-invoke the command or add session-wide allow rules in /permissions.

10. Broken YAML frontmatter. Frontmatter is optional — a bare markdown file works — but malformed YAML between --- markers (unclosed quotes, bad indentation) can prevent the file from loading correctly. When a command doesn't appear, stripping the frontmatter entirely is the fastest way to isolate whether YAML is the culprit.

#Can non-developers use these?

Yes — and this is underrated. A slash command is a markdown file containing plain-English instructions. There's no code, no build step, no API. If you can write a checklist, you can write a command.

The developer examples above happen to be about git, but the mechanism is generic. Real patterns that need zero programming:

• A /todo command that manages a task list in a plain todos.md file — add, complete, due dates — no Trello signup, no separate app. (There's a verified one in the commands collection.)
• A /weekly-report command that reads your notes folder and drafts a status update in your team's format
• A /brief command encoding your content style guide, so every draft starts on-format

The skills merge makes this even more non-developer-friendly: skills you enable on your claude.ai account sync into Cowork and cloud sessions, so the same /name workflow follows you outside the terminal.

Two honest caveats. First, you do have to be comfortable with the idea of files in folders — the .claude/commands/ directory is the whole "installation." Second, commands that shell out (the ! syntax, gh, git) assume those tools exist and are authenticated, which is developer territory. Stick to pure-prompt commands and neither caveat applies.

The fastest path for anyone, technical or not: don't write from scratch. Browse verified Claude Code slash commands, copy one that's close to what you need, and edit the English. If you'd rather start from a fuller working setup, the templates library covers that, and the skills primer explains the concepts in plain language.

#Questions people ask

#Are Claude Code slash commands deprecated now that skills exist?

No. Anthropic merged custom commands 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. Existing command files keep working; skills are simply the recommended format for new work because they support supporting files, invocation control, and automatic loading.

#How do I pass arguments to a Claude Code slash command?

Use the $ARGUMENTS placeholder in the command file — it receives everything typed after the command name. For positional access use $ARGUMENTS[N] or the $N shorthand, which is 0-based ($0 is the first argument). Wrap multi-word values in quotes. You can also declare named arguments in an arguments frontmatter list and reference them as $name.

#Where do custom slash command files go?

Project-scoped: .claude/commands/.md (flat file) or .claude/skills//SKILL.md (directory) inside your repo, shared with your team via git. Personal, across all projects: ~/.claude/skills//SKILL.md. The file or directory name becomes the /command you type.

#How do I see the full list of built-in Claude Code commands?

Type /help inside a session, or see the commands reference in the official docs. Commonly used built-ins include /model, /clear, /compact, /permissions, /init, /memory, /mcp, /context, /plan, /resume, and /usage, plus bundled skills like /code-review, /doctor, /debug, /batch, and /verify.

#Why isn't my custom slash command showing up?

The usual causes: wrong folder shape (commands are flat .md files, skills need a /SKILL.md subdirectory), a skills directory created after the session started (restart Claude Code), loading via the additionalDirectories setting instead of --add-dir (the setting doesn't load commands), a name collision with a personal-level or bundled command, or malformed YAML frontmatter.