Claude Code Slash Commands: Built-In and Custom Commands

Slash commands are how you interact with Claude Code's features and invoke custom workflows. Type / in the Claude Code CLI and you'll see a list of available commands. Some are built into Claude Code, and others are custom commands you define as skills.

This guide covers every built-in command and shows you how to create powerful custom commands for your own workflows.

Built-In Commands

These commands are always available in Claude Code. They control the session, manage context, and access core features.

Session Management

Workflow Commands

Context Commands

Custom Slash Commands (Skills)

Custom commands are the real power of slash commands. They're markdown files stored in .claude/skills/ that define reusable prompts invoked with a slash command. When you type the command, Claude loads the skill's instructions and follows them.

Creating your first custom command

Create a file at .claude/skills/review.md:

---
name: Security Review
description: Review code for security vulnerabilities
command: /security-review
---

# Security Code Review

Review the provided code for security vulnerabilities.
Focus on OWASP Top 10 categories:

1. Injection (SQL, NoSQL, OS command, LDAP)
2. Broken authentication
3. Sensitive data exposure
4. XML external entities (XXE)
5. Broken access control
6. Security misconfiguration
7. Cross-site scripting (XSS)
8. Insecure deserialization
9. Using components with known vulnerabilities
10. Insufficient logging and monitoring

For each finding, provide:
- **Severity**: Critical / High / Medium / Low
- **Location**: File and line reference
- **Issue**: What the vulnerability is
- **Fix**: Concrete code fix or recommendation

Now typing /security-review apps/api/src/routes/auth.ts runs a focused security audit on that file.

The YAML frontmatter

The frontmatter at the top of each skill file defines metadata:

---
name: Human-readable name shown in command list
description: Brief description shown in autocomplete
command: /your-command-name
---

• name -- displayed in the skill list and autocomplete
• description -- shown as a subtitle in autocomplete hints
• command -- the slash command that triggers this skill (must start with /)

Skill content best practices

• Be directive, not conversational. Skills are instructions, not conversations. Use imperative verbs: "Review the code", "Write tests", "Create a migration."
• Include output format. Tell Claude exactly how to structure its response -- bullet points, tables, code blocks, etc.
• Add examples. Show what good output looks like. Claude follows examples closely.
• Keep skills focused. One skill per workflow. A "do everything" skill is less effective than three focused ones.

Example Custom Commands

/tdd -- Test-Driven Development

---
name: TDD Workflow
description: Strict test-driven development cycle
command: /tdd
---

Follow strict TDD for every change:

1. Write a failing test FIRST. Run it. Confirm the failure.
2. Write the MINIMUM code to pass the test.
3. Run the test. Confirm it passes.
4. Refactor if needed. Run tests again.

Rules:
- Never write production code without a failing test
- Each test should test one behavior
- Use descriptive test names: "should [behavior] when [condition]"
- Keep the red-green-refactor cycle tight

/component -- React Component Generator

---
name: React Component
description: Create a new React component with tests
command: /component
---

Create a new React component following our project conventions:

1. Component file: src/components/{Name}/{Name}.tsx
   - Use function component with TypeScript
   - Props interface named {Name}Props
   - Use named export

2. Test file: src/components/{Name}/{Name}.test.tsx
   - Use React Testing Library
   - Test rendering, interactions, and edge cases

3. Index barrel: src/components/{Name}/index.ts
   - Re-export the component

4. Styles: src/components/{Name}/{Name}.module.css
   - CSS modules, BEM-inspired naming

/debug -- Systematic Debugging

---
name: Debug
description: Systematic debugging workflow
command: /debug
---

Follow a systematic debugging approach:

1. REPRODUCE: Understand and reproduce the issue
   - What is the expected behavior?
   - What is the actual behavior?
   - What are the steps to reproduce?

2. ISOLATE: Narrow down the cause
   - Check recent changes (git log, git diff)
   - Add logging/breakpoints to trace execution
   - Binary search through the code path

3. IDENTIFY: Find the root cause
   - Don't fix symptoms -- find the underlying issue
   - Explain WHY the bug exists, not just WHERE

4. FIX: Apply a targeted fix
   - Minimal change to fix the root cause
   - Don't refactor unrelated code

5. VERIFY: Confirm the fix
   - Write a test that would have caught this bug
   - Run the full test suite
   - Manually verify the original reproduction steps

Organizing Commands for Teams

For teams, maintain a curated set of commands in your repository's .claude/skills/ directory. A typical team setup:

.claude/
  skills/
    review.md          # /review - Code review
    tdd.md             # /tdd - Test-driven development
    api-endpoint.md    # /api - New API endpoint scaffold
    db-migrate.md      # /migrate - Database migration workflow
    deploy-checklist.md # /deploy - Pre-deployment checklist
    debug.md           # /debug - Systematic debugging

Commit these to your repository. Every team member gets the same commands, and they evolve with your codebase. When someone discovers a better workflow, they update the skill file and everyone benefits.

Custom Commands vs Built-In Commands

A common question: what if your custom command has the same name as a built-in command? Built-in commands take precedence. If you define a skill with command: /clear, the built-in /clear will still run. Choose unique command names for your skills.

Tips for Effective Commands

• Use descriptive names. /security-review is better than /sr. You'll forget what abbreviations mean.
• Include the command in your CLAUDE.md. Add a section listing available custom commands so Claude (and your team) knows what's available.
• Version your skills. Since skills live in your git repo, they're versioned automatically. Use PRs to review changes to team skills.
• Combine with hooks for enforcement. A skill tells Claude what to do; a hook ensures it happens.
• Keep skills under 500 words. Longer skills eat into your context window. Be precise and directive.