Expert guidance for creating Claude Code slash commands. Use when working with slash commands, creating custom commands, understanding command structure, or learning YAML configuration.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Expert guidance for creating Claude Code slash commands. Use when working with slash commands, creating custom commands, understanding command structure, or learning YAML configuration.
Create effective slash commands for Claude Code that enable users to trigger reusable prompts with `/command-name` syntax. Slash commands expand as prompts in the current conversation, allowing teams to standardize workflows and operations. This skill teaches you to structure commands with XML tags, YAML frontmatter, dynamic context loading, and intelligent argument handling.
<quick_start>
1. Create `.claude/commands/` directory (project) or use `.claude/commands/` (personal)
2. Create `command-name.md` file
3. Add YAML frontmatter (at minimum: `description`)
4. Write command prompt
5. Test with `/command-name [args]`
**File**: `.claude/commands/optimize.md`
---
description: Analyze this code for performance issues and suggest optimizations
---
Analyze the performance of this code and suggest three specific optimizations:
Usage: /optimize
Claude receives the expanded prompt and analyzes the code in context.
</quick_start>
<xml_structure>
All generated slash commands should use XML tags in the body (after YAML frontmatter) for clarity and consistency.
<required_tags>
<objective> - What the command does and why it matters
<objective>
What needs to happen and why this matters.
Context about who uses this and what it accomplishes.
</objective>
<process> or <steps> - How to execute the command
**Required** - Describes what the command does
**Optional** - Restricts which tools Claude can use
<process>
Sequential steps to accomplish the objective:
1. First step
2. Second step
3. Final step
</process>
<success_criteria> - How to know the command succeeded
<success_criteria>
Clear, measurable criteria for successful completion.
</success_criteria>
# For git commands - prevent running arbitrary bashallowed-tools:Bash(gitadd:*),Bash(gitstatus:*),Bash(gitcommit:*)# For analysis - thinking onlyallowed-tools:SequentialThinking
5. Use $ARGUMENTS for flexibility
Find and fix issue #$ARGUMENTS
6. Reference relevant files
Review @ package.json for dependencies
Analyze @ src/database/* for schema
(Note: Remove the space after @ in actual usage)
</best_practices>
<common_patterns>
Simple analysis command:
---
description: Review this code for security vulnerabilities
---<objective>
Review code for security vulnerabilities and suggest fixes.
</objective><process>1. Scan code for common vulnerabilities (XSS, SQL injection, etc.)
2. Identify specific issues with line numbers
3. Suggest remediation for each issue
</process><success_criteria>- All major vulnerability types checked
- Specific issues identified with locations
- Actionable fixes provided
</success_criteria>
Git workflow with context:
---
description: Create a git commit
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
---
<objective>
Create a git commit for current changes following repository conventions.
</objective><context>
- Current status: ! `git status`
- Changes: ! `git diff HEAD`
- Recent commits: ! `git log --oneline -5`
</context><process>
1. Review staged and unstaged changes
2. Stage relevant files
3. Write commit message following recent commit style
4. Create commit
</process><success_criteria>
- All relevant changes staged
- Commit message follows repository conventions
- Commit created successfully
</success_criteria>
Parameterized command:
---
description: Fix issue following coding standards
argument-hint: [issue-number]
---<objective>
Fix issue #$ARGUMENTS following project coding standards.
This ensures bugs are resolved systematically with proper testing.
</objective><process>1. Understand the issue described in ticket #$ARGUMENTS
2. Locate the relevant code in codebase
3. Implement a solution that addresses root cause
4. Add appropriate tests
5. Verify fix resolves the issue
</process><success_criteria>- Issue fully understood and addressed
- Solution follows coding standards
- Tests added and passing
- No regressions introduced
</success_criteria>
File-specific command:
---
description: Optimize code performance
argument-hint: [file-path]
---<objective>
Analyze performance of @ $ARGUMENTS and suggest specific optimizations.
This helps improve application performance through targeted improvements.
</objective><process>1. Review code in @ $ARGUMENTS for performance issues
2. Identify bottlenecks and inefficiencies
3. Suggest three specific optimizations with rationale
4. Estimate performance impact of each
</process><success_criteria>- Performance issues clearly identified
- Three concrete optimizations suggested
- Implementation guidance provided
- Performance impact estimated
</success_criteria>
Is it simple (single-step) or complex (multi-step)?
Create frontmatter:
---name:command-namedescription:Cleardescriptionofwhatitdoesargument-hint: [input] # Only if arguments neededallowed-tools: [...] # Only if tool restrictions needed---
Create XML-structured body:
Always include:
<objective> - What and why
<process> - How to do it (numbered steps)
<success_criteria> - Definition of done
Include when relevant:
<context> - Dynamic state (! commands) or file references (@ files)
<verification> - Checks to perform if creating artifacts
<testing> - Test commands if tests are part of workflow
<output> - Files created/modified
Integrate $ARGUMENTS properly:
If user input needed: Add argument-hint and use $ARGUMENTS in tags
If self-contained: Omit argument-hint and $ARGUMENTS
Apply intelligence:
Simple commands: Keep it concise (objective + process + success criteria)
Complex commands: Add context, verification, testing as needed
