// WHY THIS MATTERS
skill = 一个装着 SKILL.md 的文件夹，agent 觉得跟当前任务相关时才把它读进上下文。2025 年 10 月 Claude Code 上线 plugin 系统之后，这东西长成了一整个市场：官方仓库、几家第三方 marketplace、无数「最好用的 N 个 skill」榜单。本期直接给编码类里十个真实可装的：它替你干掉哪件事、命令怎么敲、什么时候装了反而是负担。后半程再讲怎么自己判断——因为清单会过期，判据不会。这一期是本系列开篇，后面几期把其中最值得的逐个拆开。
// 01
先给清单：编码类里这十个可以直接装
论断：编码场景真正跑得起来的组合是「一条流程骨架 + 三四个高频动作 + 一个造 skill 的 skill」。下面这十个都能给出仓库或 marketplace 页面，装法都在第二段。
装什么 替你干掉的那件事 什么时候别装
───────────────────────────────────────────────────────────────────────────
superpowers 整条开发流水线：计划→TDD→审查 十分钟能改完的活
code-reviewer diff → 按严重度分级的问题单 已有严格 CI + 人审
git-commit-writer staged diff → commit 文案 团队没有 commit 规范
pr-description-writer 分支 diff → PR 正文 + 测试计划 改动都很碎的仓库
changelog-generator commit 区间 → semver 条目 根本不发版的项目
env-doctor 本地环境排障 Node/venv/Docker 全员容器化开发
truth-first 逼它跑完再说「做好了」 你更在意回答简短
webapp-testing ★ 前端改完自己开页面验 纯后端 / CLI 项目
mcp-builder ★ 写 MCP server 的脚手架 你不打算写 server
skill-creator ★ 生成 SKILL.md 脚手架 —— 这个建议都装
───────────────────────────────────────────────────────────────────────────
★ = Anthropic 官方 anthropics/skills 仓库里的；其余为第三方 marketplace 上的单点 skill
怎么装（三条路，命令都是官方给的）
# ① 官方仓库 anthropics/skills（★ 那几个都在这里）
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills
/plugin install document-skills@anthropic-agent-skills
# ② Superpowers：走官方 plugin 源，一条命令
/plugin install superpowers@claude-plugins-official
# Cursor：/add-plugin superpowers
# Gemini CLI：gemini extensions install https://github.com/obra/superpowers
# ③ 第三方 marketplace 上的单点 skill：没有命令，就是拷文件夹
# 下载 zip → 解压到 ~/.claude/skills/<skill-name>/ → 重启 agent 即生效
逐条说人话
- superpowers（obra，MIT，据 GitHub 仓库页 2026-08 约 27.9 万 star）：不是干某一件事，是把「头脑风暴 → 开 git worktree → 写计划 → subagent 分工实现 → TDD → 代码审查 → 收尾合并」这七段钉成强制流水线，支持 15+ 种 agent。任务越大越划算，小活上它是纯负担。
- code-reviewer / git-commit-writer / pr-description-writer / changelog-generator：四个都是「一个 diff 进去、一段规范文本出来」，装完立刻能用，天花板也低。据 Agensi 的装机量榜（该页 2026-03 发布、2026-04 更新）它们分别是 764 / 232 / 127 / 44 次安装。
- env-doctor：专治本地环境——Node 版本、Python venv、Docker 缓存这类「昨天还好好的」。全员容器化开发的团队用不上。
- truth-first：逼模型跑完代码再声称「做好了」，治的是虚假完成声明。代价是每次回答更啰嗦、更慢。
- webapp-testing / mcp-builder / skill-creator（官方三个）：分别是「前端改完让 agent 自己开页面验」「写 MCP server 的脚手架」「生成 SKILL.md 脚手架」。
skill-creator 建议人人都装——你迟早要写自己的。
失败模式：看到「27.9 万 star」就装 superpowers 去写一个 50 行脚本——强制 TDD + 两段式审查会让你为一件十分钟的事付一小时；或者把 anthropics/skills 当应用商店整仓克隆，那 19 个里有 algorithmic-art、slack-gif-creator、canvas-design，跟你的工作毫无关系。
// 02
这十个不该放进同一张榜比：分母不一样，名字还常被抄错
论断：star 榜、装机量榜、编辑推荐榜量的是三件事。上表里 superpowers 的 star 是六位数，单点 skill 的装机量是三位数——这不是「谁更受欢迎」，是分母根本不同。
背景与原理
star 数着的是全 GitHub 的路人（anthropics/skills 据仓库页 2026-08 约 17.2 万 star，但它是「示范怎么写 skill」的参考实现，不是「你该装什么」的清单）；装机量数的是某一个 marketplace 的注册用户；「编辑推荐」数的是写稿人的偏好。三者不可比。
数字还在动。上一节引的 code-reviewer 764 次安装来自一份 2026-03 的榜；去它的 skill 页看，2026-08 显示的是 1,236 次。五个月涨六成——所以任何榜位都必须连着「哪个池子、哪个月」一起读，否则就是噪声。
更实际的坑是名字被抄错：好几篇 2026 年的聚合文章把官方 skill 写成 artifacts-builder 和 slack-formatter，去仓库目录一看实际叫 web-artifacts-builder 和 slack-gif-creator，后者根本不是格式化 Slack 消息的，是做 GIF 的。名字错了你照着装会装不上，让 agent 照着找会找不到。
实战示例
立一条硬规矩：任何要写进配置、喂给 agent、转述给同事的 skill 名，一律以仓库目录或官方 marketplace 页面为准，聚合文章只用来发现候选，不用来抄名字。读榜补三问——量的是什么？哪个池子？哪个月的数？
失败模式：把某个 marketplace 的榜首当「行业第一」写进团队规范；或反过来，因为某个 skill「才 32 次安装」就否掉它——在一个细分类目里那可能已经是天花板。
// 03
清单之外：打开 SKILL.md 三分钟验货
论断：Anthropic 那份《Skill authoring best practices》是写给作者的，但每一条都能反过来当买家的判据——上面十个之外你自己发现的候选，用这六条筛。
背景与原理
先讲机制：agent 启动时只把所有 skill 的 name 和 description 预加载进系统提示词，正文 SKILL.md 等它被判定相关时才读，附带文件再按需读——这叫渐进式披露。所以 description 决定它会不会被触发，SKILL.md 的长度决定它触发之后吃掉你多少上下文。官方硬约束：name ≤ 64 字符（小写+数字+连字符）、description ≤ 1024 字符，正文建议 500 行以内。
实战示例
- description 写没写「什么时候用」：官方要求同时写清做什么和何时用，且用第三人称（「Processes Excel files…」而非「I can help you…」）。只写「Helps with code」的，要么永不触发，要么到处乱触发。
- SKILL.md 超没超 500 行：超了还不拆文件，说明作者没做渐进式披露，你每次触发都在为没用上的内容付 token。
- 引用是不是只有一层：SKILL.md →
reference.md 可以，reference.md → details.md 不行——嵌套时模型常常只扫一眼开头，拿到残缺信息。
- 自由度匹不匹配任务：官方比喻是「悬崖窄桥 vs 空旷原野」。数据库迁移要低自由度（给死脚本）；代码审查要高自由度（给方向）。把 code review 写成十二步死流程的，是把原野当窄桥走。
- 有没有可执行脚本 + 校验闭环：确定性操作该是预置脚本而不是让模型现编——脚本只有输出计费、内容不进上下文。质量攸关处还该有「跑校验 → 报错 → 修 → 再跑」。
- 说不说得出它解决的三个具体失败：官方方法论是先写评估再写文档。这条答不上来的，你没法判断它有没有用。
// 04
装多了的代价：context 税、触发打架、以及本该用别的东西
论断：单个 skill 的边际成本只有几十 token 元数据，但真正的成本不在启动，在于选择——描述重叠的 skill 越多，模型挑错的概率越高。
背景与原理
渐进式披露确实让「装 100 个」在启动时几乎免费。但 description 之所以关键，正是因为模型要从上百个候选里挑一个。上表里如果再塞进 codex-grade-coding、再加一个自制的「代码质量」skill，你就制造了一个选择问题，而不是能力叠加。
另一半代价是：你要的东西可能根本不该是 skill。
- Skill = 注入「怎么做这件事」的知识。适合有稳定套路、要模型按你规矩来的任务。
- Subagent = 起个上下文隔离的分身去干活，只带结论回来。适合会产生大量中间垃圾的探索。
- MCP server = 接外部能力与实时数据（查最新文档、开浏览器、读数据库）。skill 教不会模型它不知道的事实，MCP 可以。
- Hooks = 「每次提交前跑 lint」这种该由代码保证，写进 skill 只是祈祷模型记得。
实战示例
判断顺序：这事每次都必须发生吗 → hook；需要外部数据或能力吗 → MCP；会产生大量不必留在主上下文的中间过程吗 → subagent；只是「模型知道该怎么做就行」吗 → skill。
失败模式：把一份 API 文档做成 skill 塞进上下文——文档会过期，每次触发还吃 token，这是文档检索类 MCP 的活。反过来，把团队代码规范做成 MCP tool 也错，那是纯知识，skill 才对。另外：第三方 skill 是别人写的可执行指令——Agensi 的 skill 页会标「Security scanned · 5 个月前验过」，5 个月前的扫描不等于现在干净，装之前自己打开 SKILL.md 读一遍。
// 一页选购卡
先装这三个：skill-creator（官方，你迟早要写自己的）+ code-reviewer 或 git-commit-writer（挑你每天真的在做的那件）+ superpowers（只在你的活确实是多步骤工程时）。不要一口气装十个。
装之前三分钟：description 有没有写「何时用」且第三人称 · SKILL.md 是否 < 500 行 · 引用是否只有一层 · 自由度是否匹配任务脆弱性 · 有没有校验脚本 · 说不说得出它解决的三个具体失败。
读榜三问：量的是什么？哪个池子？哪个月的数？——名字一律以仓库目录为准，别抄聚合文章。
装完两周复查：它触发过几次？有没有误触发？没触发过的直接删——留着只会让别的 skill 更难被选中。
// 术语表
- Agent Skill
- 一个文件夹，里面必有
SKILL.md（YAML 头 + Markdown 正文），可选附带参考文档与可执行脚本。agent 按需读进上下文，用来学「怎么做某类任务」。
- SKILL.md / frontmatter
- skill 的主文件。开头 YAML 头必填
name（≤64 字符，小写+数字+连字符）与 description（≤1024 字符）。
- progressive disclosure（渐进式披露）
- 启动时只预加载所有 skill 的 name+description；正文触发后才读，附带文件用到才读；脚本只执行、内容不进上下文。这是「装很多 skill 也不炸上下文」的机制基础。
- harness
- 跑 agent 的那层壳（Claude Code、Cursor、Codex CLI 等）：它决定上下文怎么组织、工具怎么暴露、skill 怎么被加载。同一个 skill 在不同 harness 上表现可以不同。
- marketplace / plugin
- skill 的分发渠道。plugin 是能一次打包 skill + 命令 + hooks 的更大单位；marketplace 是列出这些包的目录站，官方与第三方各有。
- MCP（Model Context Protocol）
- 让 agent 接外部工具与数据源的开放协议。补的是「模型不知道的事实与做不到的动作」，与 skill 补的「知识与套路」互补。