How to Build Custom Slash Commands for Claude Code

You've probably typed the same prompt into Claude Code a dozen times this week. "Review this file for bugs." "Write a commit message for these changes." "Create a spec for this feature." Every time, you're writing it from scratch, adjusting the wording, hoping you remembered all the constraints you care about.

Claude Code slash commands fix this. They let you save prompts as reusable commands that you invoke with a / prefix. Once you understand how they work, you'll never write the same prompt twice.

What slash commands actually are

A slash command is a markdown file that contains a prompt template. You put it in the right directory, and Claude Code picks it up automatically. Type / in the chat, and your commands show up in an autocomplete menu alongside the built-in ones.

That's it. No plugin API, no build step, no configuration file. A markdown file in a folder.

This simplicity is the point. Commands are version-controlled, shareable, and editable with any text editor. Your whole team gets the same workflows just by pulling the repo.

Where commands live

Claude Code looks for custom commands in two places:

• Project commands: .claude/commands/ in your repo root — shared with the team via git
• User commands: ~/.claude/commands/ in your home directory — personal commands across all projects

Project commands are the ones you'll use most. They travel with the codebase and encode your team's conventions. User commands are for personal shortcuts that don't belong in any specific repo.

The directory structure is flat. Each .md file becomes a command. Subdirectories create namespaced commands with colons:

.claude/commands/
├── review.md              → /review
├── commit.md              → /commit
├── spec.md                → /spec
├── blog-post.md           → /blog-post
└── db/
    ├── migrate.md         → /db:migrate
    └── seed.md            → /db:seed

Anatomy of a command file

A command file is plain markdown. The entire file contents become the prompt sent to Claude when you invoke the command. Here's a minimal example:

Review the code in $ARGUMENTS for:

1. Bugs and logic errors
2. Security vulnerabilities
3. Performance issues
4. Naming and readability

Be specific. Reference line numbers. Suggest fixes, not just problems.

Save that as .claude/commands/review.md, and now /review src/auth/login.ts sends that full prompt to Claude with $ARGUMENTS replaced by src/auth/login.ts.

The $ARGUMENTS variable

$ARGUMENTS is the only built-in variable, and it captures everything typed after the command name. It's how you make commands flexible without making them complicated.

Some commands don't need arguments at all — a /commit command can inspect the current git diff without any input. Others rely heavily on them. Design each command to work naturally with how you'd want to invoke it.

When $ARGUMENTS is empty (the user just typed /review with nothing after it), the literal string $ARGUMENTS stays in the prompt. Handle this by writing commands that make sense either way, or by including instructions for Claude to ask for the missing input.

Four commands worth stealing

These are commands we use daily. Each one replaces a prompt you'd otherwise type out by hand every time.

/commit — structured commit messages

Look at the current git diff (staged changes). Write a commit message following
conventional commits format:

type(scope): short description

Longer body explaining what changed and why. Not how — the diff shows how.

Rules:
- Type must be one of: feat, fix, refactor, docs, style, test, chore
- Scope should be the primary module or area affected
- Subject line under 72 characters
- Body wraps at 80 characters
- If the change is trivial (typo, formatting), skip the body

Output ONLY the commit message, nothing else. No markdown fences.

/review — opinionated code review

Review $ARGUMENTS with the eye of a senior engineer who cares about shipping
reliable software. Check for:

1. **Correctness** — Will this break? Edge cases? Race conditions?
2. **Security** — Input validation, auth checks, injection vectors
3. **Performance** — O(n^2) loops, unnecessary allocations, missing indexes
4. **Maintainability** — Will someone curse this code in six months?

Skip praise. Skip style nits the linter will catch. Focus on things that
matter in production.

Format: list each finding with the file path, line number, severity
(critical/warning/note), and a suggested fix.

/spec — feature specification

Create a feature specification for: $ARGUMENTS

Use this structure:

## Goal
One paragraph. What are we building and why.

## Requirements
Numbered list of concrete, testable requirements.

## Non-Goals
What this spec explicitly does NOT cover.

