28 · skill-creator 使用：用一个 skill 造你自己的 skill

📚 系列导航：上一篇 27 Skills 使用实例 教你怎么用好别人造的 skill——装进来、让它自动触发、用得顺手。这一篇反过来：教你造自己的。而且不靠手搓，靠官方那个专门用来造 skill 的 skill——skill-creator。

都说 SKILL.md 不就一个 markdown 文件嘛，自己手写就完了，犯得着再请个工具？

说句实话，这话只对了一半。文件确实简单，但「造一个能被准确触发的 skill」这件事一点都不简单——而手写翻车的，九成栽在同一个地方：description 写歪了，结果这 skill 永远叫不动。

我自己第一个手写的 skill 就是这么翻的。当时想做一个「生成符合团队规范的 commit message」的 skill，目录建好、正文写得明明白白，description 我随手填了句「Commit message helper」。结果呢？每次让 Claude 提交，它压根不理我那个 skill，自己按通用习惯写一版。我一口咬定是没装好，折腾半天 /doctor、重启、重装，全没用。后来才搞明白——问题不在「装没装上」，在「描述里没有用户会说的那些词」。这种坑，手写时你完全看不见，得有个东西逼你把它做对。

skill-creator 就是那个东西。

看完这一篇，你会拿到：

• 为什么手写 SKILL.md 看着省事、实际最容易踩坑，skill-creator 到底帮你做对了哪几件事
• skill-creator 的完整造 skill 流程：起脚手架 → 引导写 name / description / 正文 → 组织 scripts 和 references → 打包
• 全篇最值钱的一节：description 怎么写才能被准确触发（含触发场景关键词，还得「主动」一点）
• 个人 skill 和项目 skill 该落在哪个目录，谁能用到
• 一个能照着跑的动手实战：用 skill-creator 起一个最小 skill，并亲手验证它真的被触发了

---

01 反共识：手写 SKILL.md 不难，难的是「让它叫得动」

先把上一篇的底子接上。27 篇里你已经知道：一个 skill 就是一个目录，核心是里面那个 SKILL.md，顶上一段 YAML 写 name 和 description，下面是给 Claude 看的正文。官方文档原话：

每个 skill 都需要一个 SKILL.md 文件，包含两部分：YAML frontmatter（在 --- 标记之间）告诉 Claude 何时使用该 skill，以及包含 Claude 在调用该 skill 时遵循的说明的 markdown 内容。

看着是不是特简单？建个文件夹、写个文件，齐活。所以新手第一反应都是：手写就行了，要什么工具。

这就是那个反共识的点：手写本身确实不难，难的是手写出来的 skill「叫不动」——你以为它会在该出场的时候自动出场，结果它一直在角落里睡觉。

类比：填一张表单的「造工具向导」。 你装新软件时见过那种向导吧——它不让你对着空白配置文件瞎填，而是一页一页问你「这工具叫什么」「什么情况下该用它」「输入长啥样、输出要什么格式」，你回答几个问题，它在背后把目录结构、脚手架、各字段的位置全给你摆对。skill-creator 就是 skill 界的这种向导：你回答它几个问题，它把那些「手写时你根本想不到要管」的事替你做对。

具体它替你兜住了哪几个手写最容易翻的坑？看这张对照表——这是本节最该记住的：

容易翻车的环节	❌ 纯手写常见结果	✅ skill-creator 帮你做对
description	写成「Commit helper」这种，缺触发词，永远不触发	引导你写清「干什么 + 什么时候用」，含用户会说的关键词
目录结构	把脚本、参考文档全塞进 SKILL.md，又长又乱	帮你分到 scripts/ references/，正文保持精简
触发验证	写完不知道到底触不触发，全靠玄学	给你测试用例，跑一遍看它到底叫不叫得动
改进	没触发只能干瞪眼，不知道改哪	有专门的描述优化环节，对着触发率调

看出来没？手写翻的车，全是「你看不见所以没管」的事。skill-creator 的价值不是帮你打字（打字它没快多少），而是逼你把这几件隐形的事一件不落地做对。

💡 一句话总结：手写 SKILL.md 不难，难在让它在该触发时真触发；skill-creator 像个填表造工具的向导，把 description、目录、验证、改进这几件「手写时看不见」的事替你兜住。

---

02 skill-creator 是什么、怎么请它出场

先给结论：skill-creator 本身就是一个 skill，它的专长是「造别的 skill」。听着像绕口令，但逻辑很顺——既然 skill 是用来扩展 Claude 能力的，那「造 skill」这件重复性工作，本身就值得做成一个 skill。

