Claude Code Commands: Slash Commands and Custom Workflows (2026)

Every weekday, Maya opened Claude Code and pasted the same six-line prompt: read the open PR, summarize the risky changes, flag anything touching auth, and write a checklist. By Thursday she had typed it forty-something times that month. Then a teammate showed her that the entire prompt could live in one file and run as /review-pr. That is the whole pitch for Claude Code commands: a prompt you repeat is a prompt you should save. This guide covers the built-in slash commands you already have, how to write your own, how to pass arguments, and how to share custom commands with a team through git.

Most people meet commands through the built-ins and never go further. That is the trap. The built-ins are useful, but the real time savings start the moment you write the first one of your own. You will leave this page knowing exactly which commands ship with the tool, how to author a custom one in under a minute, and which of your daily prompts are worth turning into a command.

Built-in Slash Commands You Already Have

Built-in slash commands ship with Claude Code and control the session itself. You type them in the prompt with a leading slash, and they run instantly without any setup. The ones you will reach for daily are /clear, /compact, /model, and /review; the rest cover setup and configuration.

One thing worth knowing on day one: /help shows your custom commands right alongside the built-ins, so once you start writing your own, this is the index you will check. If you have just installed the tool, running /init to generate a CLAUDE.md is the most valuable first command, because it gives Claude the project context every later prompt relies on. Want to see what teams build on top of these primitives? Browse the skill registry to see commands and workflows others have already packaged.

Custom Slash Commands: Where the Time Goes

A custom slash command is a Markdown file in .claude/commands/, and the filename becomes the command name. Save .claude/commands/changelog.md and you can immediately type /changelog; whatever you wrote in that file becomes the prompt Claude runs. There is no registration step, no config to edit, and no restart. Create the file, type the slash, done.

Custom commands have now been merged into skills, so a file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way, and your existing .claude/commands/ files keep working.

Here is the entire setup for a command that summarizes uncommitted work:

# Create the file
mkdir -p .claude/commands
echo "Summarize my staged and unstaged git changes as a short, plain-English changelog entry." > .claude/commands/changelog.md

Now /changelog works in that project. The body of a command file is just a prompt, so anything you would normally type, you can save. Bash injection makes these files far more capable than a saved snippet: a line of the form !`command` (the command wrapped in backticks after the !) runs that shell command and feeds its output into the prompt. A sharper changelog command pulls in both the diff and the existing file this way:

# .claude/commands/changelog.md
Here is the current diff:

!`git diff --staged`

And the existing changelog for tone:

!`cat CHANGELOG.md`

Write a new entry matching that style. Keep it under five bullet points.

When you run /changelog, Claude executes git diff --staged, reads CHANGELOG.md, and writes the entry, all from one slash. That is the difference between a command and a snippet: a command can gather its own context before it runs. This pairs naturally with Claude Code hooks, which automate actions around the agent, while commands automate the prompts you send into it.

Passing Arguments with $ARGUMENTS

Static commands are useful, but the ones you live in take input. Put $ARGUMENTS anywhere in a command file and Claude substitutes everything you type after the command name. So /fix the login redirect loop drops "the login redirect loop" into the placeholder, and one file handles every variation of the task.

# .claude/commands/fix.md
Investigate and fix this bug: $ARGUMENTS

Reproduce it first, write a failing test, then make it pass.
Show me the diff before committing anything.

Run /fix the date picker shows tomorrow in UTC-8 and the whole sentence flows into $ARGUMENTS. When a command needs more than one distinct input, use positional placeholders, which are 0-based: $0, $1, and so on. They map to the words you pass, in order:

# .claude/commands/scaffold.md
Create a new $0 component named $1.

Match the patterns in our existing $0 components, include a basic test,
and add it to the index export.

Now /scaffold react Button sets $0 to "react" and $1 to "Button". Positional arguments are how you turn a one-off prompt into a small, reliable generator. Once you have a command you call several times a day, this is the point where it starts feeling less like a shortcut and more like a tiny tool you built for yourself.

