命令创建器

斜杠命令是位于 .claude/commands/（项目级）或 ~/.claude/commands/（全局级）目录中的 Markdown 文件，当被调用时会扩展为提示内容。

命令结构

---
description: /help 中显示的简要说明（必填）
argument-hint: <required> 或 [optional]（若需参数）
---

# 命令标题

[代理自主执行的指令]

创建流程

步骤 1：确定位置

1. 检查是否在 Git 仓库中：git rev-parse --is-inside-work-tree
2. 默认规则：有 Git 仓库 → .claude/commands/，无 Git 仓库 → ~/.claude/commands/
3. 若用户明确指定“全局”或“项目”，则覆盖默认路径

在继续前报告所选位置。

步骤 2：识别模式

加载 [references/patterns.md](references/patterns.md) 并提供以下选项：

提问：“哪个模式最接近你的需求？”

步骤 3：收集信息

A. 名称与用途

• “命令应叫什么名字？”（使用 kebab-case 格式：my-command）
• “它具体做什么？”（用于 description 字段）

B. 参数

• “是否需要参数？是必需还是可选？”
• 必需参数：<placeholder>，可选参数：[placeholder]

C. 工作流步骤

• “它应遵循哪些具体步骤？”
• “应使用哪些工具或命令？”

D. 限制条件

• “是否有必须使用或避免的工具？”
• “是否有需要读取以获取上下文的文件？”

步骤 4：生成命令

加载 [references/best-practices.md](references/best-practices.md) 获取：

• 模板结构
• 写作风格（祈使句形式）
• 质量检查清单

核心原则：

• 使用祈使句形式：如“运行 X”，而非“你应该运行 X”
• 表述明确：如“运行 make lint”，而非“检查错误”
• 包含预期结果
• 定义错误处理机制
• 明确成功标准

步骤 5：创建文件

mkdir -p [directory-path]

编写命令文件。报告以下内容：

• 文件路径
• 该命令的功能
• 使用方式：/command-name [args]

步骤 6：测试（可选）

建议：“使用 /command-name [args] 进行测试”

根据反馈进行迭代优化。

编写指南

使用祈使句（动词开头）：

• ✅ “运行 git status”
• ❌ “你应该运行 git status”

具体明确，避免模糊：

• ✅ “运行 make lint 以检查错误”
• ❌ “检查错误”

包含预期结果：

• ✅ “运行 git status —— 应显示已修改的文件”
• ❌ “运行 git status”

使用真实示例：

• ✅ git commit -m "添加 OAuth2 认证"
• ❌ git commit -m "foo bar"

命令模式速查表

工作流自动化

1. 检查是否存在 .PLAN.md
2. 分析 git status/diff
3. 执行相应操作
4. 报告结果

迭代修复

1. 运行 make all-ci（最多 10 次迭代）
2. 按类别解析错误
3. 应用针对性修复
4. 重复直到成功或卡住

代理委派

1. 提供上下文信息
2. 使用 Task 工具调用子代理
3. 根据用户反馈迭代
4. 经确认后保存输出

更多完整示例请参见 [references/examples.md](references/examples.md)。

质量检查清单

在最终定稿前确认：

• [ ] 命令名称为 kebab-case 格式（如 my-command，而非 my_command）
• [ ] description 为行动导向描述
• [ ] 步骤编号清晰且具体
• [ ] 工具使用明确指出
• [ ] 错误处理机制已定义
• [ ] 成功标准已说明
• [ ] 使用祈使句形式

绝对禁止

• 在命令名称中使用下划线（应使用连字符）
• 编写模糊指令（如“修复错误”）
• 忽略错误处理
• 使用第二人称（如“你应该…”）
• 在未测试的情况下创建命令
• 不明确说明成功标准