create-slash-commands

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

<quick_start>

1. 创建 `.claude/commands/` 目录（项目级），或使用 `~/.claude/commands/`（个人级） 2. 创建 `command-name.md` 文件 3. 添加 YAML frontmatter（至少包含：`description`） 4. 编写命令提示词 5. 使用 `/command-name [args]` 测试 **文件**：`.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:

用法：/optimize

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

<xml_structure> 所有生成的斜杠命令都应在正文（YAML frontmatter 之后）使用 XML 标签，以确保清晰一致。

<required_tags>

<objective> - 命令的作用及其重要性

<objective>
What needs to happen and why this matters.
Context about who uses this and what it accomplishes.
</objective>

<process> 或 <steps> - 如何执行命令

<process>
Sequential steps to accomplish the objective:
1. First step
2. Second step
3. Final step
</process>

<success_criteria> - 如何判断命令是否成功

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

</required_tags>

<conditional_tags>

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

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

（注意：实际使用时，移除 @ 后面的空格）

<verification> - 生成需要检查的产物时使用

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

<testing> - 工作流包含运行测试时使用

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

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

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

简单命令（单项操作，不生成产物）：

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

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

• 必需：<objective>、<process>、<success_criteria>
• 添加：<context>（如果加载状态）、<verification>（如果创建文件）、<output>（说明会创建什么）
• 示例：/commit、/create-prompt、/run-prompt

带动态参数的命令：

• 在 <objective> 或 <process> 标签中使用 $ARGUMENTS
• 在 frontmatter 中包含 argument-hint
• 明确说明参数的用途

会生成文件的命令：

• 始终包含 <output> 标签，说明会创建什么
• 始终包含 <verification> 标签，列出要执行的检查

会运行测试或构建的命令：

• 包含 <testing> 标签，列出具体命令
• 在 <success_criteria> 中包含通过/失败标准 </intelligence_rules> </xml_structure>

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

<commands_that_need_arguments>

用户提供具体输入：

• /fix-issue [issue-number] - 需要 issue 编号
• /review-pr [pr-number] - 需要 PR 编号
• /optimize [file-path] - 需要指定要优化的文件
• /commit [type] - 需要提交类型（可选）

**模式：**任务针对用户指定的数据执行

在 frontmatter 中包含 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> 标签中：

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

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

在 <process> 标签中：

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

在 <context> 标签中：

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

（注意：实际使用时，移除感叹号后面的空格） </incorporating_arguments>

<positional_arguments>

对于结构化输入，请使用 $1、$2、$3：

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

<objective>
Review PR #$1 with priority $2 and assign to $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>

**必填** - 描述命令的功能

description: Analyze this code for performance issues and suggest optimizations

显示在 /help 命令列表中。

**可选** - 限制 Claude 可使用的工具

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

如果省略：所有工具均可用 </yaml_frontmatter>

命令文件：.claude/commands/fix-issue.md

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

Fix issue #$ARGUMENTS following our coding standards

用法：/fix-issue 123 high-priority

Claude 收到的内容：“按照我们的编码规范修复问题 #123 high-priority” </all_arguments_string>

<positional_arguments_syntax>

命令文件：.claude/commands/review-pr.md

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

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

用法：/review-pr 456 high alice

Claude 收到的内容：“审查 PR #456，优先级为 high，并分配给 alice”

有关高级模式，请参阅 references/arguments.md。 </positional_arguments_syntax>

<dynamic_context>

在提示词之前执行 Bash 命令：在反引号前直接添加感叹号前缀（中间不要有空格）。

注意： 为防止技能加载期间执行，下方示例在感叹号后添加了一个空格。在实际斜杠命令中，请移除该空格。

示例：

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

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

<file_references>

使用 @ 前缀引用特定文件：

---
description: Review implementation
---

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

（注意：实际使用时，请移除 @ 后的空格）

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

<best_practices>

1. 始终使用 XML 结构

# All slash commands should have XML-structured bodies

在 frontmatter 后使用 XML 标签：

• <objective> - 做什么以及为什么（始终包含）
• <process> - 如何执行（始终包含）
• <success_criteria> - 完成的定义（始终包含）
• 根据需要添加其他标签（参见 xml_structure 部分）

2. 清晰的描述

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

# Bad
description: Optimize stuff

3. 对依赖状态的任务使用动态上下文

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

4. 适当限制工具

# 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. 使用 $ARGUMENTS 提高灵活性

Find and fix issue #$ARGUMENTS

6. 引用相关文件

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

（注意：实际使用时，请移除 @ 后的空格） </best_practices>

<common_patterns>

简单分析命令：

---
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 工作流：

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

参数化命令：

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

针对特定文件的命令：

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

1. 分析用户的请求：

   • 命令的用途是什么？
   • 是否需要用户输入（$ARGUMENTS）？
   • 是否会生成文件或其他产物？
   • 是否需要验证或测试？
   • 是简单（单步）还是复杂（多步）？

2. 创建 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
   ---
   

3. 创建 XML 结构化正文：

   始终包含：

   • <objective> - 做什么以及为什么
   • <process> - 如何执行（编号步骤）
   • <success_criteria> - 完成的定义 在相关情况下包含：
   • <context> - 动态状态（！commands）或文件引用（@ 文件）
   • <verification> - 创建工件时要执行的检查
   • <testing> - 工作流包含测试时使用的测试命令
   • <output> - 创建/修改的文件

4. 正确整合 $ARGUMENTS：

   • 如果需要用户输入：添加 argument-hint，并在标签中使用 $ARGUMENTS
   • 如果命令可独立运行：省略 argument-hint 和 $ARGUMENTS

5. 灵活处理：

   • 简单命令：保持简洁（目标 + 流程 + 成功标准）
   • 复杂命令：按需添加上下文、验证和测试
   • 不要为简单命令过度设计
   • 不要对复杂命令说明不足

6. 保存文件：

   • 项目：.claude/commands/command-name.md
   • 个人：~/.claude/commands/command-name.md </generation_protocol>

<success_criteria> 结构良好的斜杠命令应符合以下标准：

YAML Frontmatter：

• description 字段清晰简洁
• 命令接受参数时提供 argument-hint
• 需要限制工具时指定 allowed-tools

XML 结构：

• 包含全部三个必需标签：<objective>、<process>、<success_criteria>
• 根据复杂度适当使用条件标签
• 正文中不使用原始 Markdown 标题
• 所有 XML 标签均正确闭合

参数处理：

• 命令处理用户指定的数据时使用 $ARGUMENTS
• 需要结构化输入时使用位置参数（$1、$2 等）
• 对于可独立运行的命令，不引用 $ARGUMENTS

功能性：

• 调用时命令可正确展开
• 动态上下文可正确加载（bash 命令、文件引用）
• 工具限制可防止未经授权的操作
• 命令能够可靠地完成预期任务

质量：

• <process> 标签中的说明清晰且可执行
• <success_criteria> 中的完成标准可衡量
• 细节程度适当（简单任务不过度设计）
• 在有帮助时提供示例 </success_criteria>