command-creator

command-creator 技能概览

command-creator 适合这样的人：你已经在 Claude Code 里反复执行某套流程，希望把它沉淀成一个可复用的 slash command，而不是每次都重新解释步骤。它的作用不只是帮你起草一个 markdown 文件；更重要的是，它会帮助你选对命令模式，用 agent 可执行的方式编写指令，并把命令放到适合项目级复用或用户级复用的正确位置。

哪些人最适合使用 command-creator

command-creator 最适合开发者、团队负责人，以及使用 Skill Authoring 的用户。前提是你已经有一套会重复执行的流程，比如修 CI、提交 PR、做实现规划，或者执行代码评审例行流程，并且希望把这套流程变成可以直接通过 /command-name 调用的命令。

它真正解决的是什么问题

大多数用户真正需要的并不是“一个命令文件”，而是一个能让另一个 agent 在更少歧义、更少追问、输出更稳定的前提下执行的命令。command-creator skill 的价值就在于，它关注的是命令结构、执行清晰度和可复用的工作流设计，而不是停留在模糊的 prompt 写作层面。

它和普通 prompt 有什么不同

普通 prompt 也许能很快生成一个粗略的 slash command，但 command-creator 提供的是更高价值的指导，包括：

• 选择合适的工作流模式
• 编写祈使式、对工具友好的指令
• 定义参数和预期输出
• 判断命令应该放在 .claude/commands/ 还是 ~/.claude/commands/
• 避免那些会削弱自主执行效果的常见命令编写错误

什么情况下 command-creator 特别适合

如果你经常会说下面这类话，就很适合用 command-creator：

• “这个任务我总在做，帮我做成一个 slash command。”
• “把这个流程变成 /something。”
• “把这套多步骤流程写清楚，让 Claude Code 能稳定执行。”
• “给这个仓库做一个项目专用命令。”
• “做一个我能跨项目复用的全局命令。”

哪些情况下它不是对的工具

如果你只需要一次性的回答、一个不打算复用的普通 prompt，或者你要做的自动化更依赖外部脚本而不是 markdown 命令定义，那就不必用 command-creator。它最擅长的场景，是把一套流程清晰表达为可重复执行的分析、操作和汇报序列。

如何使用 command-creator 技能

command-creator 的安装上下文

该仓库是 softaworks/agent-toolkit，这个技能位于 skills/command-creator。如果你是从这个 toolkit 安装技能，常见方式是：

npx skills add softaworks/agent-toolkit --skill command-creator

如果你的环境使用的是其他 skill loader，请以上面的仓库路径作为准确信息来源。

command-creator 会帮你产出什么

最终产物是一个 Claude Code 的 slash command：一个 markdown 文件，存放在以下两个位置之一：

• .claude/commands/：用于项目专属命令
• ~/.claude/commands/：用于全局命令

之后你可以在 Claude Code 里通过 /command-name 来调用这个文件。

使用 command-creator 之前，先读这些文件

如果你想以最快速度拿到更好的结果，建议按这个顺序阅读仓库内容：

1. SKILL.md：了解触发方式和技能边界
2. references/patterns.md：选择合适的命令形态
3. references/best-practices.md：学习写法和结构规范
4. references/examples.md：查看已经验证可用的完整命令示例
5. README.md：如果你需要更完整的整体说明，再读它

这个阅读顺序很重要，因为大多数采用障碍并不是安装问题，而是设计问题，比如选错模式，或者指令写得太含糊。

从工作流出发，而不是先想命令名

最佳的 command-creator usage，起点应该是一项重复出现的任务，而不是先做命名包装。在调用这个技能前，先把下面这些内容写出来：

• 触发条件：什么问题会启动这套流程
• 输入：需要哪些参数、文件或仓库状态
• 顺序：步骤应该如何依次执行
• 停止条件：什么才算成功
• 汇报内容：命令结束后应该告诉用户什么

这样一来，技能才有足够的信息去匹配合适的命令模式，而不是凭空松散地拼一个出来。

把模糊需求改写成高质量输入

较弱的输入：

• “帮我做个 PR 用的 slash command。”

更强的输入：

• “Create a Claude Code slash command named submit-stack for this repo. It should check for .PLAN.md first, fall back to git diff if absent, generate a concise commit message, run Graphite restack and submit commands, then report PR URLs. This should be project-level, live in .claude/commands/, and accept an optional description argument.”

