命令创建器（command-creator）：把重复的开发流程，一句话变成可复用的斜杠命令
- 一句话定位：这是一个专门指导 AI 助手创建 Claude Code 斜杠命令（Slash Command）的技能，把“我每次都要重复做的那套流程”固化成
/命令名一键调用。 - 核心产出：在
.claude/commands/（项目级）或~/.claude/commands/（全局级）生成一个结构规范的 Markdown 命令文件，包含描述、参数提示与可被代理自主执行的步骤指令。 - 四种内置模式：工作流程自动化、迭代修复、代理委派、简单执行，覆盖绝大多数自动化诉求。
- 质量保障：技能自带三份参考文档（模式库、真实示例、最佳实践与检查清单），避免写出“能调用但跑不通”的命令。
- 适合谁用：频繁做代码审查、提交 PR、修复 CI、生成实施方案等重复流程的开发者与团队。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 命令创建器Skill |
| 英文名 | command-creator |
| 技能ID | 12220 |
| 类型 | 流程指导型技能（Agent Skill） |
| 主要产出 | Claude Code 斜杠命令文件（Markdown） |
它解决什么问题？
在使用 Claude Code 的日常开发中，很多操作是重复的：把当前分支的改动整理成一次干净的提交、跑完测试和类型检查后逐个修掉 CI 报错、根据实施计划文档推进任务……每次都要重新口述一遍步骤，既费时又容易漏步骤。斜杠命令正是为此设计的——但你得手写一个符合规范的 Markdown 文件，写清楚 frontmatter、参数提示、执行步骤、错误处理和成功标准，大多数人要么懒得写，要么写出来的命令代理根本执行不稳定。
命令创建器Skill 就是把“写命令”这件事本身交给 AI：你描述需求，它负责检测存放位置、推荐命令模式、追问关键信息、生成优化后的命令文件，并告诉你如何调用与迭代。
一键安装思路与步骤
- 确认前提：你已经在使用 Claude Code 或支持 Agent Skills 机制的 AI 编程客户端，并且该客户端提供技能（Skill）市场或安装入口。具体入口位置以官方说明为准。
- 检索技能：在技能市场或技能列表中，用英文名
command-creator或技能ID12220搜索，也能用中文关键词“命令创建器”“斜杠命令”定位。 - 执行安装：点击安装/启用即可，安装方式与命令细节以官方说明为准。安装后技能通常随会话自动加载，无需手动配置路径。
- 验证是否生效：新开一个会话，直接说“帮我创建一个斜杠命令”，或说“我一直在做代码审查，能把它做成命令吗”。如果助手开始询问命令名称、用途、参数等信息，说明技能已被正确触发；反之则重新检查安装状态。
- 零门槛替代路径：即便暂未安装，也可以直接把需求描述给助手，让它按“Markdown + frontmatter”的规范手写命令文件，只是缺少模式库与质量清单的加持，稳定性会差一些。
该技能的主要功能和特点
- 位置自动检测：技能会先执行
git rev-parse --is-inside-work-tree判断当前是否处于 Git 仓库中，在仓库内默认写入项目级.claude/commands/，不在仓库内则落到全局~/.claude/commands/，也支持你显式指定“全局”或“项目级”。 - 模式化引导：内置四种命令模式——工作流程自动化（分析→行动→报告）、迭代修复（运行→解析→修复→重复）、代理委派（上下文→委派→迭代）、简单执行（带参数跑一条命令）。它会主动问你“哪种模式最接近你想做的？”，帮你把模糊需求落到结构上。
- 规范化命名：强制 kebab-case 命名（如
submit-stack），文件名即命令名，my-command.md对应/my-command，避免下划线命名导致调用异常。 - 参数体系支持：通过 frontmatter 中的
argument-hint声明参数，用尖括号<placeholder>表示必填、方括号[placeholder]表示可选，提示直观。 - 代理可执行指令生成：按照“祈使句动词开头、具体明确、包含预期结果、给出具体示例、定义清晰错误处理”的原则撰写正文，而不是写一段给人看的说明书。
- 捆绑参考资料：
references/patterns.md（模式）、references/examples.md（真实命令完整源码，如 submit-stack、ensure-ci、create-implementation-plan）、references/best-practices.md（模板结构、质量检查清单、常见陷阱），按需加载，保证产出质量。 - 与通用提示词的区别：普通提示词模板只是“一段可复制的文字”，而这个技能产出的是带元数据、带参数、带工具约束、可被代理按步骤自主执行的正式命令资产，可纳入版本库随项目分发。
如何使用该技能？
步骤一：用自然语言提出需求
不需要背语法，直接用口语描述。例如：
“我每次提交 PR 前都要跑一遍测试、格式化、再整理提交信息，帮我把这个做成命令。”
步骤二：确认存放位置
技能会先判断当前目录是否为 Git 仓库，然后向你报告选定的路径（项目级 .claude/commands/ 或全局 ~/.claude/commands/）。如果你希望写到全局，只需补一句“这个要做成全局命令”。
步骤三：选择命令模式
技能会展示四种模式并询问哪一类最接近你的需求：
- 想“分析一下再动手再汇报”→ 工作流程自动化
- 想“跑到通过为止”→ 迭代修复
- 想“先规划再交给子代理干活”→ 代理委派
- 想“就是拿参数跑一条固定命令”→ 简单执行
步骤四：回答四组关键信息
| 追问项 | 你要回答的内容 | 示例 |
|---|---|---|
| 命令名称与用途 | 文件名（kebab-case）+ 一句话描述 | 名称 submit-stack，用途“整理当前栈改动并提交 PR” |
| 参数 | 是否接受参数、必填还是可选、代表什么 | 可选参数 [target-branch]，指定目标分支 |
| 工作流步骤 | 先检查什么、做什么、如何处理结果、成功标准 | “先跑测试，再格式化，最后生成提交信息” |
| 工具与限制 | 指定或禁用的工具、需要预读的上下文文件 | “用 Bash 跑 pytest，禁止直接 push” |
步骤五：拿到生成结果
技能会创建目录（mkdir -p）并写入命令文件，然后向你汇报文件位置、命令作用以及调用方式。生成的文件结构大致如下：
---
description: 在 /help 中显示的简要描述（必需）
argument-hint: <placeholder>
---
# 命令标题
[代理自主执行的详细指令]
步骤六：测试与迭代
在会话中直接输入 /命令名 参数 试跑，把不符合预期的点反馈给助手，让它修改文件即可。技能本身也建议你在测试后再定稿。
实用提示：涉及 pytest、pyright、ruff、prettier、make 等工具时使用 Bash 工具执行；需要专项处理时可委派子代理；待办事项建议完成即标记而非批量标记；命令中务必写明错误处理与成功标准。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 命令创建器Skill（command-creator） | 斜杠命令的“生成器 + 质量顾问” | 位置检测、模式推荐、信息收集、规范生成、参考资料、迭代支持 | 低：安装后在会话中用自然语言描述即可 | 想把重复流程固化为团队可复用命令 | 优势：有模式库与最佳实践兜底，产出规范、可执行性强；不足：产出的命令仍需真人试跑验证 |
| 手写 Markdown 命令文件 | 原始方式 | 自行编写 frontmatter 与正文指令 | 中：需了解目录规范、frontmatter 字段、代理执行习惯 | 极简单的单步命令 | 优势：完全可控、无依赖；不足：易漏参数声明与错误处理，命名不规范会导致调用失败，维护成本高 |
| 通用提示词模板库 | 提示词资产复用 | 提供可复制粘贴的提示词片段 | 低：复制即用 | 一次性任务、非固定流程 | 优势：上手最快；不足：没有参数机制、不能通过 /命令名 触发，也无法随项目版本化分发 |
| IDE 内置自定义指令 / 规则文件 | 编辑器级全局约束 | 用规则文件约束 AI 的编码风格与行为 | 中：需要理解规则优先级与生效范围 | 统一团队编码规范 | 优势：全局生效、覆盖所有对话；不足：偏向“约束”而非“可调用的流程”，无法按需触发某套多步骤动作 |
总的来说：如果你需要的只是“让 AI 记住某种风格”，规则文件更合适；如果你需要的是“随时能敲一个 /xxx 就跑完一整套流程”，命令创建器Skill 是更对口的路径。
该技能的典型应用场景与实际体验情况
场景一：提交 PR 前的固定动作（后端开发者）
痛点：每次提交前都要手动跑测试、格式化、检查改动范围、组织提交信息，步骤散落在脑子里，偶尔漏跑测试把问题带上主干。使用方式：描述“跑测试→格式化→整理提交信息→提 PR”的流程，选择“工作流程自动化”模式，生成 submit-stack 类命令。体验：命令文件把“分析→行动→报告”拆得分明，代理执行时不容易跳步；注意要把“禁止直接 push 到主干”这类限制明确写进工具约束里。
场景二：CI 失败的循环修复（团队协作场景）
痛点：CI 一遍遍红，人工看日志、改代码、再推送，来回十几轮。使用方式：选“迭代修复”模式，描述“运行检查→解析报错→修复→重跑，直到通过”，生成 ensure-ci 类命令。体验：这类命令的价值在于“重试直到成功”的循环被固化，人只需最后确认；需要注意设置最大重试次数并写明失败时的上报方式，否则容易陷入无效循环。
场景三：需求到实施计划的流转（Tech Lead / 架构角色）
痛点：口头讲完方案，执行细节全靠对方揣摩，落地质量参差。使用方式：选“代理委派”模式，先读取 .PLAN.md 之类的计划文件，再把子任务委派给子代理并迭代。体验：把“读上下文→拆解→委派→汇总”写进命令后，同一份计划可以被反复执行且结果稳定；注意命令中要指定必须预读的文件路径，否则代理可能在没有上下文的情况下自行发挥。
场景四：个人开发者的轻量快捷操作
痛点：只想把某条常用命令变成快捷方式，比如带参数跑一次代码审查。使用方式：选“简单执行”模式，加一个可选参数占位符即可。体验：上手最快，一分钟出结果；这类命令结构简单，但仍建议补齐 description 字段，否则在 /help 列表里看不出用途。
整体上手难度：低。全程是对话式追问，不需要事先学习 frontmatter 语法；真正需要花心思的是“把自己的流程讲清楚”，而这恰恰是技能通过结构化追问帮你完成的。
该技能能为用户带来的价值
- 把隐性经验变成显性资产：过去“老员工脑子里的流程”变成仓库里可读、可改、可评审的 Markdown 文件，新人拉下代码就能用同样的命令跑同样的流程。
- 显著降低编写门槛：不用记目录规范、frontmatter 字段、参数写法、代理执行偏好，描述需求即可产出；原本可能需要反复查文档、试错半小时的命令，变成几分钟的对话。
- 提升流程一致性：同一命令每次执行路径相同，减少漏跑测试、漏检查类型、提交信息格式不统一等“人因失误”。
- 降低维护成本：命令正文用祈使句、明确预期结果与错误处理，后续修改只需改一处文件，团队共享即时生效。
- 可复利的长期价值：每固化一个流程，后续每次执行都在为团队省时间；命令库随项目沉淀，项目越复杂，收益越明显。
常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认生效？
A：在支持 Agent Skills 的客户端的技能市场或技能列表中，用英文名 command-creator 或技能ID 12220 搜索并安装即可，具体安装入口与命令以官方说明为准。验证方法：新开会话说“帮我创建一个斜杠命令”，若助手开始追问命名、用途、参数、步骤等信息，说明技能已正常触发。
Q2：这个技能收费吗？
A：技能本身的定价与授权方式取决于你使用的技能平台或客户端，本技能详情中没有相关说明，请以官方说明为准。技能产出的命令文件是存放在你本地目录中的普通 Markdown 文件，不涉及额外费用。
Q3：生成的命令会放在哪里？会不会污染我的项目？
A：技能会自动检测当前是否在 Git 仓库中：在仓库内默认写入项目级 .claude/commands/，不在仓库内则写入全局 ~/.claude/commands/，并允许你用“全局”或“项目级”明确指定。写入前会向你报告所选位置，命令文件只有一个 Markdown，完全可以纳入版本管理或随时删除。
Q4：命令名字能用下划线吗？调用不生效怎么办？
A：不能。技能明确要求 kebab-case 命名（如 submit-stack），文件名与命令名严格对应，my-command.md 对应 /my-command，写成下划线形式会出现调用异常。若调用不生效，先检查文件名是否带连字符、是否放在正确的 commands 目录下、frontmatter 中的 description 是否存在。
Q5：它和手写命令、提示词模板、IDE 规则文件怎么选？
A：需要“可一键触发的多步骤流程”就选本技能；命令极其简单且你想完全掌控细节，手写 Markdown 也够用；只是一次性任务，复制提示词模板最快；想统一全局编码风格而非定义可调用动作，用 IDE 规则文件更合适。三者并不冲突，实践中常常是规则文件管“风格”、斜杠命令管“流程”。