What Claude Code Slash Commands Actually Are
A slash command in Claude Code is a saved prompt you run by typing a slash and a name, like /review. There are two kinds. Built-in commands control the session itself - /clear wipes the context, /init writes a CLAUDE.md, /model switches the model. Custom commands are the ones you write: you save a prompt you keep reusing as a Markdown file, give it a name, and from then on you trigger the whole thing with one keystroke instead of retyping it.
The reason they matter is simple. If you do client work, you run the same handful of prompts over and over - review this before I ship it, scope this request, write me a handoff. Retyping those from memory means they drift and get sloppy. A slash command freezes your best version of that prompt and runs it the same way every time. It's the difference between explaining your process from scratch each time and pressing a button that already knows it.
How To Create A Custom Slash Command
A custom slash command is just a Markdown file in a commands folder. Drop a file called review.md into .claude/commands/ in your project, and Claude Code turns it into /review automatically. The file name becomes the command name, and the file's contents become the prompt that runs. That's the whole mechanism - there's no config to learn.
- Make the folder: create .claude/commands/ in your project root for project-specific commands, or ~/.claude/commands/ for commands you want in every project.
- Write the prompt as a file: save your instructions as a Markdown file, for example ship.md. The file name (minus .md) is the command name.
- Use $ARGUMENTS for input: anything you type after the command name gets dropped in where you put $ARGUMENTS, so /scope add a dark mode toggle passes that request straight into the prompt.
- Run it: type / to see your commands in the menu, pick one, and it runs like you'd typed the whole prompt yourself.
The Four Custom Commands I Use Every Day
I've made a lot of slash commands and deleted most of them. These four survived because they replaced a prompt I was genuinely retyping every week. This is my CCC command kit - the workflows I run on almost every client build.
The commands that earned a permanent place in my workflow
| Command | What it does | What it replaced |
|---|---|---|
| /review | Reviews the current diff for bugs, edge cases, and anything I'd be embarrassed to ship to a client | Me pasting 'check this before I ship' ten times a week |
| /ship | Runs the tests, writes a clean commit message, and summarizes what changed in plain English for the client update | Three separate manual steps I did in the wrong order half the time |
| /scope | Takes a client's feature request and turns it into a bulleted scope with the parts that are out of scope flagged | Rewriting fuzzy client asks into something buildable, from scratch |
| /handoff | Writes a handoff doc: what was built, how to run it, and what to watch for | The doc I always meant to write and never did |
The pattern across all four: each one is a workflow I care about doing consistently, saved so it happens the same way whether it's Monday morning or Friday at six. /review in particular is the one I'd tell anyone to build first - it catches the small mistakes before they reach a client, and it costs me one keystroke.
What Makes A Slash Command Worth Keeping
Most commands you make you'll never use twice. The ones worth keeping share three traits, and I check a new command against them before it earns a spot in the menu.
- It's something you repeat. A command for a one-off task is just a slower way to type a prompt. Save the prompts you run weekly, not the clever ones you run once.
- The prompt is better than what you'd type live. Because you're writing it calmly and once, a good command is more thorough than the rushed version you'd type in the moment. Put the edge cases and the standards in it.
- It has one clear job. A command that tries to do five things produces mush. /review reviews. /ship ships. Narrow commands compose better than one giant do-everything command.
Get The Command Kit
Slash commands are the cheapest workflow upgrade in Claude Code - a Markdown file and a folder, and a prompt you were typing anyway now runs in one keystroke. Start with /review, add /ship, and let the rest grow out of the prompts you catch yourself repeating.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
What is a slash command in Claude Code?
A slash command is a saved prompt you run by typing a slash and a name, like /review. Built-in commands control the session (/clear, /init, /model), and custom commands are ones you write yourself by saving a prompt as a Markdown file. Instead of retyping a multi-step prompt every time, you trigger the whole thing with one keystroke.
How do I create a custom slash command in Claude Code?
Create a .claude/commands/ folder in your project (or ~/.claude/commands/ for every project), then save your prompt as a Markdown file - review.md becomes /review. The file name is the command name and the file contents are the prompt. Use $ARGUMENTS in the file to pass in anything you type after the command name.
Where do custom slash commands live?
Project commands live in .claude/commands/ inside the repo, so they ship with the project and your whole team gets them. Personal commands live in ~/.claude/commands/ and follow you across every project. Keep client-workflow commands in the repo and your own habits in the personal folder.
What slash commands are worth creating?
Save prompts you repeat weekly, not one-offs. The ones I use daily are /review (checks the diff before I ship), /ship (tests, commits, and summarizes the change), /scope (turns a client request into a buildable scope), and /handoff (writes the handoff doc). Each one has a single clear job and replaced a prompt I was retyping constantly.
Can slash commands take arguments?
Yes. Put $ARGUMENTS anywhere in the command's Markdown file, and whatever you type after the command name gets dropped in there. So a /scope command with $ARGUMENTS in it lets you run /scope add a dark mode toggle and pass that request straight into the prompt.
Last reviewed by David Iya on July 21, 2026