它不是 Claude Code 自带就有的（不像 /code-review、/debug 那几个捆绑 skill），需要单独安装——把 skill 目录放到 ~/.claude/skills/（个人全局）或项目的 .claude/skills/（只对这个项目生效），第 27 篇已讲过这套机制。官方插件市场（claude-plugins-official）里对应「创建插件」的工具包叫 plugin-dev，skill-creator 是独立发布的 skill，安装方式是直接克隆或下载目录到 skills 路径：

# 把 skill-creator 目录放到个人 skills 目录
cp -r skill-creator ~/.claude/skills/

预期：放好后，/skills 列表里能看到 skill-creator，描述写着「Create new skills, modify and improve existing skills...」。

装好之后，请它出场有两种姿势，跟 27 篇讲的「用 skill」一模一样：

姿势一：直接喊名字（明确指令）。

/skill-creator

姿势二：用大白话说你要干啥（让它自动触发）。 这也是更常用的一种——因为 skill-creator 的 description 写得很「全」，你说「我想做一个 skill 来干 XX」它就接住了：

我想做一个 skill，每次帮我把 git 改动总结成一条规范的 commit message

不管哪种姿势，接下来它都不会闷头给你甩一个文件，而是像向导一样开始问你问题。官方那个 skill-creator 的说明里，第一步就叫「Capture Intent（捕捉意图）」，它会问你这么几件事：

1. 这个 skill 要让 Claude 能干什么？
2. 它应该在什么时候触发？（用户会用哪些说法 / 在什么场景）
3. 期望的输出格式是什么？
4. 要不要建测试用例来验证它能正常工作？

注意第 2 问——「什么时候触发」它会专门问你一遍。这就是它跟手写最大的不同：手写时这个问题没人逼你回答，你随手糊一个描述就过去了；skill-creator 把它当头等大事，因为它知道这一问答不好，造出来的 skill 就是个废物。

类比：婚礼策划师接单先把你问个底朝天。 靠谱的策划不会上来就甩方案，他先问「预算多少」「请多少人」「想要中式还是户外」「有没有忌讳」。把这些问透了，出的方案才贴你的需求，而不是套个模板了事。skill-creator 的「Capture Intent」就是这道「问需求」工序——先把你要什么问明白，再动手攒 skill。

💡 一句话总结：skill-creator 是个「造 skill 的 skill」，从官方插件市场装（需魔法上网）；喊 /skill-creator 或大白话说需求都能唤出它，它出场第一件事是反过来问你问题，尤其会专门问「这 skill 什么时候该触发」。

---

03 它替你走完的完整流程

skill-creator 不是只帮你生成一个文件就撒手，它会陪你走完造 skill 的一整条流水线。把它的流程拆开看，你就知道每一步它在帮你兜什么。

官方 skill-creator 把整个过程概括成一个循环，我给你翻成大白话：

1. 想清楚要干啥：先跟你聊明白这 skill 做什么、大概怎么做（就是上一节的「Capture Intent」）。
2. 写初稿：根据你的回答，填好 name、description 和正文，生成 SKILL.md。
3. 建测试用例：写 2-3 个「真实用户会说的话」当测试 prompt，问你「这几个测试像不像样，要不要加」。
4. 跑一遍 + 评估：拿这些 prompt 实际跑，让你看结果好不好——既看「输出对不对」，也看「该触发的有没有触发」。
5. 照反馈改：根据你的评价和测试结果回头改 skill，改完再跑一轮，直到你满意。
6. （可选）优化描述：专门有个环节优化 description，把触发准确率往上调。
7. 打包：最后把整个 skill 目录打成一个 .skill 文件，方便你分发或安装。

看出这条流水线的门道没？手写时你只做了第 2 步（写个文件），后面 3-7 全跳过了——所以你的 skill 触不触发全凭运气，触不动也不知道怎么改。skill-creator 的价值就在于它把 2 之后那几步当成必修课，尤其是「跑测试看触发」和「照反馈改」这个循环。

这里穿插一个它帮你做对的目录结构。官方文档「添加支持文件」一节给的目录示例是这样的：

my-skill/
├── SKILL.md           # 主要说明（必需）
├── reference.md       # 详细参考文档，按需加载
├── examples.md        # 示例输出，按需加载
└── scripts/
    └── helper.py      # Claude 可以执行的脚本

关键认知：SKILL.md 要短，重的东西往外放。官方原话点得很透：

将 SKILL.md 保持在 500 行以下。将详细的参考资料移到单独的文件中。

