create-slash-commands

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<objective> 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. </objective>

<quick_start>

<workflow> 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]` </workflow> <example> **File**: `.claude/commands/optimize.md`

markdown

---
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. </example> </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

markdown

<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

markdown

<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

markdown

<success_criteria>
Clear, measurable criteria for successful completion.
</success_criteria>

</required_tags>

<conditional_tags>

<context>
- When loading dynamic state or files

markdown

<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

markdown

<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

markdown

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

<output>
- When creating/modifying specific files

markdown

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

</conditional_tags>

<structure_example>

markdown

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

markdown

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

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

In
<process>
tag:

markdown

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

In
<context>
tag:

markdown

<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

markdown

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

<field name="description"> **Required** - Describes what the command does

yaml

description: Analyze this code for performance issues and suggest optimizations

Shown in the

/help

command list. </field>

<field name="allowed-tools"> **Optional** - Restricts which tools Claude can use

yaml

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 </field> </yaml_frontmatter>

Command file:

.claude/commands/fix-issue.md

markdown

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

markdown

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

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

markdown

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

<objective> 为Claude Code创建高效的斜杠命令，让用户能够通过`/command-name`语法触发可复用的提示词。斜杠命令会在当前对话中展开为提示词，帮助团队标准化工作流程与操作。本技能将教你如何使用XML标签、YAML前置元数据、动态上下文加载以及智能参数处理来构建命令。 </objective>

<quick_start>

<workflow> 1. 创建`.claude/commands/`目录（项目级）或使用`~/.claude/commands/`目录（个人级） 2. 创建`command-name.md`文件 3. 添加YAML前置元数据（至少包含`description`字段） 4. 编写命令提示词 5. 使用`/command-name [args]`进行测试 </workflow> <example> **文件**: `.claude/commands/optimize.md`

markdown

---
description: Analyze this code for performance issues and suggest optimizations
---

Analyze the performance of this code and suggest three specific optimizations:

用法:

/optimize

Claude会接收展开后的提示词，并结合上下文分析代码。 </example> </quick_start>

<xml_structure> 所有生成的斜杠命令在正文部分（YAML前置元数据之后）都应使用XML标签，以保证清晰性和一致性。

<required_tags>

<objective>
- 命令的功能及重要性

markdown

<objective>
需要完成的任务及其重要性。
关于目标用户和达成效果的上下文信息。
</objective>

<process>
或
<steps>
- 命令的执行方式

markdown

<process>
完成目标的步骤：
1. 第一步
2. 第二步
3. 最终步骤
</process>

<success_criteria>
- 命令成功的判定标准

markdown

<success_criteria>
清晰、可衡量的完成标准。
</success_criteria>

</required_tags>

<conditional_tags>

<context>
- 加载动态状态或文件时使用

markdown

<context>
当前状态: ! `git status`
相关文件: @ package.json
</context>

（注意：实际使用时需去掉@后的空格）

<verification>
- 生成需要校验的产物时使用

markdown

<verification>
完成前需验证：
- 需执行的特定测试或检查
- 如何确认功能正常
</verification>

<testing>
- 工作流程包含测试环节时使用

markdown

<testing>
运行测试: ! `npm test`
检查代码规范: ! `npm run lint`
</testing>

<output>
- 创建或修改文件时使用

markdown

<output>
创建/修改的文件:
- `./path/to/file.ext` - 描述
</output>

</conditional_tags>

<structure_example>

markdown

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

<objective>
处理$ARGUMENTS以达成[目标]。
这将帮助[用户群体]实现[成果]。
</objective>

<context>
当前状态: ! `relevant command`
文件: @ relevant/files
</context>

<process>
1. 解析$ARGUMENTS
2. 执行操作
3. 验证结果
</process>

<success_criteria>
- 操作无错误完成
- 输出符合预期格式
</success_criteria>

</structure_example>

<intelligence_rules>

简单命令（单一操作，无产物）:

必填：
```
<objective>
```
、
```
<process>
```
、
```
<success_criteria>
```
示例：
```
/check-todos
```
、
```
/first-principles
```

复杂命令（多步骤，生成产物）:

必填：
```
<objective>
```
、
```
<process>
```
、
```
<success_criteria>
```
可选添加：
```
<context>
```
（加载状态时）、
```
<verification>
```
（创建文件时）、
```
<output>
```
（指定生成内容）
示例：
```
/commit
```
、
```
/create-prompt
```
、
```
/run-prompt
```

带动态参数的命令:

在
```
<objective>
```
或
```
<process>
```
标签中引用
```
$ARGUMENTS
```
在前置元数据中添加
```
argument-hint
```
明确说明参数用途

生成文件的命令:

必须包含
```
<output>
```
标签指定生成的文件
必须包含
```
<verification>
```
标签说明校验方式

运行测试/构建的命令:

包含
```
<testing>
```
标签指定具体命令
在
```
<success_criteria>
```
中定义通过/失败标准 </intelligence_rules> </xml_structure>

<arguments_intelligence> 本技能可智能判断斜杠命令是否需要参数。

<commands_that_need_arguments>

用户需提供特定输入的场景:

```
/fix-issue [issue-number]
```
- 需要问题编号
```
/review-pr [pr-number]
```
- 需要PR编号
```
/optimize [file-path]
```
- 需要待优化文件路径
```
/commit [type]
```
- 需要提交类型（可选）

模式: 任务需对用户指定的数据进行操作

在前置元数据中添加

argument-hint: [description]

，并在正文中引用

$ARGUMENTS

。 </commands_that_need_arguments>

<commands_without_arguments>

自包含流程:

```
/check-todos
```
- 对已知文件（TO-DOS.md）进行操作
```
/first-principles
```
- 基于当前对话内容操作
```
/whats-next
```
- 分析当前上下文

模式: 任务基于隐式上下文（当前对话、已知文件、项目状态）操作

无需添加

argument-hint

或引用

$ARGUMENTS

。 </commands_without_arguments>

<incorporating_arguments>

在
<objective>
标签中使用:

markdown

<objective>
按照项目规范修复编号为$ARGUMENTS的问题。
这确保系统地解决Bug并完成适当测试。
</objective>

在
<process>
标签中使用:

markdown

<process>
1. 从问题跟踪系统了解编号为$ARGUMENTS的问题
2. 定位相关代码
3. 实现修复方案
4. 添加测试
</process>

在
<context>
标签中使用:

markdown

<context>
问题详情: @ issues/$ARGUMENTS.md
相关文件: ! `grep -r "TODO.*$ARGUMENTS" src/`
</context>

（注意：实际使用时需去掉!后的空格） </incorporating_arguments>

<positional_arguments>

对于结构化输入，使用

$1

、

$2

、

$3

markdown

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

<objective>
审核编号为$1的PR，优先级为$2，并分配给$3。
</objective>

用法:

/review-pr 456 high alice

</positional_arguments> </arguments_intelligence>

<file_structure>

项目级命令:

.claude/commands/

通过版本控制与团队共享
在
```
/help
```
列表中显示
```
(project)
```
标识

个人级命令:

~/.claude/commands/

可在所有项目中使用
在
```
/help
```
列表中显示
```
(user)
```
标识

文件命名:

command-name.md

→ 调用方式为

/command-name

</file_structure>

<yaml_frontmatter>

<field name="description"> **必填** - 描述命令功能

yaml

description: Analyze this code for performance issues and suggest optimizations

会在

/help

命令列表中展示。 </field>

<field name="allowed-tools"> **可选** - 限制Claude可使用的工具

yaml

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

格式:

数组形式:
```
allowed-tools: [Read, Edit, Write]
```
单一工具:
```
allowed-tools: SequentialThinking
```
Bash命令限制:
```
allowed-tools: Bash(git add:*)
```

若省略此字段：可使用所有工具 </field> </yaml_frontmatter>

命令文件:

.claude/commands/fix-issue.md

markdown

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

Fix issue #$ARGUMENTS following our coding standards

用法:

/fix-issue 123 high-priority

Claude接收内容: "Fix issue #123 high-priority following our coding standards" </all_arguments_string>

<positional_arguments_syntax>

命令文件:

.claude/commands/review-pr.md

markdown

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

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

用法:

/review-pr 456 high alice

Claude接收内容: "Review PR #456 with priority high and assign to alice"

高级模式请参考references/arguments.md。 </positional_arguments_syntax> </arguments>

<dynamic_context>

在提示词前使用感叹号前缀直接跟反引号（无空格）来执行bash命令。

注意: 以下示例中感叹号后有空格，是为了避免在技能加载时执行命令。实际斜杠命令中需去掉该空格。

示例:

markdown

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

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:

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

yaml

undefined

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


bash命令会被执行，其输出将包含在展开后的提示词中。
</dynamic_context>

<file_references>

使用`@`前缀引用特定文件:

```markdown
---
description: Review implementation
---

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