之所以后者效果更好，是因为它明确了上下文检查、回退逻辑、工具动作、目标位置和参数要求。

尽早选定正确的命令模式

这些参考文档已经说明，先选模式再起草，命令质量通常会明显提升。常见模式包括：

• Analyze → Act → Report：适合多步骤工作流自动化
• Run → Parse → Fix → Repeat：适合 CI、lint 这类迭代修复任务
• 面向委派的流程：适合把任务路由给专门 agent 的命令
• 更简单的执行模式：适合分支少、步骤直接的任务

如果你的命令在实际使用中总是执行不稳，问题往往不在措辞，而在于模式不匹配。

用 agent 可执行的方式写指令

references/best-practices.md 里有一个非常关键的结论：命令应该使用祈使式、具体可执行的指令，而不是对“你”提出建议。

更推荐：

• “Run git status to inspect modified files.”
• “Check whether .PLAN.md exists in the repository root.”
• “Report PR URLs after submission.”

尽量避免：

• “You should inspect the repo.”
• “You may want to look at git status.”
• “Try to submit the PRs.”

这是 command-creator guide 里影响最大的细节之一，因为它会直接影响生成出来的命令能否真正自主执行。

写清预期结果和决策分支

好的命令不只是罗列步骤，还要说明“应该发生什么”以及“遇到情况时如何分支处理”。

建议补充的信息包括：

• 首先要检查哪个文件
• 如果该文件不存在，下一步应该怎么做
• 什么样的输出算成功
• 什么时候应该停止并询问用户
• 最后要向用户回报什么

这样能减少执行过程中的猜测，也让命令更容易跨对话复用。

判断应该放项目级还是全局级

对于 command-creator for Skill Authoring 来说，命令放置位置是很实际的设计决策：

• 当流程依赖仓库约定、仓库工具或项目文件时，用 .claude/commands/
• 当流程是你个人在多个仓库里都能复用的，用 ~/.claude/commands/

通常来说，项目专属命令是更稳妥的默认选择，因为大多数真正有价值的流程都依赖本地约定。

参数要围绕真实变化来设计

只有当参数确实会显著改变执行逻辑时，才应该加参数。比较合适的参数包括：

• 用户提供的说明文字
• 目标文件或路径
• 类似 quick 和 full 这样的模式
• 环境或作用范围选择器

不要只是因为“命令应该更灵活”就堆参数。可选参数太多，反而会让命令更不稳定，也更难被 agent 正确理解。

首次使用的实操流程

一个实用的 command-creator install 与使用路径通常是这样的：

1. 从 softaworks/agent-toolkit 安装或加载该技能
2. 阅读 SKILL.md 和 references/patterns.md
3. 只选一条重复工作流作为目标
4. 用输入、分支和预期输出描述这条流程
5. 让 command-creator 起草 slash command
6. 对照 references/best-practices.md 检查草稿
7. 在 Claude Code 里用真实场景测试该命令
8. 收紧任何模糊步骤、缺失前置条件或汇报不足的部分

仓库里最值得关注的信号

这里最有价值的是参考资料，而不是辅助脚本。这个技能附带了模式、示例和最佳实践文档，这一点很有帮助，因为命令编写失败，更多是因为设计不清晰，而不是因为缺代码。也正因如此，这个技能尤其适合那些要设计可复用 markdown 命令，而不是重度依赖工具自动化的人。

command-creator 技能常见问题

如果我本来就会写 prompt，还有必要用 command-creator 吗？

有必要，前提是你的目标是可复用的命令编写，而不是一次性的 prompt。command-creator 能为 slash command 提供结构化支持，尤其是在命令模式、祈使式写法和预期输出这些方面。相比临时拼出来的 prompt，它通常更容易产出一个能被另一个 agent 稳定执行的命令。

command-creator 对新手友好吗？

大体上是友好的，前提是你已经理解自己要自动化的那套流程。你不需要一开始就熟悉所有 slash command 约定，但如果你能清楚描述任务、输入和成功标准，结果会好很多。

command-creator 不会帮我做什么？

它不会凭一句模糊描述，就自动推断出一套混乱流程里的所有隐含逻辑。如果你的流程里存在隐藏前提、工具名称缺失，或者停止条件不清晰，生成出来的命令也会继承这些问题。

