元技能榜单：造工具的工具

先给清单：官方这九件，装法都在下面

怎么装（命令都是官方页面上的原文）

# ① 官方 skills 仓库：注册 marketplace，再按包装
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills
/plugin install document-skills@anthropic-agent-skills

# skill-creator 另有一条官方 plugin 源（Claude Code 文档给的就是这条）
/plugin install skill-creator@claude-plugins-official

# ⑧ 体检：列出每个 skill 的 context 开销与调用频次（需 v2.1.252+）
/skill-doctor

# ⑨ 校验：查 YAML 与清单语法
claude plugin validate .claude/skills

逐条说人话

• ① skill-creator（官方）：它真正的重头戏在后半段——为新 skill 写 2–3 条真实测试提示，然后并行开两组 subagent：一组带 skill、一组不带，用 agents/grader.md 按断言打分，跑 scripts.aggregate_benchmark 汇成 benchmark.json，再用 eval-viewer/generate_review.py 让人肉过一遍。Claude Code 文档描述的同一条链是：测试用例存进 skill 目录下的 evals/evals.json → 每条用例开独立 subagent 跑 → 结果进 grading.json → 通过率/耗时/token 汇进 benchmark.json。它还能做 A/B 与 description 调优。
• ② mcp-builder（官方）：把「写一个 MCP server」拆成研究规划 → 实现 → 审查测试 → 评估四阶段，Python(FastMCP) 与 Node/TypeScript 两套实现指南各带一份。硬要求是造 10 道验收题，每道必须互相独立、只读、复杂、真实、可核验——而且你得自己先做一遍答出来，答案要能做字符串比对。
• ③ web-artifacts-builder（官方，注意真名不是 artifacts-builder）：一整套把 React 18 + TypeScript + Tailwind + shadcn/ui 打成单文件 HTML 的工具链，确定性动作全写成脚本——scripts/init-artifact.sh 起项目、scripts/bundle-artifact.sh 用 Parcel 打成 bundle.html，初始化时就带好 40 多个 shadcn/ui 组件。
• ④ claude-api（官方）：先探测项目语言，再只读该语言那一份文档；共享部分按域拆成 shared/prompt-caching.md、shared/cost-optimization.md、shared/model-migration.md、shared/token-counting.md 等。它不是造 skill 的工具，收进本榜是因为它是「一个 SKILL.md 挂多份领域文档」这个结构最完整的官方范本（Skill 23 会把它拆开）。
• ⑤ template/SKILL.md：仓库 template/ 下只有这一个文件，内容短到近乎挑衅——frontmatter 里 name: template-skill 加一句「把 description 换成这个 skill 做什么、什么时候该用」，正文只有一行 # Insert instructions below。这就是官方认为的最小合格骨架。
• ⑥ agent-skills-spec：仓库里 spec/agent-skills-spec.md 现在只剩一句话——规范已迁至 agentskills.io/specification。这条本身就是情报：字段真相源已经从 Anthropic 仓库挪到了独立站点（Claude Code 的 skills 文档也把评估章节指向同一个站）。抄 2025 年的仓库快照会抄到旧版。
• ⑦ Skill authoring best practices（platform.claude.com）：第 03 节所有判据的原始出处，连「先写评估再写文档」的五步法和最后那张 checklist 都在这一页。
• ⑧ /skill-doctor 与 ⑨ claude plugin validate：前者列出每个 skill 的 context 开销与调用频次，标出从没被触发过的、最近没用过的 plugin；后者查 marketplace.json 的 schema 错误、重名、源路径穿越、版本不一致。

这九条不能混着比：三层各自的分母不一样

背景与原理

anthropics/skills 据 GitHub 仓库页 2026-09 约 17.5 万 star / 2.07 万 fork（本站 Skill 01 在 2026-08 记的是 17.2 万，一个月涨了约三千）。但这个数字量的是「示范仓库有多出名」，不是「里面哪个 skill 有人用」——整仓 19 个 skill 共用同一个 star 数，skill-creator 和 slack-gif-creator 在这个指标上完全等价，显然荒谬。

更实际的分层理由是可替代性：⑤ template 与 ⑦ 最佳实践是纯文本，你抄进自己的仓库就永远拥有它，没有版本风险；①—④ 是会跑的东西，升级、依赖、脚本失效都跟着上游走；⑧—⑨ 是 Claude Code 的能力，换个 harness 就没有了。三层的保质期完全不同，别拿同一套标准挑。

实战示例

还有个坑：名字会被抄错。③ 的真名是 web-artifacts-builder，不少聚合文章写成 artifacts-builder——照那个名字装会装不上、让 agent 去找会找不到。同理 ⑥ 的位置也已经变了：仓库里那个文件还在，但内容只剩一句「规范已搬到 agentskills.io」。硬规矩：任何要写进配置或喂给 agent 的名字与路径，一律以仓库目录或官方文档页面为准。

