7.5 KiB
7.5 KiB
name, description
| name | description |
|---|---|
| Slash Command Creator | Create custom slash commands for Claude Code with argument handling, bash execution, and file references. Use PROACTIVELY when building reusable prompts, automating workflows, creating project-specific commands, or when users mention "create a command", "reusable prompt", "/something", or "slash command". NOT for complex multi-file operations. |
Slash Command Development
When to Use This Skill
Use this skill when:
- Creating custom slash commands for Claude Code
- Building reusable prompt templates
- Automating repetitive tasks with commands
- Setting up project-specific workflows
- Converting manual prompts to slash commands
Do NOT use this skill for:
- Creating full plugins (use claude-plugin skill)
- Setting up hooks (use claude-hooks skill)
- Complex multi-file operations (use subagents)
Quick Start
Create Command File
# Project-specific (team shared)
mkdir -p .claude/commands
cat > .claude/commands/review.md << 'EOF'
---
description: Review code for common issues
---
Review the following code for:
- Bugs and logic errors
- Code style issues
- Performance problems
- Security vulnerabilities
$ARGUMENTS
EOF
Usage: /review @src/main.js
Command Locations
| Location | Scope | Version Control | Use For |
|---|---|---|---|
.claude/commands/ |
Project (team) | In git | Team workflows, standards |
~/.claude/commands/ |
User (personal) | Not in git | Personal productivity |
Command Syntax
Basic Structure
---
description: Brief description for /help
---
Prompt content here
$ARGUMENTS
Filename = Command Name
# File: .claude/commands/test.md
# Command: /test
# File: .claude/commands/commit-push.md
# Command: /commit-push
Frontmatter Options
---
description: Generate unit tests for a function # Shows in /help
argument-hint: <file-path> <function-name> # Autocomplete hint
allowed-tools: Read(*), Bash(git:*) # Tool permissions
model: claude-haiku-4 # Override default model
disable-model-invocation: true # Prevent auto-invocation
---
Argument Handling
$ARGUMENTS - All Arguments
---
description: Explain multiple files
---
Explain these files: $ARGUMENTS
Usage: /explain @src/a.js @src/b.js @src/c.js
Positional ($1, $2, $3...)
---
description: Compare two approaches
argument-hint: <approach1> <approach2>
---
Compare approach "$1" versus "$2" and recommend which is better.
Usage: /compare REST GraphQL
File References with @
---
description: Review a file
---
Review @$1 for code quality issues.
Usage: /review src/auth.js
Claude reads src/auth.js automatically.
Bash Execution with !
Prefix commands with ! to execute before processing:
---
description: Show git status and suggest next steps
allowed-tools: Bash(git status:*), Bash(git diff:*)
---
!git status
!git diff --stat
Based on the current git state, suggest what I should do next.
Important: Must include allowed-tools with Bash specifications.
Complete Examples
Security Review
---
description: Comprehensive security review of code files
allowed-tools: Read(*), Grep(*)
argument-hint: <files...>
---
Perform a security audit on: $ARGUMENTS
Check for:
1. SQL injection vulnerabilities
2. XSS vulnerabilities
3. Authentication/authorization issues
4. Hardcoded secrets or credentials
5. Unsafe deserialization
6. Path traversal vulnerabilities
For each issue found:
- Severity level (Critical/High/Medium/Low)
- Location (file:line)
- Explanation of the vulnerability
- Recommended fix with code example
Commit + Push
---
description: Review changes, commit, and push to remote
allowed-tools: Bash(git:*)
---
!git status
!git diff
Review the changes above and:
1. Create an appropriate commit message
2. Commit the changes
3. Push to remote
Ask for confirmation before pushing.
Test Generator
---
description: Generate comprehensive tests for a function
argument-hint: <file> <function-name>
model: claude-sonnet-4
---
For the function "$2" in @$1:
1. Analyze the function's behavior
2. Identify edge cases
3. Generate comprehensive unit tests including:
- Happy path tests
- Edge case tests
- Error condition tests
- Boundary value tests
Use the project's existing test framework and patterns.
For more examples, see examples.md
Command Patterns
Review Pattern
---
description: Review X for Y
---
Review $ARGUMENTS for [specific criteria]
Include:
- [Aspect 1]
- [Aspect 2]
Generate Pattern
---
description: Generate X from Y
---
Generate [output type] for: $ARGUMENTS
Requirements:
- [Requirement 1]
- [Requirement 2]
Compare Pattern
---
description: Compare X and Y
argument-hint: <option1> <option2>
---
Compare "$1" versus "$2"
Analyze:
- [Comparison aspect 1]
- [Comparison aspect 2]
Recommendation: [Which is better and why]
Testing Commands
# See all available commands
/help
# Test with different arguments
/mycommand arg1
/mycommand @file.js
/mycommand @file1.js @file2.js
Best Practices
1. Clear Descriptions
# Good
description: Generate unit tests for a specific function
# Bad
description: Testing
2. Explicit Arguments
# Good
argument-hint: <file-path> <function-name>
# Bad (no hint)
3. Specific Tool Permissions
# Good - minimal permissions
allowed-tools: Bash(git status:*), Bash(git diff:*)
# Risky - too permissive
allowed-tools: *
4. Meaningful Names
# Good
/generate-tests
/review-security
/commit-and-push
# Bad
/gt
/rs
/cap
5. Self-Documenting Content
Review code for:
1. Logic errors
2. Style issues
3. Performance problems
$ARGUMENTS
Troubleshooting
| Problem | Solution |
|---|---|
| Command not found | Check file is in .claude/commands/, ends with .md |
| Arguments not working | Use $ARGUMENTS, $1, $2 (not ${ARGUMENTS}) |
| Bash not executing | Add allowed-tools frontmatter with Bash() pattern |
| File references not loading | Verify file path, use @ prefix |
Security Considerations
Limit Tool Access
# Specific commands only
allowed-tools: Bash(git status:*), Bash(git log:*)
# Never use unless required
allowed-tools: *
No Hardcoded Secrets
# Bad - hardcoded API key
!curl -H "API-Key: sk-abc123..." api.example.com
# Good - use environment variables
!curl -H "API-Key: $MY_API_KEY" api.example.com
Validate User Input
# Risky - no validation
!rm -rf $1
# Better - validate first
Confirm you want to delete: $1
(Then use interactive confirmation)
Command Template
---
description: [Clear, concise description]
argument-hint: [Expected arguments]
allowed-tools: [Specific patterns if needed]
---
[Command prompt template]
$ARGUMENTS
Resources
- Complete Examples - Working command configurations
- Advanced Patterns - Complex workflows
- Official Documentation
- Plugin Development - Packaging commands
Remember: Slash commands are for reusable prompts. Start with manual prompts, identify patterns you repeat, then codify them as commands.