---
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

<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>

</required_tags>

<conditional_tags>

<context> - When loading dynamic state or files

<context>
Current state: ! `git status`
Relevant files: @ package.json
</context>

(Note: Remove the space after @ in actual usage)

<verification> - When producing artifacts that need checking

<verification>
Before completing, verify:
- Specific test or check to perform
- How to confirm it works
</verification>

<testing> - When running tests is part of the workflow

<testing>
Run tests: ! `npm test`
Check linting: ! `npm run lint`
</testing>

<output> - When creating/modifying specific files

<output>
Files created/modified:
- `./path/to/file.ext` - Description
</output>

</conditional_tags>

<structure_example>

---
name: example-command
description: Does something useful
argument-hint: [input]
---

<objective>
Process $ARGUMENTS to accomplish [goal].

This helps [who] achieve [outcome].
</objective>

<context>
Current state: ! `relevant command`
Files: @ relevant/files
</context>

<process>
1. Parse $ARGUMENTS
2. Execute operation
3. Verify results
</process>

<success_criteria>
- Operation completed without errors
- Output matches expected format
</success_criteria>

</structure_example>

<intelligence_rules>

Simple commands (single operation, no artifacts):

Required: <objective>, <process>, <success_criteria>
Example: /check-todos, /first-principles

Complex commands (multi-step, produces artifacts):

Required: <objective>, <process>, <success_criteria>
Add: <context> (if loading state), <verification> (if creating files), <output> (what gets created)
Example: /commit, /create-prompt, /run-prompt

Commands with dynamic arguments:

Use $ARGUMENTS in <objective> or <process> tags
Include argument-hint in frontmatter
Make it clear what the arguments are for

Commands that produce files:

Always include <output> tag specifying what gets created
Always include <verification> tag with checks to perform

Commands that run tests/builds:

Include <testing> tag with specific commands
Include pass/fail criteria in <success_criteria> </intelligence_rules> </xml_structure>

<arguments_intelligence> The skill should intelligently determine whether a slash command needs arguments.

<commands_that_need_arguments>

User provides specific input:

/fix-issue [issue-number] - Needs issue number
/review-pr [pr-number] - Needs PR number
/optimize [file-path] - Needs file to optimize
/commit [type] - Needs commit type (optional)

Pattern: Task operates on user-specified data

Include argument-hint: [description] in frontmatter and reference $ARGUMENTS in the body. </commands_that_need_arguments>

<commands_without_arguments>

Self-contained procedures:

/check-todos - Operates on known file (TO-DOS.md)
/first-principles - Operates on current conversation
/whats-next - Analyzes current context

Pattern: Task operates on implicit context (current conversation, known files, project state)

Omit argument-hint and don't reference $ARGUMENTS. </commands_without_arguments>

<incorporating_arguments>

In <objective> tag:

<objective>
Fix issue #$ARGUMENTS following project conventions.

This ensures bugs are resolved systematically with proper testing.
</objective>

In <process> tag:

<process>
1. Understand issue #$ARGUMENTS from issue tracker
2. Locate relevant code
3. Implement fix
4. Add tests
</process>

In <context> tag:

<context>
Issue details: @ issues/$ARGUMENTS.md
Related files: ! `grep -r "TODO.*$ARGUMENTS" src/`
</context>

(Note: Remove the space after the exclamation mark in actual usage) </incorporating_arguments>

<positional_arguments>

For structured input, use $1, $2, $3:

---
argument-hint: <pr-number> <priority> <assignee>
---

<objective>
Review PR #$1 with priority $2 and assign to $3.
</objective>

Usage: /review-pr 456 high alice </positional_arguments> </arguments_intelligence>

<file_structure>

Project commands: .claude/commands/

Shared with team via version control
Shows (project) in /help list

Personal commands: ~/.claude/commands/

Available across all your projects
Shows (user) in /help list

File naming: command-name.md → invoked as /command-name </file_structure>

<yaml_frontmatter>

description: Analyze this code for performance issues and suggest optimizations

Shown in the /help command list.

allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)

Formats:

Array: allowed-tools: [Read, Edit, Write]
Single tool: allowed-tools: SequentialThinking
Bash restrictions: allowed-tools: Bash(git add:*)

