绝大多数 Skill 的故事是“一个文件夹、一份 SKILL.md、解决一件事”。本文拆的 obra/superpowers 不是这个故事——它是一整套由十几个 Skill 组成的技能家族，家族内部互相调用、层层接力，把“从一个模糊想法到合并代码”的完整工程流程硬编码进 Claude Code：先头脑风暴、再写计划、再逐任务执行、每个任务强制测试驱动、出了 bug 必须走根因分析。本文逐一拆解其中六个核心成员的 SKILL.md 设计，重点看一个此前拆解文章很少触及的问题：Skill 与 Skill 之间是怎么接线的。评测对象信息基于作者公开仓库与博客连载，具体 Star 数未经官方证实，文中不作精确标注。
superpowers 的作者是 Jesse Vincent（GitHub ID：obra），资深开源开发者、问题追踪系统 RT 的作者。2025 年 10 月前后，他在个人博客 blog.fsck.com 上连载了一系列文章，讲述自己如何把多年工程习惯移植给 Claude Code，随后开源了这套技能库。上线后迅速成为社区引用率最高的第三方技能库之一，被大量后来的 Skill 作者模仿——今天在很多新 Skill 里能看到的“先侦察再动手”“逐任务提交”等条款，往上追溯多半有它的影子。
它解决的是大模型的两个老毛病：
superpowers 的答案不是调参、不是写更长的系统提示词，而是把流程拆成一串 Skill，每个 Skill 只负责一个阶段，完成时把接力棒交给下一个。这本质上是工程管理，不是提示词工程。
flowchart TD
A["模糊想法"] --> B["brainstorming<br/>逐问逼出设计决策"]
B --> C["设计文档<br/>docs/plans/ 下落盘"]
C --> D["writing-plans<br/>设计拆成分阶段计划"]
D --> E["计划文件<br/>带勾选框的任务清单"]
E --> F["executing-plans<br/>逐任务执行"]
F --> G["每个任务内"]
G --> H["test-driven-development<br/>红-绿-重构循环"]
G --> I{"出 bug?"}
I -- 是 --> J["systematic-debugging<br/>四阶段根因分析"]
J --> H
I -- 否 --> K["任务完成<br/>强制 commit 作检查点"]
K --> L{"还有任务?"}
L -- 是 --> F
L -- 否 --> M["code-review 请求/接收"]
M --> N["合并"]
O["using-git-worktrees<br/>全程提供隔离工作区"] -.-> F
P["subagent 派发<br/>主会话只做调度"] -.-> G
| Skill | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区活跃度 | 综合 |
|---|---|---|---|---|---|---|
| brainstorming | ★★★★★ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★★ | 4.7 |
| writing-plans | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★☆ | 4.4 |
| executing-plans | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★☆ | 4.4 |
| test-driven-development | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★☆ | ★★★★☆ | 4.2 |
| systematic-debugging | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ | 4.0 |
| using-git-worktrees | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | ★★★★★ | ★★★☆☆ | 3.5 |
（社区活跃度按仓库更新频率与社区讨论热度定性评估，未采信精确数字）
定位：在你描述完需求、模型准备动手的那一刻拦截它。它的 description（触发条件）大意是：当用户提出新功能、新项目或含糊的需求时使用。这是一个精心选择的触发面——够宽，宽到几乎所有编码会话的起点都会命中。
SKILL.md 的流程设计有三个值得逐行学的细节：
docs/plans/ 目录下），然后明确指示：接下来把这份文档交给 writing-plans。注意这句——这就是 Skill 之间接线的位置。文档既是交接物，也是下一阶段唯一的事实来源。短板：对明确的小改动，它可能显得啰嗦。好的用法是自己判断——需求一句话能说清时直接跳过。
定位：输入设计文档，输出实施计划。它的关键设计是对计划粒度的硬性规定：每个任务必须小到一次能完成、每个任务必须指明涉及哪些文件、验收方式是什么，并且禁止写“实现 XX 功能”这种无法验收的粗粒度任务。
更值得注意的是它对“计划为谁而写”的回答：计划不是给用户看的，是给未来一个失忆的工程师看的。SKILL.md 里反复强调，执行这份计划的可能是另开的一个全新会话——那个会话对本次对话一无所知，唯一能依赖的就是这份文档。所以计划里必须把背景、约束、每个任务的完整上下文全部写进去，不能写“按上面讨论的来”。
这个设计跟此前拆解过的 planning-with-files 是同一哲学：把状态写进文件，而不是指望会话记忆。区别在于 planning-with-files 管的是单个会话内的任务清单，writing-plans 管的是跨会话的工程交接。
定位：拿着计划文件逐任务执行。它的三条纪律构成了整个家族的“施工规范”：
配合 subagent 模式使用时，主会话只读计划、派发任务、验收结果，实现细节全部发生在子代理里——这就是对“上下文腐烂”的正面防御：主上下文永远只装调度信息，不装代码细节。
定位：强制红-绿-重构循环。SKILL.md 的写法在整个家族里最有攻击性，值得引用式转述几条：
对大模型来说这套约束的针对性极强：模型的自然倾向是“一口气写完实现再补测试”，而补出来的测试往往是照着实现写的——实现错了测试也跟着错，测试形同虚设。先红后绿从机制上杜绝了这一点：测试必须先在“无实现”状态下失败一次，才算数。
它同时给出了明确的否决条款（什么时候不该用）：改配置、改文案、纯样式调整，不必走全流程。这些“什么时候别用我”的段落是家族内每个成员的标配，下文细说。
定位：bug 出现时接管流程。它把调试拆成四个阶段，最反直觉也最有价值的是第一阶段：先复现，再阅读，禁止修改。流程明确禁止模型在读完代码前就开始改——因为模型的自然冲动是“看起来像是这里的问题，改一下试试”，而这种猜测试探在长会话里就是回滚地狱。
四个阶段大意是：复现并锁定最小失败用例 → 阅读相关代码、形成假设 → 用最小改动验证假设 → 确认根因后再修复、补回归测试。修完必须回到 TDD 的轨道上补一个防复发的测试，又一次家族内部接线。
定位：在动手前用 git worktree 开一个隔离目录，让实验性改动不污染主工作区。它功能最简单，SKILL.md 也最短，但补上了流水线的物理安全网：计划执行失败、实验被放弃时，主分支毫发无损。它同时也是对 Claude Code 内建 worktree 能力的教学——很多用户是从这个 Skill 第一次知道 git worktree 怎么用。
从 superpowers 身上可以提炼出一套“多 Skill 编排”的写法模式，这是它区别于单文件 Skill 的核心贡献：
法则一：阶段出口即下一阶段入口。 每个 Skill 的结尾都有一段“下一步”指引——brainstorming 出口交设计文档给 writing-plans，executing-plans 内嵌 TDD 与 debugging。接线不靠魔法，靠的就是一句“接下来读取/执行某某 Skill”，外加一个落盘的交接文件。任何想让 Skill 编排 Skill 的作者，模仿这一句就够。
法则二：每个 Skill 自带否决条款。 “何时使用”旁边永远有一栏“何时不适用”。这不只是省 token——它把触发判断权还给模型，让家族在用户跳过某个环节时依然能顺畅运转。单一职责的 Skill 可以不写，流水线成员必须写。
法则三：状态一律落盘，会话皆可死。 设计文档、计划文件、commit 检查点，三样东西保证任何一个会话爆炸，下一个会话都能从文件接力。这背后是对模型会话生命周期的悲观假设——不是“会不会断”，而是“何时断”。
法则四：分权，不许一个会话独裁。 设计者（brainstorming 会话）不施工，施工者（executing 会话）不改设计，实现者（subagent）不污染调度者（主会话）的上下文。superpowers 真正的产物不是某个功能，而是这套权力结构。
mindmap
root((superpowers))
想清楚阶段
brainstorming
一次一问
出口是设计文档
writing-plans
任务粒度硬约束
计划写给失忆者
动手阶段
executing-plans
逐任务commit
无权改计划
test-driven-development
先红后绿
禁止假设失败
救火阶段
systematic-debugging
先复现禁乱改
四阶段根因
基础设施
using-git-worktrees
物理隔离
subagent派发
上下文防腐
superpowers 以 Claude Code plugin 形式分发，先加作者的 marketplace 再安装：
# 添加 marketplace
claude plugin marketplace add obra/superpowers-marketplace
# 安装插件
claude plugin install superpowers@superpowers-marketplace
安装后重启 Claude Code，技能自动进入可用池。日常使用不需要背命令——直接描述需求，brainstorming 会按触发条件接管；也可以显式点名："用 superpowers 的流程帮我实现 XX"。具体安装方式可能随版本更新变化，以仓库 README 为准。
适用：多天的中型功能开发、需求还模糊的项目起点、容易上下文爆炸的长会话、想要强制测试纪律的团队。 不适用：五分钟的脚本小改（流程开销大于收益）、需要即兴探索的实验性玩耍、对提交粒度有严格外部规范限制的仓库。
单个 Skill 的天花板是“把一件事做好”，superpowers 示范了天花板之上的玩法：把十个好习惯焊成一条流水线，让每个 Skill 成为流程中的一站，用文件交接、用 commit 断点、用分权防篡改。今天回看，它更像 Claude Code 生态的“宪法文本”——后续大量技能库的编排结构都能在其中找到原型。对想写自己第一个多 Skill 工作流的开发者，没有比通读它的 SKILL.md 更好的教材。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。