What is a slash command?

A prompt you save once and invoke from any Claude Code session by typing /name. The lightest-weight way to ship a skill.

I type /brief in Claude Code. Three seconds later a one-page brief lands in the terminal, summarizing every prior conversation with the people I'm about to meet. I didn't write that prompt today. I wrote it once, six months ago, saved it as a markdown file in a folder, and Claude has been running it on demand ever since. The folder plus that file is a slash command.

Slash commands are the level-up version of "I keep pasting the same prompt." They're how a workflow stops being something you do and becomes something you run.

A slash command IS a skill. Same idea, lighter packaging. A skill is the broader concept: a named, reusable capability Claude can invoke. A slash command is the simplest way to ship one. If you've heard the word "skill" thrown around in Claude Code conversations, slash commands are what people are usually building. The richer skill format (with bundled docs, scripts, and metadata in a SKILL.md file) is the next altitude up; the slash command is where you start.

So in short, slash commands save you from the drudgery of having to do the same thing over and over in Claude Code.

The easiest way to make one is to tell Claude Code what you want and let Claude write the file for you. No file paths to memorize, no formatting rules to learn. Describe the workflow in plain English, ask Claude to save it as a slash command, and Claude handles the mechanics. The sections below describe what a slash command is and what makes a good one. None of it is stuff you have to learn before you build your first one.

What it is

A slash command is a saved prompt you can invoke in Claude Code by typing /name, where name is whatever you called the file. The file lives at one of two paths.

Project-level at .claude/commands/{name}.md inside whatever project folder you have Claude Code open in. Available only when you're working in that folder. Use this when the command depends on the project's files (Desk Theory has a /learn command that only makes sense inside the content repo).

User-level at ~/.claude/commands/{name}.md in your home folder. Available in every Claude Code session anywhere on your laptop. Use this for commands that apply to any folder you'd be working in (a pre-meeting brief works the same whether you're in ~/notes/ or ~/headphones-com/).

The file itself is plain markdown. Whatever you'd paste manually into Claude Code goes into the file instead. You can pass arguments inline: typing /brief, meeting with Priya about the senior hire passes the trailing text to the prompt for the command to parse.

Why it matters

A prompt you have to retype every time is a prompt you stop running. That's the failure mode for ninety percent of useful AI workflows: the value is real, the friction is one too many steps, and the workflow quietly dies in your second week.

I felt this for months. I'd write a prompt I loved, paste it once, copy it into a Notes file, then lose track of which Notes file it was in. Then I'd retype a worse version from memory. Then I'd give up and ask the question without the prompt at all. The difference between "I'll run that brief sometime this week" and "I run that brief before every meeting" is whether the prompt is one keystroke away.

Slash commands close that gap. The friction of running a workflow drops from "find the prompt, paste it, fill in the blanks" to typing seven characters. The workflows that survive that gap compound; the ones that don't, don't.

What a good slash command looks like

A good command is short, named for what it does, and tells Claude how to interpret the input.

• Named for the workflow, not the mechanism. /brief works because the next thing it does is brief you. /run doesn't (run what?). /agent doesn't (which agent?). Future-you should be able to scan a list of your commands and remember what each one does without opening the file.
• Argument-handling at the top. If the command takes inline arguments, the first paragraph tells Claude how to interpret the trailing text. "Parse the attendees and topic from whatever follows /brief" beats hoping Claude figures it out.
• The body is the prompt itself. Same shape you'd paste manually. Operator vernacular, plain-spoken instructions, clear output spec at the end. Slash commands are not magic; the prompt body still has to be good.
• Output specification. Tell Claude where to put the result (terminal? a file?) and how long it should be. A command without an output cap is a command that produces six-paragraph answers.

You don't have to write any of this yourself. Open Claude Code, describe the workflow you want ("make me a slash command that drafts a pre-meeting brief by reading my ~/notes/granola/ folder"), and ask Claude to save it as a slash command. Claude writes the file, drops it in the right folder, and confirms it's registered. The first version is rarely the final one; use it for a week, notice what it gets wrong, then ask Claude to edit the file based on what you've learned. The whole loop happens through plain English.

My user-level ~/.claude/commands/ folder has about fifteen commands. Pre-meeting brief. Weekly review. Daily standup. Content-idea capture. Commitment-ledger refresh. Each one started as a manually pasted prompt that earned its place by being run twice in the same week.

Common mistakes

• Naming the command something generic. /run, /agent, /go, /do. None of these tell you (or Claude) what they do. Name the command after the workflow it runs, not the action of running it.
• Stuffing every workflow into one command. If /brief does pre-meeting briefs and weekly reviews and commitment-ledger updates, the prompt body gets confused and the output gets sloppy. One command, one job. Build a second command before extending the first.
• Forgetting the empty-input case. If your command needs arguments and the user types /brief with nothing after, the command should ask for what's missing, not run with empty values. Otherwise you get a hallucinated brief about no-one.
• Hiding what the command does. The command file should say plainly "Use this when the user wants X." If Claude can't tell when to use the command from reading the file itself, it won't fire when you expect it to.
• Treating it as set-and-forget. The first version of a command is rarely the final one. Use it for a week, notice the failure patterns, edit the file. The good commands in your folder are the ones you've edited four or five times.

Do this next

If you've written the same prompt twice in a row this month, open Claude Code and ask it to make a slash command for you. Describe the workflow in plain English, name the command after what it does, and let Claude write the file. Three minutes. The next time you type /name, the loop starts compounding.