Command Creator
Slash commands are markdown files in .claude/commands/ (project) or ~/.claude/commands/ (global) that expand into prompts when invoked.
Command Structure
CODEBLOCK0
Creation Workflow
Step 1: Determine Location
- 1. Check if in git repo: INLINECODE2
- Default: Git repo →
.claude/commands/, No git → INLINECODE4 - Override if user explicitly says "global" or "project"
Report chosen location before proceeding.
Step 2: Identify Pattern
Load references/patterns.md and present options:
| Pattern | Structure | Use When |
|---|
| Workflow Automation | Analyze → Act → Report | Multi-step with clear sequence |
| Iterative Fixing |
Run → Parse → Fix → Repeat | Fix issues until passing |
| Agent Delegation | Context → Delegate → Iterate | Complex tasks, user review |
| Simple Execution | Parse → Execute → Return | Wrapper for existing tools |
Ask: "Which pattern is closest to what you want?"
Step 3: Gather Information
A. Name and Purpose
- - "What should the command be called?" (kebab-case:
my-command) - "What does it do?" (for description field)
B. Arguments
- - "Does it take arguments? Required or optional?"
- Required:
<placeholder>, Optional: INLINECODE7
C. Workflow Steps
- - "What specific steps should it follow?"
- "What tools or commands should it use?"
D. Constraints
- - "Any specific tools to use or avoid?"
- "Any files to read for context?"
Step 4: Generate Command
Load references/best-practices.md for:
- - Template structure
- Writing style (imperative form)
- Quality checklist
Key principles:
- - Use imperative form: "Run X", not "You should run X"
- Be explicit: "Run
make lint", not "Check for errors" - Include expected outcomes
- Define error handling
- State success criteria
Step 5: Create File
CODEBLOCK1
Write the command file. Report:
- - File location
- What the command does
- How to use: INLINECODE9
Step 6: Test (Optional)
Suggest: "Test with /command-name [args]"
Iterate based on feedback.
Writing Guidelines
Imperative form (verb-first):
- - ✅ "Run git status"
- ❌ "You should run git status"
Specific, not vague:
- - ✅ "Run
make lint to check for errors" - ❌ "Check for errors"
Include outcomes:
- - ✅ "Run
git status - should show modified files" - ❌ "Run git status"
Realistic examples:
- - ✅ INLINECODE13
- ❌ INLINECODE14
Command Patterns Quick Reference
Workflow Automation
CODEBLOCK2
Iterative Fixing
CODEBLOCK3
Agent Delegation
CODEBLOCK4
See references/examples.md for full command examples.
Quality Checklist
Before finalizing:
- - [ ] Name is kebab-case (
my-command, not my_command) - [ ] Description is action-oriented
- [ ] Steps are numbered and specific
- [ ] Tool usage explicitly specified
- [ ] Error handling defined
- [ ] Success criteria stated
- [ ] Uses imperative form
NEVER
- - Use underscores in command names (use hyphens)
- Write vague instructions ("fix errors")
- Skip error handling
- Use second person ("You should...")
- Create commands without testing
- Leave success criteria undefined
命令创建器
斜杠命令是位于.claude/commands/(项目级)或~/.claude/commands/(全局级)中的Markdown文件,调用时会展开为提示词。
命令结构
markdown
description: 用于/help的简要描述(必填)
argument-hint: <必填> 或 [可选](如果接受参数)
命令标题
[供代理自主执行的指令]
创建工作流程
第一步:确定位置
- 1. 检查是否在git仓库中:git rev-parse --is-inside-work-tree
- 默认规则:Git仓库 → .claude/commands/,非Git仓库 → ~/.claude/commands/
- 如果用户明确指定全局或项目,则覆盖默认规则
在继续之前报告所选位置。
第二步:识别模式
加载references/patterns.md并呈现选项:
| 模式 | 结构 | 适用场景 |
|---|
| 工作流自动化 | 分析 → 执行 → 报告 | 具有清晰顺序的多步骤流程 |
| 迭代修复 |
运行 → 解析 → 修复 → 重复 | 修复问题直至通过 |
| 代理委派 | 上下文 → 委派 → 迭代 | 复杂任务,用户审查 |
| 简单执行 | 解析 → 执行 → 返回 | 现有工具的封装 |
询问:哪种模式最接近您的需求?
第三步:收集信息
A. 名称和用途
- - 命令应该叫什么?(短横线命名法:my-command)
- 它做什么?(用于描述字段)
B. 参数
- - 它接受参数吗?必填还是可选?
- 必填:<占位符>,可选:[占位符]
C. 工作流步骤
- - 它应该遵循哪些具体步骤?
- 它应该使用哪些工具或命令?
D. 约束条件
- - 是否有特定工具要使用或避免?
- 是否有文件需要读取以获取上下文?
第四步:生成命令
加载references/best-practices.md以获取:
关键原则:
- - 使用祈使句形式:运行X,而不是你应该运行X
- 明确具体:运行make lint,而不是检查错误
- 包含预期结果
- 定义错误处理
- 说明成功标准
第五步:创建文件
bash
mkdir -p [目录路径]
写入命令文件。报告:
- - 文件位置
- 命令功能
- 使用方法:/command-name [参数]
第六步:测试(可选)
建议:使用/command-name [参数]进行测试
根据反馈进行迭代。
编写指南
祈使句形式(动词优先):
- - ✅ 运行git status
- ❌ 你应该运行git status
具体而非模糊:
- - ✅ 运行make lint检查错误
- ❌ 检查错误
包含结果:
- - ✅ 运行git status - 应显示修改过的文件
- ❌ 运行git status
真实示例:
- - ✅ git commit -m 添加OAuth2认证
- ❌ git commit -m foo bar
命令模式快速参考
工作流自动化
markdown
- 1. 检查.PLAN.md文件
- 分析git状态/差异
- 执行操作
- 报告结果
迭代修复
markdown
- 1. 运行make all-ci(最多10次迭代)
- 按类别解析错误
- 应用针对性修复
- 重复直到成功或卡住
代理委派
markdown
- 1. 呈现上下文
- 使用任务工具调用子代理
- 根据用户反馈迭代
- 批准后保存输出
完整命令示例请参见references/examples.md。
质量检查清单
最终确定前:
- - [ ] 名称为短横线命名法(my-command,而非my_command)
- [ ] 描述以行动为导向
- [ ] 步骤编号且具体
- [ ] 明确指定工具使用
- [ ] 定义了错误处理
- [ ] 说明了成功标准
- [ ] 使用祈使句形式
禁止事项
- - 在命令名称中使用下划线(使用连字符)
- 编写模糊的指令(修复错误)
- 跳过错误处理
- 使用第二人称(你应该...)
- 未经测试创建命令
- 未定义成功标准