Commands That Pay Off

The commands worth writing are the prompts you already repeat. Three patterns earn their keep for nearly every developer, and each one started as a prompt someone got tired of retyping.

• The reviewer:a /review-pr that runs !`git diff main`, applies your team's review checklist, and flags security-sensitive changes. This is Maya's command; it replaced her six-line morning paste and now runs in two keystrokes.
• The changelog writer:a /changelog that reads the staged diff and the existing changelog file, then drafts an entry in the right voice. Saves the "what did I even change" pause before every commit.
• The scaffolder:a /scaffold $0 $1 that generates a new component, hook, or endpoint matching your project's conventions, complete with a test stub. New code that looks like your existing code, every time.

A team at a small fintech, Northwind, measured this in March 2026. They counted the prompts their four engineers retyped most often, turned the top seven into project commands, and committed them. Within two weeks the phrase "what's the command for that again" had moved from Slack into /help, and onboarding a fifth engineer took an afternoon instead of a week, because the team's workflows were now files in the repo rather than tribal knowledge.

Commands vs Skills: Which to Reach For

Commands and skills both package reusable instructions, but they fire at different times, and that difference decides which one you want. A command runs only when you type its slash name; you control the exact moment. A skill is loaded by Claude automatically when your task matches the skill's description, so it activates without you asking.

The practical rule: if you want to decide when something happens, write a command. If you want Claude to recognize the situation and act, build a skill. A /deploy command should be deliberate; "always follow our API error-handling conventions" should be a skill that loads itself. Many teams keep both, and every skill on PolySkill is security-scanned before listing, which matters because a skill activates on its own where a command waits for you.

Sharing Commands Across a Team

The reason commands beat personal aliases is that they travel. A command in .claude/commands/ sits inside your repository, so when you commit it and a teammate pulls, they get the command too, no setup on their end. This is project scope, and it is how a workflow stops being one person's habit and becomes the team's.

There are two homes for commands, and the difference is who gets them:

• Project scope:.claude/commands/ in the repo. Commit it and the whole team shares the command through git. Use this for review checklists, scaffolders, and anything tied to the codebase.
• Personal scope:~/.claude/commands/ in your home folder. Available in every project you open, visible only to you. Use this for personal habits like a journaling prompt or your own commit-message style.

Treat your .claude/commands/ directory like the rest of the codebase: review changes to it, name commands clearly, and prune ones nobody runs. A shared command that drifts out of date is worse than no command, because people trust it. When you bring a new engineer on, the commands in the repo are a running tour of how the team actually works, which is exactly why committing them beats keeping a wiki page nobody updates.

When a Command Is the Wrong Move

Commands are cheap, which makes it easy to write too many. A directory of forty commands nobody remembers is just clutter with a slash in front of it. Three cases where a command is not the answer:

A prompt you run once. If you will type something a single time, type it. The minute spent writing the file is only repaid by repetition; a true one-off never repays it.

Logic that should be a real script. If your command is mostly shell with ! lines and barely any instruction for Claude, you have written a shell script in disguise. Put it in a Makefile or a scripts/ file where it can be tested and version-controlled as code.

Knowledge that should load itself. If you find yourself typing the same command at the start of every session to remind Claude how the project works, that belongs in CLAUDE.md or a skill, not in a command you have to remember to run.

If You Run a Prompt Twice a Week, It's a Command

The math is simple. A custom command takes about a minute to write. A prompt you retype twice a week costs you that minute again every few days, plus the small tax of getting the wording slightly wrong each time. Run it twice a week for a month and the command has paid for itself eight times over, and it never drifts. Pick the one prompt you typed most this week, save it as a file in .claude/commands/, and use it tomorrow. That single command is the cheapest win in the whole tool, and the second one is even easier, because you already know how.

Browse next: How to Add Skills to Claude Code (2026) | Claude Code Subagents (2026) | Claude Code Hooks (2026) | Claude Code MCP (2026)

Back to Blog