（注意：实际使用时需去掉@后的空格）

Claude可访问被引用文件的内容。 </file_references>

<best_practices>

1. 始终使用XML结构

yaml

undefined

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**
```yaml


前置元数据之后，使用XML标签:
- `<objective>` - 功能与目的（必填）
- `<process>` - 执行步骤（必填）
- `<success_criteria>` - 完成标准（必填）
- 根据需要添加其他标签（参考xml_structure章节）

**2. 清晰的描述**
```yaml

Good

description: Analyze this code for performance issues and suggest optimizations

Bad

description: Optimize stuff


**3. Use dynamic context for state-dependent tasks**
```markdown
Current git status: ! `git status`
Files changed: ! `git diff --name-only`

4. Restrict tools when appropriate

yaml

undefined

description: Optimize stuff


**3. 对依赖状态的任务使用动态上下文**
```markdown
Current git status: ! `git status`
Files changed: ! `git diff --name-only`

4. 适当限制工具权限

yaml

undefined

For git commands - prevent running arbitrary bash

针对git命令 - 防止执行任意bash命令

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

For analysis - thinking only

针对分析任务 - 仅允许思考

allowed-tools: SequentialThinking


**5. Use $ARGUMENTS for flexibility**
```markdown
Find and fix issue #$ARGUMENTS

6. Reference relevant files

markdown

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:

markdown

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

markdown

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

markdown

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

markdown

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

yaml

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

allowed-tools: SequentialThinking


**5. 使用$ARGUMENTS提升灵活性**
```markdown
Find and fix issue #$ARGUMENTS