If omitted: All tools available </yaml_frontmatter>

Command file: .claude/commands/fix-issue.md

---
description: Fix issue following coding standards
---

Fix issue #$ARGUMENTS following our coding standards

Usage: /fix-issue 123 high-priority

Claude receives: "Fix issue #123 high-priority following our coding standards" </all_arguments_string>

<positional_arguments_syntax>

Command file: .claude/commands/review-pr.md

---
description: Review PR with priority and assignee
---

Review PR #$1 with priority $2 and assign to $3

Usage: /review-pr 456 high alice

Claude receives: "Review PR #456 with priority high and assign to alice"

See references/arguments.md for advanced patterns. </positional_arguments_syntax>

<dynamic_context>

Execute bash commands before the prompt using the exclamation mark prefix directly before backticks (no space between).

Note: Examples below show a space after the exclamation mark to prevent execution during skill loading. In actual slash commands, remove the space.

Example:

---
description: Create a git commit
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
---

## Context

- Current git status: ! `git status`
- Current git diff: ! `git diff HEAD`
- Current branch: ! `git branch --show-current`
- Recent commits: ! `git log --oneline -10`

## Your task

Based on the above changes, create a single git commit.

The bash commands execute and their output is included in the expanded prompt. </dynamic_context>

<file_references>

Use @ prefix to reference specific files:

---
description: Review implementation
---

Review the implementation in @ src/utils/helpers.js

(Note: Remove the space after @ in actual usage)

Claude can access the referenced file's contents. </file_references>

<best_practices>

1. Always use XML structure

# All slash commands should have XML-structured bodies

After frontmatter, use XML tags:

<objective> - What and why (always)
<process> - How to do it (always)
<success_criteria> - Definition of done (always)
Additional tags as needed (see xml_structure section)

2. Clear descriptions

# Good
description: Analyze this code for performance issues and suggest optimizations

# Bad
description: Optimize stuff

3. Use dynamic context for state-dependent tasks

Current git status: ! `git status`
Files changed: ! `git diff --name-only`

4. Restrict tools when appropriate

# For git commands - prevent running arbitrary bash
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)

# For analysis - thinking only
allowed-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>

Usage: /optimize src/utils/helpers.js

See references/patterns.md for more examples. </common_patterns>

<reference_guides>

Arguments reference: references/arguments.md

$ARGUMENTS variable
Positional arguments ($1, $2, $3)
Parsing strategies
Examples from official docs

Patterns reference: references/patterns.md

Git workflows
Code analysis
File operations
Security reviews
Examples from official docs

Tool restrictions: references/tool-restrictions.md

Bash command patterns
Security best practices
When to restrict tools
Examples from official docs </reference_guides>

<generation_protocol>

Analyze the user's request:
- What is the command's purpose?
- Does it need user input ($ARGUMENTS)?
- Does it produce files or artifacts?
- Does it require verification or testing?
- Is it simple (single-step) or complex (multi-step)?

Create frontmatter:

---
name: command-name
description: Clear description of what it does
argument-hint: [input] # Only if arguments needed
allowed-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
- Don't over-engineer simple commands
- Don't under-specify complex commands
Save the file:
- Project: .claude/commands/command-name.md
- Personal: ~/.claude/commands/command-name.md </generation_protocol>

<success_criteria> A well-structured slash command meets these criteria:

YAML Frontmatter:

description field is clear and concise
argument-hint present if command accepts arguments
allowed-tools specified if tool restrictions needed

XML Structure:

All three required tags present: <objective>, <process>, <success_criteria>
Conditional tags used appropriately based on complexity
No raw markdown headings in body
All XML tags properly closed

Arguments Handling:

$ARGUMENTS used when command operates on user-specified data
Positional arguments ($1, $2, etc.) used when structured input needed
No $ARGUMENTS reference for self-contained commands

Functionality:

Command expands correctly when invoked
Dynamic context loads properly (bash commands, file references)
Tool restrictions prevent unauthorized operations
Command accomplishes intended purpose reliably

Quality:

Clear, actionable instructions in <process> tag
Measurable completion criteria in <success_criteria>
Appropriate level of detail (not over-engineered for simple tasks)
Examples provided when beneficial </success_criteria>

create-slash-commands