为啥要这么分？因为 skill 一旦触发，SKILL.md 的内容会整段进上下文、并在整个会话里赖着不走——每一行都是重复的 token 成本。而 scripts/ 里的脚本是「执行但不加载」、references/ 里的文档是「需要时才读」。手写最容易犯的错，就是把一份三百行的 API 文档直接糊进 SKILL.md，又占上下文又乱。skill-creator 会引导你把这些分门别类放对地方——正文只留「干什么、去哪找」，重资料挪进 references/，可执行的活儿挪进 scripts/。

类比：写一本书的目录页和附录。 你不会把所有内容都堆在目录页上，目录页只写「第几章讲什么、在哪一页」，详细内容在正文和附录里。SKILL.md 就是那张目录页——它告诉 Claude「有哪些料、什么时候去翻哪一份」，料本身放在 references/ 和 scripts/ 里。

💡 一句话总结：skill-creator 陪你走的是「想清楚 → 写初稿 → 跑测试看触发 → 照反馈改 → 优化描述 → 打包」一整条流水线；手写往往只做了第二步，它把后面那几步补全了，还会引导你把重资料分到 references/ 和 scripts/、让 SKILL.md 保持精简。

---

04 全篇最值钱的一节：description 怎么写才叫得动

如果这篇你只记一件事，记这件：description 是决定一个 skill 触不触发的「总开关」。

为什么是它？因为 Claude 在每次对话里，看到的不是你 skill 的全文——它先看到的只是一串「skill 名字 + description」的清单，然后根据这个 description 判断「这次该不该把这个 skill 调出来」。description 写得对不对，直接决定它会不会被想起来。官方在「Skill 未触发」的排查里，第一条就是冲着它去的：

检查描述是否包含用户会自然说的关键字。

开头我那个翻车的 commit skill，病根就在这。写的是「Commit message helper」——这句话里一个「用户会说的词」都没有。我平时嘴里蹦出来的明明是「帮我提交」「写个 commit」「生成提交信息」，可描述里这些词一个没有，Claude 自然对不上号。后来我让 skill-creator 把描述改成下面这样，再喊一句「帮我提交」，它立马就接住了。

对照一下这两种写法，差距一目了然：

❌ 手写常见的废描述	✅ skill-creator 引导出的好描述
Commit message helper	把暂存的改动总结成一条符合团队规范的 commit message。当用户说「帮我提交」「写个 commit」「生成提交信息」或让你 review 改动准备提交时使用。
只说了「是什么」	既说「干什么」，又说「什么时候用、用户会怎么说」
缺触发词，永远不触发	含真实触发词，该出场时准时出场

提炼成一句口诀：好的 description = 干什么 + 什么时候用（含用户会说的那些原话词）。「干什么」让 Claude 知道这工具是干嘛的，「什么时候用」才是真正的触发钩子——而且这部分要尽量写成用户嘴里会蹦出来的大白话，不是你脑子里的术语。

还有一个反直觉的点，是从 skill-creator 那儿能学到的：描述要「主动」一点，甚至略微「催」一点。因为目前 Claude 有个倾向，叫「undertrigger（该用没用）」——它经常在 skill 明明能帮上忙时，懒得调出来。skill-creator 的内部说明里专门叮嘱要对抗这个：

目前 Claude 有不愿触发 skill 的倾向——在 skill 本可派上用场时不去用它。为对抗这一点，请把 skill 描述写得稍微「主动」一些。

什么叫「主动」？举个它给的例子的味道：与其干巴巴写「构建一个展示内部数据的仪表盘」，不如写成「……只要用户提到仪表盘、数据可视化、内部指标，或者想展示任何公司数据，哪怕没明说要『仪表盘』，都该用这个 skill」。把「即使用户没明说，也该出场」的场景显式写进去——这一手能显著提高它被叫动的概率。

类比：给店门口的招牌写文案。 招牌只写「张记」，路人不知道你卖啥，不会进来；写成「张记牛肉面 · 加面免费 · 辣的不辣的都有」，把客人可能搜的词都铺上，进店的人立马多了。description 就是你这个 skill 的招牌——招牌上要有顾客嘴里会念叨的词，还得主动招呼。

💡 一句话总结：description 是触发总开关，公式是「干什么 + 什么时候用（含用户会说的原话关键词）」，而且要写得略微主动、把「没明说也该出场」的场景铺进去——这一句写好了，skill 才叫得动；写歪了，正文再漂亮也白搭。

---

05 落在哪个目录：个人 skill vs 项目 skill

skill 造好了，存哪儿？存的位置直接决定谁能用到它。这点 skill-creator 会问你，但你得自己心里有数。

官方给的位置表，挑出小白最常用的两档：

位置	路径	谁能用