三分钟验货：把这四个官方 skill 自己的写法当判据

背景与原理

先记住硬约束（官方 authoring 页原文）：name ≤ 64 字符，只许小写字母、数字、连字符，不能含 anthropic / claude 这类保留词；description ≤ 1024 字符，非空，必须第三人称；正文建议 500 行以内；引用只许一层深。另外 Claude Code 文档还给了一个容易被忽略的数：skill 列表里 description 与 when_to_use 合起来按 1536 字符截断——写超了的部分不是被读到，是被砍掉。

实战示例

1. description 是不是把触发词铺满了——看 skill-creator 的原文：「create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description」。一句里塞进 create / edit / optimize / run evals / benchmark 五组说法，因为用户嘴里可能是任何一种。只写「Helps with skills」的，要么永不触发，要么到处乱触发。
2. 有没有可机器核验的验收标准——mcp-builder 要求那 10 道题「答案要支持字符串比对」。这句是分水岭：写得出这句的作者，知道自己在追求什么；写不出的，交付标准就是「看起来还行」。
3. 确定性动作有没有落成脚本——web-artifacts-builder 把起项目和打包写成 init-artifact.sh / bundle-artifact.sh，而不是每次让模型现编。官方的理由很直白：预置脚本更可靠、更省 token（只有输出计费，脚本内容不进上下文）、结果还一致。
4. reference 是不是按域拆、且只有一层——claude-api 按语言 + 按主题拆出十几份文档，SKILL.md 只当目录。官方明确警告：嵌套引用时模型常常只 head -100 扫一眼开头，拿到残缺信息；所以所有 reference 都要从 SKILL.md 直连。超过 100 行的 reference 还该自带目录。
5. 自由度和任务脆弱性匹不匹配——官方比喻是「两侧是悬崖的窄桥 vs 空旷原野」。数据库迁移要低自由度（给死命令，并写明「不要改这条命令、不要加参数」）；代码审查要高自由度（给方向）。
6. 它说不说得出自己解决的三个具体失败——官方 checklist 的原话是「至少创建三条评估」，并且要求「用 Haiku、Sonnet、Opus 各测一遍」。这条答不上来的元技能，你没法判断它有没有用。

顺序也别写反。官方 authoring 页把「先建评估，再写文档」写成加粗要求，五步是：跑无 skill 的真实任务、记下具体失败 → 就这些缺口造三个场景 → 量出基线 → 只写刚好够补缺口的字 → 迭代对照基线。它给的理由是：这样你解决的才是真问题，而不是想象出来的需求。

诚实的代价：官方文档亲口说「你不需要一个写 skill 的 skill」

背景与原理

authoring 最佳实践页里有一条 Tip，直白到有点扫兴：Claude 原生就懂 skill 的格式与结构，你不需要特殊系统提示词、也不需要一个「写 skill 的 skill」，直接叫它写，它就会生成结构正确、frontmatter 齐全的 SKILL.md。

那 skill-creator 的价值在哪?在它后半段那套评估机器，不在起草。并行开两组 subagent 做有/无 skill 对照、按断言打分、汇出 benchmark.json——这套东西你手搓要花一整天。冲着「帮我生成 SKILL.md」去装它，你付了 context 税，换回来的是本来就免费的东西。

实战示例

• 评估这条线是分叉的，别以为写一份到处能跑。平台文档给了评估的 JSON 结构（skills / query / files / expected_behavior），却明说目前没有内置的方式来跑这些评估，要自己搭；Claude Code 侧的 skill-creator 则有自己一整套 evals.json → grading.json → benchmark.json 的流程。两条线不通用。
• validate 过了 ≠ skill 没问题。官方文档写得很清楚：从 marketplace 目录跑校验时，Claude Code 不会打开各插件的 skill / agent / command / hook 文件；要查那些文件里的错，得对单个插件跑校验。把 claude plugin validate 当质量门是误会——它是语法体检，不是内容体检。
• 元技能是「为一次性任务装的常驻工具」。你一年写五个 skill，却让 skill-creator 常驻一整年的 description 候选池。所以写完就该 /skill-doctor 回头查账——它会标出从没被触发过的 skill，那些直接删掉，留着只会让别的 skill 更难被选中。
• 生态位移是真实成本。规范搬到 agentskills.io、Claude Code 的评估章节也指过去，意味着你的 skill 库要跟着一个仓库之外的版本走。跨 harness 用的团队，该把当期规范的关键字段抄一份进自己仓库，别每次现查。