## Technical Approach
How we'll implement this. Key decisions and trade-offs.

## Tasks
Break the work into ordered tasks. Each task should be completable
in under 2 hours. Use checkbox format:
- [ ] Task description (time estimate)

## Open Questions
Anything unresolved that needs input before starting.

/blog-post — content generation with constraints

Write a blog post about: $ARGUMENTS

Constraints:
- 1,200-1,800 words
- Developer audience, technical but accessible
- Short paragraphs (2-4 sentences max)
- No corporate fluff, no "In today's fast-paced world"
- Include concrete code examples where relevant
- End with a clear takeaway, not a generic CTA

Output as MDX with frontmatter including title, description, date, author,
category, and tags.

How Monday Morning uses commands at scale

Monday Morning ships over 50 custom slash commands that automate project management workflows directly inside Claude Code. Commands like /mm:task, /mm:spec, /mm:review-project, and /mm:daily-brief let developers manage specs, track issues, and run project reviews without leaving their terminal.

The key insight from building that many commands: each command should do exactly one thing. Early on, we tried building Swiss-army-knife commands that handled multiple workflows based on arguments. They were confusing to invoke and produced inconsistent results. Splitting them into focused, single-purpose commands made everything more reliable.

Monday Morning also demonstrates that commands can drive real project structure. The /mm:spec command doesn't just generate text — it creates a folder with the right naming convention, populates spec.md and implementation.md, and links the spec to its parent feature. The prompt includes explicit file paths and formats so Claude produces output that integrates directly into the project's tracking system.

This is what separates toy commands from production workflows: the prompt encodes your project's conventions, not just a generic instruction.

Tips for writing effective commands

After writing dozens of these, patterns emerge for what works and what produces garbage.

Be specific about output format. "Write a summary" gives you unpredictable results. "Write a summary as a markdown list with no more than 5 bullet points, each under 20 words" gives you something consistent every time. Claude follows formatting constraints well — use that.

Include constraints, not just instructions. Tell Claude what NOT to do. "Skip boilerplate explanations." "Do not include import statements unless they're non-obvious." "No markdown fences around the output." Constraints eliminate the most common failure mode: over-verbose, over-helpful responses.

Set the role and standard. "Review this like a senior engineer" produces different output than "review this code." A single sentence of framing changes the depth and focus of the response significantly.

Test with edge cases. Run your command with an empty file, a huge file, a file in a language you didn't expect. Commands that work great on your typical input often fall apart on unusual input. Add handling for those cases in the prompt itself.

Keep commands under 500 words. Long prompts dilute focus. If your command prompt needs more than a page of instructions, you're probably trying to do too much in a single command. Split it up.

How commands differ from CLAUDE.md

This trips people up, so let's be explicit.

CLAUDE.md is passive context. It loads automatically at the start of every conversation. Use it for things Claude should always know: project structure, coding conventions, tech stack, architectural decisions. It's background knowledge.

Slash commands are active workflows. They're invoked on demand for specific tasks. Use them for things you do repeatedly: generating commits, running reviews, creating specs, scaffolding components.

The two work together. Your CLAUDE.md tells Claude about your project's conventions. Your slash commands invoke those conventions in specific workflows. A /commit command works better when CLAUDE.md already explains your commit message format — the command can reference "follow our commit conventions" instead of restating all the rules.

Think of CLAUDE.md as the employee handbook and slash commands as the SOPs for specific procedures.

Getting started

Create the directory and add your first command:

mkdir -p .claude/commands

Write a command for whatever you prompted Claude to do most recently. If you've typed it more than twice, it should be a command. Start with /commit and /review — they have the highest daily ROI.

Commit the commands directory to git. Your whole team benefits immediately.

If you want to skip the bootstrapping phase, Monday Morning ships a full suite of project management commands out of the box. Install it, run mm init, and you get 50+ battle-tested commands for specs, tasks, issues, reviews, and daily workflow. But even without Monday Morning, the pattern is powerful on its own. A few well-written markdown files can transform how you work with Claude Code.