它和直接抄一个示例命令有什么区别？

示例当然有帮助，但当你的流程需要适配时，command-creator usage 会更强。仓库自带的示例展示了可用模式，而这个技能的价值在于帮助你把自己的具体流程映射到这些模式上，而不是盲目复制某个例子后赌它刚好适用。

简单任务也应该用 command-creator 吗？

只有当这个任务重复得足够频繁，值得为它做一个 slash command 时才建议用。对于一次性的小动作，直接 prompt 更快；但对于团队内或仓库内反复出现的流程，command-creator skill 的价值就会明显提升。

command-creator 能帮助我写项目专用命令吗？

可以，而且这正是它最擅长的场景之一。对于那些依赖仓库文件、本地约定，或者固定检查与执行顺序的命令，这个技能非常合适。

什么情况下我不该优先安装 command-creator？

如果你真正需要的是外部自动化代码、shell 脚本，或者 CI 配置，而不是 Claude Code 的 slash command，那么就不应该优先考虑 command-creator install。这个技能的重点是命令定义编写，而不是替代所有其他自动化层。

如何改进 command-creator 技能的使用效果

给 command-creator 更好的源材料

提升 command-creator 输出质量最快的方法，就是把工作流按结构提供出来：

• 目标
• 触发条件
• 所需工具
• 文件检查点
• 分支逻辑
• 最终交付物

哪怕只是一个简短的要点列表，也比“帮我做个 release 命令”这种模糊一句话强得多。

提供仓库专属上下文

如果这是一个项目级命令，请把仓库细节一起告诉它，例如：

• 命令应该优先读取的重要文件
• 像 make test 或 pnpm lint 这样的标准命令
• 命名约定
• commit 或 PR 规范
• Graphite、pytest 或自定义脚本等工具

这样技能产出的命令会更贴合这个仓库，而不是沦为一个通用模板。

提前说明常见失败模式

直接告诉 command-creator 哪些地方最容易出问题：

• 上下文文件缺失
• working tree 不干净
• 测试不稳定
• 工具只返回部分输出
• 哪些情况下命令应该停止而不是继续

这会让它生成出更好的分支逻辑，也能让指令更安全。

明确要求前置条件和输出

一个常见失败模式是：命令写了“做什么”，却没写“怎样才算做成”。你可以要求技能明确包含：

• preflight checks
• 每个主要步骤之后的预期输出
• 最终汇报格式
• 当流程无法安全继续时的升级/中止点

这样通常能让命令第一次生成时就更接近可执行状态。

第一版出来后，继续收紧模糊语言

如果第一版结果里频繁出现 “check”“review”“fix” 这类宽泛词，但没有足够细节，就把它们改写成具体动作：

• 应该运行什么命令
• 应该读取哪个文件
• 应该验证什么条件
• 应该返回什么输出

这是改进 command-creator for Skill Authoring 的最佳方法之一，因为 slash command 表现不佳，最常见原因就是歧义太多。

有策略地复用自带参考资料

每份参考资料适合用于不同的改进轮次：

• references/patterns.md：修正整体结构
• references/examples.md：把你的命令和真实可用示例对比
• references/best-practices.md：收紧措辞和执行细节

这种做法比反复重读 SKILL.md 更有效。

用真实调用测试，而不只是静态通读

一个命令在 markdown 里看起来不错，不代表实际执行就没问题。要用真实的 /command-name 场景、真实参数和真实仓库状态去测试。然后重点修正：

• 不清晰的隐含前提
• 缺失的文件检查
• 不够稳妥的回退逻辑
• 不理想的汇报方式
• 没必要的可选项

先优化命令范围，再增加复杂度

如果你的第一个命令显得很脆弱，优先缩小范围，而不是继续叠功能。一个只处理单一清晰流程的小命令，往往比一个试图覆盖大量边界情况的“聪明命令”更可靠。等基础路径稳定后，再有意识地增加参数或分支。

把 command-creator 当作设计辅助，而不是最终裁决者

想提高 command-creator skill 的结果质量，最佳做法是把第一版草稿视为一个设计产物。先检查它是否真的符合你的工作方式，再根据你的仓库、工具和约束继续修改。这个技能最强的地方，是帮你减少设计猜测，而不是替你做最终判断。