Fabler Labs → Guides → Claude Code slash commands

Claude Code slash commands: create your own

Free · no signup · verified against the docs · last updated July 2026

A custom slash command turns a workflow you keep re-typing — “stage and commit with a good message,” “summarize this PR,” “deploy to staging” — into a single /word you type in Claude Code. The mechanism recently changed in a way most guides haven't caught up to: custom commands have been merged into skills. Your old .claude/commands/deploy.md still works and still makes /deploy — but a skill at .claude/skills/deploy/SKILL.md makes the same command and can do more. This page covers both, current, with copy-paste examples: where the files live, how arguments work, how to inject live data, and how to stop Claude from firing a command on its own.

The fastest path: a one-file command

A slash command is just a Markdown file whose name becomes the command. Drop one file in .claude/commands/ and you're done — this is the quickest way to get a working command:

---
description: Stage and commit the current changes with a clear message
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---

Stage all changes and create a single commit.

1. Run `git status` and `git diff` to see what changed.
2. Write a concise, conventional commit message describing the change.
3. Commit. Do not push.

The filename without .md is the command name, so this file gives you /commit. The body is the prompt Claude runs when you type it. That's the whole idea — everything below is refinement.

The modern path: a skill directory

The recommended form is a skill: a directory containing a SKILL.md. The directory name becomes the command. Same command, but now you can bundle supporting files (templates, scripts, longer reference docs) next to it, and opt into Claude loading it automatically when relevant.

---
description: Stage and commit the current changes with a clear message. Use when the user asks to commit or wants a commit message.
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---

Stage all changes and create a single commit.

1. Run `git status` and `git diff` to see what changed.
2. Write a concise, conventional commit message describing the change.
3. Commit. Do not push.

Which should you use? A .claude/commands/*.md file is perfect for a simple one-shot prompt. Reach for a .claude/skills/<name>/SKILL.md directory when the command needs helper files or you want Claude to be able to invoke it automatically. Both support the same frontmatter, so migrating later is just moving the file into a folder named for the command. If a skill and a command share a name, the skill wins.

Where commands live & who gets them

The location decides the scope. Personal commands follow you across every project; project commands live in the repo and are shared with anyone who clones it.

When the same name exists at more than one level, personal overrides project (and enterprise-managed overrides both). Commit project commands to version control and a git pull is all a teammate needs to get your whole command set.

Passing arguments

Whatever you type after the command name is available in the body. The $ARGUMENTS placeholder gets the full string; use indexed forms for individual words.

---
description: Fix a GitHub issue by number
argument-hint: [issue-number]
disable-model-invocation: true
---

Fix GitHub issue $ARGUMENTS following our coding standards.

1. Read the issue with `gh issue view $ARGUMENTS`.
2. Understand the requirements and implement the fix.
3. Write tests, then create a commit.

Running /fix-issue 123 substitutes 123 for $ARGUMENTS. For several arguments, address them by position with $ARGUMENTS[0], $ARGUMENTS[1] … or the shorthand $0, $1 …:

Migrate the $0 component from $1 to $2.
Preserve all existing behavior and tests.

Wrap multi-word values in quotes to keep them as one argument: /migrate "Search Bar" React Vue makes $0 = Search Bar. For readable names instead of numbers, declare them in an arguments frontmatter list — arguments: [issue, branch] — and reference them as $issue and $branch. And a useful default: if a command has no $ARGUMENTS at all, your input is still appended as ARGUMENTS: <value> so Claude sees it.

Injecting live data (run a shell command first)

The most powerful trick: run a shell command before the prompt reaches Claude, and drop its output straight into the command. A line beginning with ! and a backtick does exactly that. This grounds the command in your real working tree instead of what Claude can guess.

---
description: Summarize uncommitted changes and flag anything risky
allowed-tools: Bash(git diff *)
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes above in two or three bullets, then list any risks —
missing error handling, hardcoded values, or tests that need updating.
If the diff is empty, say there are no uncommitted changes.

The !`git diff HEAD` line runs first; its output replaces the line before Claude sees the prompt. Two details that trip people up: the ! form is only recognized at the start of a line or right after whitespace (so KEY=!`cmd` stays literal), and for several commands use a fenced block opened with three backticks and an !:

## Environment
```!
node --version
npm --version
git status --short
```

Always list the commands you inject under allowed-tools so they run without a permission prompt each time.

Manual-only vs. auto-invoked

Because commands are skills, Claude can also load one on its own when your request matches its description. That's great for reference commands and dangerous for ones with side effects. Two frontmatter fields decide who can pull the trigger:

Rule of thumb: anything that writes, pushes, or spends money gets disable-model-invocation: true. You don't want Claude deciding your code “looks ready” and running /deploy for you.

Frontmatter you'll actually use

All fields are optional; only description is recommended. The ones worth knowing:

Run a command in its own subagent

Add context: fork and the command runs in a fresh, isolated context — the command body becomes the subagent's whole task, and results are summarized back to you. Perfect for research or review that shouldn't clutter your main conversation:

---
description: Summarize the changes in the current pull request
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---

## Pull request context
- Diff: !`gh pr diff`
- Comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`

## Your task
Summarize this pull request: intent, risky changes, and anything a
reviewer should look at closely.

This pairs the two most useful features — live injection to pull in the PR data, and a forked subagent so the summary work stays out of your main context.