Slash commands

The slash is the one keystroke that turns a chat box into an interface. Type / and pause, and Claude shows you a menu of everything it can do on request — built-in and yours. That works identically in Claude Desktop and in the terminal, because the slash lives in the chat, not on a command line.

There are two populations behind that menu, and they answer different needs. The built-in commands are the moves Anthropic assumes you make constantly — start a review, clear the thread, check what a session is costing. The custom ones are the moves only your team makes. Nobody at Anthropic knows what your Monday standup summary should look like; a custom command is how you tell Claude once instead of every Monday.

A few of them aren’t actions at all — they’re settings. /output-style doesn’t produce anything; it changes how Claude talks for the rest of the session. Worth knowing so you’re not waiting for output that isn’t coming. /help is the map: when you’ve forgotten what exists, it lists what’s available right now, including anything you or your team added.

The tell that you need a custom one is repetition. If you’ve pasted the same three-paragraph instruction into a fresh session more than twice, you have a command that hasn’t been written down yet. Writing it is deliberately unimpressive — the “code” is the prompt you were pasting anyway, saved in a file, and the filename becomes the command name.

What a command actually is, and where it lives

A custom command is a markdown file in a .claude/commands/ folder. The filename becomes the command name — review.md becomes /review — and the file’s contents are the prompt Claude runs. There is no programming involved anywhere; if you can write the instruction, you can write the command. The easiest way to make one is to ask for it in the chat (“create a slash command called /review that reviews my staged changes for bugs and security issues, grouped by severity”), accept the file in the diff, and it’s live.

Two details make them much more useful than a saved snippet:

They take input. Drop $ARGUMENTS into the prompt and whatever you type after the command lands there. A file containing “Explain what the file $ARGUMENTS does, in plain English, to someone who’s never seen this codebase” turns into /explain server/index.js — one command, reusable on anything.

Where you put the folder decides who gets it. .claude/commands/ inside the project is committed to the repository, so the whole team gets the command. ~/.claude/commands/ in your home folder is personal and available in every project you open. Same split as CLAUDE.md: shared workflows in the repo, personal ones at home.

That first option is quietly the point. A well-written /review in the repo means everyone on the team gets your best prompt for that job rather than whatever they’d improvise — which is why commands end up being a team operating guide mechanism as much as a personal shortcut.

The thing people get wrong is picking a command when they wanted a skill. The difference is entirely about the trigger: a command fires when you type it, a skill fires when Claude decides it’s relevant. The comparison below has the full split. And if what you’re capturing is true of every task in a project rather than one recurring job, it probably belongs in project memory instead of either.