6. 引用相关文件

markdown

Review @ package.json for dependencies
Analyze @ src/database/* for schema

（注意：实际使用时需去掉@后的空格） </best_practices>

<common_patterns>

简单分析命令:

markdown

---
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工作流命令:

markdown

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

参数化命令:

markdown

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

特定文件命令:

markdown

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

用法:

/optimize src/utils/helpers.js

更多示例请参考references/patterns.md。 </common_patterns>

<reference_guides>

参数参考: references/arguments.md

$ARGUMENTS变量
位置参数($1, $2, $3)
解析策略
官方文档示例

模式参考: references/patterns.md

Git工作流
代码分析
文件操作
安全审核
官方文档示例

工具限制参考: references/tool-restrictions.md

Bash命令模式
安全最佳实践
何时限制工具
官方文档示例 </reference_guides>

<generation_protocol>

分析用户需求:
- 命令的用途是什么？
- 是否需要用户输入($ARGUMENTS)？
- 是否会生成文件或产物？
- 是否需要验证或测试？
- 是简单命令（单步骤）还是复杂命令（多步骤）？

创建前置元数据:

yaml

---
name: command-name
description: Clear description of what it does
argument-hint: [input] # Only if arguments needed
allowed-tools: [...] # Only if tool restrictions needed
---

创建XML结构的正文:

必填标签:
- ```
<objective>
```
  - 功能与目的
- ```
<process>
```
  - 执行步骤（编号列表）
- ```
<success_criteria>
```
  - 完成标准
按需添加标签:
- ```
<context>
```
  - 动态状态(!
```
commands
```
  )或文件引用(@ files)
- ```
<verification>
```
  - 生成产物时的校验步骤
- ```
<testing>
```
  - 工作流程包含测试环节时
- ```
<output>
```
  - 创建/修改的文件
正确集成$ARGUMENTS:
- 若需要用户输入：添加
```
argument-hint
```
  并在标签中引用
```
$ARGUMENTS
```
- 若为自包含命令：无需添加
```
argument-hint
```
  或引用
```
$ARGUMENTS
```
应用智能规则:
- 简单命令：保持简洁（目标+流程+成功标准）
- 复杂命令：按需添加上下文、验证、测试等标签
- 简单命令不要过度设计
- 复杂命令不要描述不足

保存文件:

项目级:
```
.claude/commands/command-name.md
```
个人级:
```
~/.claude/commands/command-name.md
```
</generation_protocol>

<success_criteria> 结构良好的斜杠命令需满足以下标准:

YAML前置元数据:

```
description
```
字段清晰简洁
若命令接受参数，需包含
```
argument-hint
```
若需限制工具，需指定
```
allowed-tools
```

XML结构:

包含三个必填标签：
```
<objective>
```
、
```
<process>
```
、
```
<success_criteria>
```
根据复杂度合理使用条件标签
正文中无原生markdown标题
所有XML标签正确闭合

参数处理:

当命令需对用户指定数据操作时，使用
```
$ARGUMENTS
```
当需要结构化输入时，使用位置参数(
```
$1
```
,
```
$2
```
等)
自包含命令不要引用
```
$ARGUMENTS
```

功能性:

命令调用时能正确展开
动态上下文能正确加载（bash命令、文件引用）
工具限制可阻止未授权操作
命令能可靠完成预期功能

质量:

```
<process>
```
标签包含清晰可执行的指令
```
<success_criteria>
```
包含可衡量的完成标准
细节程度适当（简单任务不过度设计）
必要时提供示例 </success_criteria>