Lesson 19: Slash Commands

Day 19 of 50 · ~7 min read · Phase 3: Customization

The Opening Question

You're in a Claude Code conversation. You've been working with Claude for a while, and you keep asking for the same things repeatedly.

"Check if the tests pass." "Show me a summary of what you just did." "Clear the conversation and start fresh." "Review my changes before I commit them."

Each time you type one of these, Claude understands and does it. But wouldn't it be nice if you could just type a shorthand — a command that Claude instantly recognizes?

Here's the question: What if your most common workflows could be one-word commands?

Discovery

Let's explore how slash commands work and why they matter.

Question 1: What are slash commands?

You've probably seen slash commands in other tools. Slack has them (/remind, /status). GitHub has them (/cc to mention someone). They're shortcuts.

Claude Code also has slash commands.

But what does a slash command actually do?

Pause and think: When you type a slash command, what should happen differently from typing regular text?

A slash command is shorthand for a common task. Instead of typing "Run the test suite and tell me if it passes," you type /test. Claude knows what you mean.

Slash commands are useful for two reasons:

1. Speed. You don't have to type out the full request each time.
2. Consistency. Claude understands exactly what you want because the command is predefined. No ambiguity.

Question 2: What built-in slash commands does Claude Code have?

Claude Code comes with several slash commands built-in. Here are the main ones:

/help — Shows available commands and what they do. Useful if you forget what's available.

/compact — Compresses the conversation history to save tokens. When you've been talking to Claude for a while and the context window is getting full, this lets you keep working without starting a new conversation.

/clear — Clears the conversation history and starts fresh. Useful when you want to move on to a completely different task.

/review — Claude reviews the changes it's made and summarizes what's different from the original. Kind of like git diff but more readable.

/commit — Suggests commit messages and creates a git commit for the changes Claude made.

/test — Runs your project's test suite and shows you the results.

/bug — When something goes wrong, typing /bug followed by error details helps Claude focus on fixing the problem.

/status — Shows what Claude is currently working on or waiting for.

Each of these is a shorthand that saves you from typing out the full intent.

Question 3: Why would you create custom slash commands?

The built-in commands cover common tasks. But every project is different.

Maybe your team has a specific deployment process. Maybe you have custom linting rules. Maybe your project has a "release checklist" you run before shipping.

Why would you want to turn these into slash commands?

Pause and think: What are the repetitive tasks you do in Claude Code conversations? What explanations do you find yourself repeating?

Custom slash commands let you encode these workflows. For example:

• /format — runs your code formatter (prettier, black, etc.) on all changed files
• /lint — runs your linter and applies auto-fixes
• /prepush — runs tests, checks for console.log statements, and verifies git status
• /docs — updates your README and generates API documentation for the changes
• /deploy-staging — runs tests, builds a Docker image, and deploys to staging

Instead of explaining these steps every time, you just type /deploy-staging and Claude knows the full workflow.

Question 4: How do you create a custom slash command?

Custom slash commands are defined in .claude/ — the same directory where your settings and rules live.

You create a file in .claude/commands/ with a markdown format. Here's what it looks like:

# /release

Release the current version to production.

## Steps
1. Run tests
2. Update version in package.json
3. Create a git tag
4. Push to main
5. Deploy to production

When you type /release, Claude reads this file and executes the steps. The file is just instructions, but Claude understands it as a workflow.

You can make commands as simple or complex as you want:

Simple:

# /format

Format all changed files using prettier.

Complex:

# /prepush

This command runs before pushing code. Execute in this order:
1. Run tests: npm test
2. Run linter: npm run lint -- --fix
3. Show git status: git status
4. Ask me to review before pushing

The beauty of this system is that you're not writing code. You're just documenting your workflow in a way Claude understands.

Pause and think: What workflows do you run repeatedly? What could you simplify?

The Insight

Here's what's really happening with slash commands:

Slash commands turn your workflows into verbs that Claude understands. Instead of explaining the same multi-step process repeatedly, you define it once in a command file, and then trigger it with a single word. This makes common tasks faster, more consistent, and easier to share with your team.

The mental model: Slash commands are like macros or aliases for your workflows. Just as ll is shorthand for ls -la, /prepush is shorthand for "run tests, lint, and check git status." You define them once, use them constantly.

Try It

Let's create your first custom slash command.

1. In your project root, create the commands directory:

   mkdir -p .claude/commands
   

2. Create a simple command file:

   cat > .claude/commands/status.md << 'EOF'
   # /status
   
   Show a summary of the current project state.
   
   ## Steps
   1. Show the project structure (top-level files and folders)
   2. Run `git status` to show uncommitted changes
   3. Show what's in .gitignore
   4. List any TODO comments in the code
   EOF
   

3. Start a conversation with Claude:

   claude
   

4. Try your command:

   /status
   

   Claude should read your command definition and execute the steps.

5. Create a second command. Think of a workflow you run often and encode it:

   cat > .claude/commands/precommit.md << 'EOF'
   # /precommit
   
   Prepare changes for commit.
   
   ## Steps
   1. Run tests
   2. Show the diff (git diff or /review)
   3. Suggest a commit message
   EOF
   

6. Try it: Type /precommit in your conversation.

Key Concepts Introduced

Bridge to Lesson 20

You've now created custom commands that Claude understands. But here's a deeper question:

What if Claude could remember patterns from one session to the next? What if it learned what your project's conventions are, and didn't have to be told again?

Tomorrow's question: How does Claude learn from experience across sessions?

We'll explore rules and memory — ways to teach Claude about your project's patterns so it gets smarter over time.

← Back to Curriculum · Lesson 20 →