Create Slash Command Guide
This skill helps you create custom Claude Code slash commands - reusable prompts stored as Markdown files that can be invoked with /command-name syntax. Slash commands are ideal for frequently-used prompts that you want to trigger explicitly.
Quick Start
When creating a new slash command, follow this workflow:
- Identify the purpose - What reusable prompt do you need?
- Choose scope - Project-level (.claude/commands/) or personal (~/.claude/commands/)?
- Select name - Clear, descriptive filename without .md extension
- Design arguments - Will it use $ARGUMENTS, $1/$2/$3, or none?
- Add frontmatter - Optional metadata (description, tools, model)
- Write prompt - The markdown content that becomes the prompt
- Test invocation - Verify command works with various arguments
Basic Syntax
Commands are invoked with:
/command-name [arguments]
The command name comes from the filename without .md extension.
File Locations
Project Commands (.claude/commands/)
- Scope: Project-specific, shared with team via git
- Label: Shows as "(project)" in help listing
- Use for: Team workflows, project conventions, shared prompts
# Create project command
echo "Review this code for security vulnerabilities" > .claude/commands/security-review.md
Example structure:
.claude/commands/
├── review.md # /review
├── optimize.md # /optimize
├── test.md # /test
└── frontend/
└── component.md # /component (project:frontend)
Personal Commands (~/.claude/commands/)
- Scope: Available across all projects
- Label: Shows as "(user)" in help listing
- Use for: Personal productivity, individual workflows, cross-project utilities
# Create personal command
echo "Explain this code in simple terms" > ~/.claude/commands/explain.md
Example structure:
~/.claude/commands/
├── explain.md # /explain (user)
├── refactor.md # /refactor (user)
└── snippets/
└── doc.md # /doc (user:snippets)
Argument Handling
No Arguments
Simple commands that don't need input:
Review the current codebase for potential improvements and suggest optimizations.
Usage: /review
All Arguments with $ARGUMENTS
Captures everything passed to the command:
Fix issue #$ARGUMENTS following our coding standards and best practices.
Usage:
/fix-issue 123/fix-issue 123 high-priority security
Positional Arguments with $1, $2, $3, etc.
Access specific arguments by position:
Review PR #$1 with priority $2 and assign to $3 for review.
Usage: /review-pr 456 high alice
Benefits:
- Access arguments in different parts of the prompt
- Provide defaults for missing arguments
- Build structured commands with specific parameter roles
- Clearer intent for multi-parameter commands
Combining Arguments
Use both positional and all arguments:
Create a $1 feature called "$2" with the following requirements:
$ARGUMENTS
Usage: /create-feature backend "user authentication" JWT tokens, role-based access, password hashing
Frontmatter Configuration
Add optional metadata at the top of your command file:
---
allowed-tools: Read, Write, Edit, Bash
argument-hint: <issue-number> [priority]
description: Fix GitHub issue following coding standards
model: claude-3-5-sonnet-20241022
---
Your command prompt content goes here...
Frontmatter Fields
allowed-tools: Restrict which tools Claude can use
allowed-tools: Read, Write, Edit, Bash
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
argument-hint: Show expected arguments in autocomplete
argument-hint: <file-path>
argument-hint: <pr-number> [priority] [assignee]
argument-hint: [message]
description: Brief command description (overrides first line)
description: Create a git commit with proper formatting
model: Specific model to use for this command
model: claude-3-5-haiku-20241022 # Fast, cheap
model: claude-3-5-sonnet-20241022 # Balanced
model: claude-opus-4-20250514 # Advanced
disable-model-invocation: Prevent auto-invocation via SlashCommand tool
disable-model-invocation: true
Advanced Features
File References with @
Include file contents in your command:
---
description: Review code implementation
---
Review the implementation in @src/utils/helpers.js and compare it with @src/utils/legacy.js.
Identify:
- Code quality improvements
- Performance optimizations
- Security vulnerabilities
Usage: /review-implementation
Bash Command Execution with !
Execute bash commands and include output (requires allowed-tools):
---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
description: Create a git commit
---
Create a git commit with the following context:
**Current Status:**
!`git status`
**Recent Changes:**
!`git diff HEAD`
**Commit Message:** $ARGUMENTS
Usage: /commit "Add user authentication feature"
Extended Thinking
Trigger extended reasoning by including keywords in the command content:
---
description: Analyze complex architectural decisions
---
Please use extended thinking to analyze the following architectural decision:
$ARGUMENTS
Consider:
- Scalability implications
- Maintenance overhead
- Team expertise requirements
- Long-term technical debt
Namespacing with Subdirectories
Organize commands in subdirectories (affects description, not command name):
.claude/commands/
├── git/
│ ├── commit.md # /commit (project:git)
│ └── review.md # /review (project:git)
└── frontend/
└── component.md # /component (project:frontend)
The subdirectory appears in the description but doesn't change the command invocation.
Complete Examples
1. Simple Code Review Command
File: .claude/commands/review.md
---
description: Comprehensive code review for quality and security
---
Review this code for:
- Code quality and maintainability
- Security vulnerabilities
- Performance optimizations
- Best practices adherence
- Potential bugs or edge cases
Provide specific, actionable feedback with code examples.
Usage: /review
2. Issue Fix Command with Arguments
File: .claude/commands/fix-issue.md
---
argument-hint: <issue-number> [priority]
description: Fix GitHub issue following coding standards
---
Fix issue #$1 following our coding standards.
Priority: $2
Steps:
1. Read the issue details from GitHub
2. Analyze the problem and root cause
3. Implement the fix with tests
4. Update documentation if needed
5. Create a commit with proper message format
Usage:
/fix-issue 123 high/fix-issue 456
3. PR Creation with Template
File: .claude/commands/create-pr.md
---
allowed-tools: Bash(git *), Read, Write
argument-hint: <title> [description]
description: Create GitHub pull request with template
model: claude-3-5-sonnet-20241022
---
Create a GitHub pull request with the following details:
**Title:** $1
**Description:** $2
**Context:**
**Current Branch:**
!`git branch --show-current`
**Changes:**
!`git diff main...HEAD --stat`
**Commits:**
!`git log main..HEAD --oneline`
Generate a comprehensive PR description following our template at @.github/pull_request_template.md
Usage: /create-pr "Add user authentication" "Implements JWT-based authentication system"
4. Test Runner Command
File: .claude/commands/test.md
---
allowed-tools: Bash, Read, Grep
argument-hint: [file-pattern]
description: Run tests and analyze failures
model: claude-3-5-haiku-20241022
---
Run tests matching pattern: $ARGUMENTS
Steps:
1. Execute test suite
2. Analyze any failures
3. Suggest fixes for failing tests
4. Validate fixes and re-run
Provide clear, actionable feedback on test failures.
Usage:
/test/test auth/test src/components/Button.test.ts
5. Documentation Generator
File: .claude/commands/document.md
---
allowed-tools: Read, Write, Grep, Glob
description: Generate comprehensive documentation
---
Generate comprehensive documentation for: $ARGUMENTS
Include:
- Overview and purpose
- API reference
- Usage examples
- Configuration options
- Best practices
- Common pitfalls
Format output in clear, professional markdown.
Usage: /document src/utils/api-client.ts
6. Code Optimization Command
File: .claude/commands/optimize.md
---
description: Analyze and optimize code performance
---
Analyze this code for performance optimizations:
$ARGUMENTS
Focus on:
- Algorithm complexity (O(n) analysis)
- Memory usage and allocations
- Database query efficiency
- Caching opportunities
- Parallel processing potential
- Resource cleanup and lifecycle management
Provide specific refactoring suggestions with before/after examples.
Usage: /optimize
7. Multi-Argument PR Review
File: .claude/commands/review-pr.md
---
allowed-tools: Bash(gh *), Read
argument-hint: <pr-number> <priority> [assignee]
description: Review pull request with priority and assignment
---
Review PR #$1 with priority: $2
**PR Details:**
!`gh pr view $1`
**Changes:**
!`gh pr diff $1`
Review focus areas based on priority $2:
- high: Security, breaking changes, data integrity
- medium: Code quality, tests, documentation
- low: Style, minor improvements
Assign to: $3 (if provided)
Provide comprehensive feedback organized by:
1. Critical issues (blocking)
2. Important suggestions
3. Minor improvements
4. Positive observations
Usage: /review-pr 123 high alice
8. Git Workflow Command
File: .claude/commands/git-flow.md
---
allowed-tools: Bash(git *)
argument-hint: <action> <branch-name>
description: Execute git workflow actions
---
Execute git workflow action: $1
Branch: $2
**Current Status:**
!`git status`
**Available Branches:**
!`git branch -a`
Actions:
- start: Create and checkout new branch
- finish: Merge branch and delete
- sync: Pull latest and rebase
- review: Show branch diff
Additional context: $ARGUMENTS
Usage:
/git-flow start feature/auth/git-flow finish bugfix/login/git-flow sync
9. Database Query Optimization
File: ~/.claude/commands/optimize-query.md
---
description: Optimize database queries for performance
---
Analyze and optimize this database query:
$ARGUMENTS
Optimization checklist:
- [ ] Execution plan analysis
- [ ] Index usage and recommendations
- [ ] Query rewrite opportunities
- [ ] JOIN optimization
- [ ] Subquery vs JOIN performance
- [ ] Parameter binding and caching
- [ ] Result set size and pagination
Provide:
1. Performance analysis
2. Optimized query
3. Index recommendations
4. Before/after execution plan comparison
Usage: /optimize-query
10. Complex Issue Creation
File: .claude/commands/create-issue.md
---
allowed-tools: Bash(gh *), Read
argument-hint: <title> <type>
description: Create detailed GitHub issue with template
model: claude-3-5-sonnet-20241022
---
Create a GitHub issue with:
**Title:** $1
**Type:** $2 (feature/bug/enhancement/docs)
**Repository Analysis:**
!`gh repo view --json name,description,url`
**Template:**
@.github/ISSUE_TEMPLATE/$2.md
Generate a comprehensive issue following our template structure with:
- Clear problem statement
- Proposed solution
- Acceptance criteria
- Implementation notes
- Related issues/PRs
Additional context: $ARGUMENTS
Usage: /create-issue "Add dark mode support" feature "Users want theme customization"
Slash Commands vs Skills
When to Use Slash Commands
Characteristics:
- Explicit invocation required (
/command) - Quick, frequently-used prompts
- Simple prompt snippets
- Single-file capabilities
- Manual control over execution
Best for:
- Code review workflows (
/review) - Quick explanations (
/explain) - Frequent operations (
/optimize,/test) - Personal productivity shortcuts
- Team-standardized prompts
When to Use Skills
Characteristics:
- Automatic discovery based on context
- Claude decides when to invoke
- Complex workflows with multiple steps
- Multiple files (scripts, templates, docs)
- Advanced capabilities
Best for:
- PDF processing (auto-invoked when user mentions PDFs)
- API documentation generation (auto-invoked for API tasks)
- Complex multi-step workflows
- Capabilities requiring external scripts
- Knowledge organized across multiple files
Can They Coexist?
Yes! Use both approaches:
- Commands: Explicit, manual shortcuts (
/review-pr) - Skills: Automatic, context-driven capabilities (PDF extraction)
Best Practices Checklist
When creating a slash command:
- [ ] Filename is descriptive and uses kebab-case
- [ ] File location matches scope (project vs personal)
- [ ] Description frontmatter is clear and concise
- [ ] Arguments are well-documented with argument-hint
- [ ] Prompt content is specific and actionable
- [ ] File references (@) use correct paths
- [ ] Bash commands (!) have proper tool restrictions
- [ ] Model selection matches complexity (haiku/sonnet/opus)
- [ ] Command tested with various argument combinations
- [ ] Related commands organized in subdirectories
- [ ] No sensitive data (credentials, API keys) in commands
- [ ] Clear examples in comments or description
Testing Slash Commands
1. Verify Command Appears
List all available commands:
# In Claude Code
/help
Look for your command in the output.
2. Test Basic Invocation
/your-command
Verify the prompt expands correctly.
3. Test with Arguments
/your-command arg1
/your-command arg1 arg2 arg3
Verify argument substitution works.
4. Test File References
If using @file.txt, verify the file exists and is readable.
5. Test Bash Commands
If using !command, verify:
- Command executes successfully
- Output is captured correctly
- Tool restrictions are appropriate
Common Issues
Command not appearing:
- Check filename has
.mdextension - Verify file is in correct location (.claude/commands/ or ~/.claude/commands/)
- Restart Claude Code to reload commands
Arguments not substituting:
- Ensure
$ARGUMENTS,$1,$2syntax is correct - Check for extra spaces or special characters
- Verify arguments are passed when invoking
File references not working:
- Confirm file path is correct (relative to project root)
- Check file exists and is readable
- Verify
@prefix is present
Bash commands failing:
- Add
allowed-tools: Bashto frontmatter - Verify command works independently
- Check tool restriction patterns (e.g.,
Bash(git *))
Description not showing:
- Add
descriptionfield in frontmatter - Ensure frontmatter YAML is valid (opening/closing
---)
Organization Strategies
By Feature Area
.claude/commands/
├── git/
│ ├── commit.md
│ ├── review.md
│ └── workflow.md
├── testing/
│ ├── run.md
│ ├── coverage.md
│ └── debug.md
└── docs/
├── generate.md
└── update.md
By Complexity
~/.claude/commands/
├── quick/ # Simple, haiku-model commands
│ ├── explain.md
│ └── format.md
├── standard/ # Regular sonnet commands
│ ├── review.md
│ └── optimize.md
└── complex/ # Advanced opus commands
└── architect.md
By Team Role
.claude/commands/
├── frontend/
│ ├── component.md
│ └── style.md
├── backend/
│ ├── api.md
│ └── database.md
└── devops/
├── deploy.md
└── monitor.md
Migration from Skills
Converting a skill to a slash command:
Skill (automatic invocation):
---
name: code-explainer
description: Explain code in simple terms when user asks
---
# Code Explainer
Instructions for explaining code...
Slash Command (explicit invocation):
---
description: Explain code in simple terms
---
Explain this code in simple, beginner-friendly terms:
$ARGUMENTS
Include:
- What the code does
- How it works
- Why it's structured this way
- Common use cases
Usage: /explain
Security Considerations
Avoid:
- Hardcoding credentials or API keys
- Network calls without encryption
- Destructive commands without confirmation
- Accessing sensitive files unnecessarily
Safe practices:
- Use environment variables for secrets
- Validate file paths before access
- Restrict bash command patterns
- Log command execution for audit trails
Advanced Patterns
Template-Based Commands
---
description: Create component from template
---
Create a new $1 component named $2:
**Template:**
@templates/$1-template.tsx
**Destination:**
src/components/$2/
Generate files:
1. Component implementation
2. Test file
3. Styles
4. Documentation
5. Storybook story
Usage: /create-component button UserProfileButton
Multi-Step Workflows
---
allowed-tools: Bash, Read, Write, Edit
description: Complete feature implementation workflow
---
Implement feature: $ARGUMENTS
Workflow:
1. Create feature branch
2. Generate boilerplate code
3. Implement core logic
4. Add tests
5. Update documentation
6. Run quality checks
7. Create PR
Execute each step with confirmation.
Usage: /feature-workflow "user authentication"
Context-Rich Commands
---
allowed-tools: Bash(git *), Read
description: Comprehensive code review with full context
---
Review code with full context:
**Project Structure:**
!`find . -type f -name "*.ts" -o -name "*.tsx" | head -20`
**Recent Changes:**
!`git log --oneline -10`
**Modified Files:**
!`git diff --name-only HEAD~5..HEAD`
**Code to Review:**
$ARGUMENTS
Provide comprehensive feedback considering project context.
Key Principles
- Descriptive names - Clear, action-oriented command names
- Explicit invocation - Users trigger commands intentionally
- Argument clarity - Use argument-hint for discoverability
- Scope appropriately - Project commands for team, personal for you
- Tool restrictions - Only grant necessary tool access
- Model selection - Match model to task complexity
- Organization - Use subdirectories for related commands
- Documentation - Clear descriptions and argument hints
- Testing - Verify with various inputs before sharing
- Security - Never hardcode sensitive data
Workflow Summary
When user asks to create a slash command:
- Clarify purpose - What prompt should be reusable?
- Choose scope - Project or personal command?
- Design arguments - $ARGUMENTS, $1/$2/$3, or none?
- Select name - Descriptive, kebab-case filename
- Add frontmatter - Description, tools, model, argument-hint
- Write prompt - Clear, actionable command content
- Add features - File references (@), bash commands (!)
- Test thoroughly - Various arguments, edge cases
- Document usage - Examples in comments or description
- Share if needed - Commit project commands to git
Remember: Slash commands are for explicit, manual invocation of frequently-used prompts. Use skills for automatic, context-driven capabilities.