# 一个Skill不够用？superpowers把十几个Skill焊成一条流水线 ## 概述 绝大多数 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 里能看到的“先侦察再动手”“逐任务提交”等条款，往上追溯多半有它的影子。 它解决的是大模型的两个老毛病： 1. **过早动手**。模型拿到需求的第一反应是直接写代码，需求模糊时尤其如此——它会替你猜，猜错就返工。 2. **上下文腐烂**。一个长会话里又读文件又写代码又调试，主上下文被细节塞满后，模型开始忘记最初的约束，越改越错。 superpowers 的答案不是调参、不是写更长的系统提示词，而是**把流程拆成一串 Skill，每个 Skill 只负责一个阶段，完成时把接力棒交给下一个**。这本质上是工程管理，不是提示词工程。 ```mermaid flowchart TD A["模糊想法"] --> B["brainstorming
逐问逼出设计决策"] B --> C["设计文档
docs/plans/ 下落盘"] C --> D["writing-plans
设计拆成分阶段计划"] D --> E["计划文件
带勾选框的任务清单"] E --> F["executing-plans
逐任务执行"] F --> G["每个任务内"] G --> H["test-driven-development
红-绿-重构循环"] G --> I{"出 bug?"} I -- 是 --> J["systematic-debugging
四阶段根因分析"] J --> H I -- 否 --> K["任务完成
强制 commit 作检查点"] K --> L{"还有任务?"} L -- 是 --> F L -- 否 --> M["code-review 请求/接收"] M --> N["合并"] O["using-git-worktrees
全程提供隔离工作区"] -.-> F P["subagent 派发
主会话只做调度"] -.-> 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** | （社区活跃度按仓库更新频率与社区讨论热度定性评估，未采信精确数字） ## 核心拆解：六个成员如何接力 ### 1. brainstorming —— 全流水线的守门员 **定位**：在你描述完需求、模型准备动手的那一刻拦截它。它的 description（触发条件）大意是：当用户提出新功能、新项目或含糊的需求时使用。这是一个精心选择的触发面——够宽，宽到几乎所有编码会话的起点都会命中。 SKILL.md 的流程设计有三个值得逐行学的细节： - **一次只问一个问题**。它明确禁止模型一口气抛出五个澄清问题让用户填表，而是逐个推进，每个回答都会收窄下一步的问题空间。这是对真实访谈技巧的移植：连环提问会让用户敷衍，单题推进能逼出真实偏好。 - **探测“已有方案”**。流程里专门有一段要求先确认用户是否已有倾向的实现方式、参考项目或must-not-do清单，避免模型自作主张选型。 - **出口是一份文档，不是代码**。头脑风暴的终点是写一份设计文档落盘（`docs/plans/` 目录下），然后明确指示：接下来把这份文档交给 writing-plans。注意这句——**这就是 Skill 之间接线的位置**。文档既是交接物，也是下一阶段唯一的事实来源。 短板：对明确的小改动，它可能显得啰嗦。好的用法是自己判断——需求一句话能说清时直接跳过。 ### 2. writing-plans —— 把散文变清单 **定位**：输入设计文档，输出实施计划。它的关键设计是**对计划粒度的硬性规定**：每个任务必须小到一次能完成、每个任务必须指明涉及哪些文件、验收方式是什么，并且禁止写“实现 XX 功能”这种无法验收的粗粒度任务。 更值得注意的是它对“计划为谁而写”的回答：计划不是给用户看的，是**给未来一个失忆的工程师看的**。SKILL.md 里反复强调，执行这份计划的可能是另开的一个全新会话——那个会话对本次对话一无所知，唯一能依赖的就是这份文档。所以计划里必须把背景、约束、每个任务的完整上下文全部写进去，不能写“按上面讨论的来”。 这个设计跟此前拆解过的 planning-with-files 是同一哲学：**把状态写进文件，而不是指望会话记忆**。区别在于 planning-with-files 管的是单个会话内的任务清单，writing-plans 管的是跨会话的工程交接。 ### 3. executing-plans —— 检查点机器 **定位**：拿着计划文件逐任务执行。它的三条纪律构成了整个家族的“施工规范”： - **一次只做一个任务**，做完打勾，与计划文件同步； - **每个任务完成必须 commit**。这不是洁癖——commit 是廉价检查点，后续任何一步走歪，回滚的单位是“一个任务”而不是“一整次会话”； - **遇到计划与现实的冲突，停下来报告，不要现场自由发挥**。执行者无权修改计划，这是刻意设计的权责分离：设计与施工分权，防止模型边做边悄悄改需求。 配合 subagent 模式使用时，主会话只读计划、派发任务、验收结果，实现细节全部发生在子代理里——这就是对“上下文腐烂”的正面防御：主上下文永远只装调度信息，不装代码细节。 ### 4. test-driven-development —— 家族里最“凶”的一份 **定位**：强制红-绿-重构循环。SKILL.md 的写法在整个家族里最有攻击性，值得引用式转述几条： - **没有失败的测试，就不许写任何实现代码**。这是第一条戒律，用加粗和重复强调； - 红灯阶段：写一个测试，运行，**亲眼确认它失败**——不许假设它会失败； - 绿灯阶段：写**刚好够让测试通过**的代码，禁止顺手多做； - 重构阶段：代码行为被测试保护着，此时才允许清理。 对大模型来说这套约束的针对性极强：模型的自然倾向是“一口气写完实现再补测试”，而补出来的测试往往是照着实现写的——实现错了测试也跟着错，测试形同虚设。先红后绿从机制上杜绝了这一点：测试必须先在“无实现”状态下失败一次，才算数。 它同时给出了明确的否决条款（什么时候不该用）：改配置、改文案、纯样式调整，不必走全流程。这些“什么时候别用我”的段落是家族内每个成员的标配，下文细说。 ### 5. systematic-debugging —— 禁止“试试看” **定位**：bug 出现时接管流程。它把调试拆成四个阶段，最反直觉也最有价值的是第一阶段：**先复现，再阅读，禁止修改**。流程明确禁止模型在读完代码前就开始改——因为模型的自然冲动是“看起来像是这里的问题，改一下试试”，而这种猜测试探在长会话里就是回滚地狱。 四个阶段大意是：复现并锁定最小失败用例 → 阅读相关代码、形成假设 → 用最小改动验证假设 → 确认根因后再修复、补回归测试。修完必须回到 TDD 的轨道上补一个防复发的测试，又一次家族内部接线。 ### 6. using-git-worktrees —— 最小但最实用 **定位**：在动手前用 `git worktree` 开一个隔离目录，让实验性改动不污染主工作区。它功能最简单，SKILL.md 也最短，但补上了流水线的物理安全网：计划执行失败、实验被放弃时，主分支毫发无损。它同时也是对 Claude Code 内建 worktree 能力的教学——很多用户是从这个 Skill 第一次知道 `git worktree` 怎么用。 ## 设计模式提炼：家族式 Skill 的四条接线法则 从 superpowers 身上可以提炼出一套“多 Skill 编排”的写法模式，这是它区别于单文件 Skill 的核心贡献： **法则一：阶段出口即下一阶段入口。** 每个 Skill 的结尾都有一段“下一步”指引——brainstorming 出口交设计文档给 writing-plans，executing-plans 内嵌 TDD 与 debugging。接线不靠魔法，靠的就是一句“接下来读取/执行某某 Skill”，外加一个落盘的交接文件。任何想让 Skill 编排 Skill 的作者，模仿这一句就够。 **法则二：每个 Skill 自带否决条款。** “何时使用”旁边永远有一栏“何时不适用”。这不只是省 token——它把触发判断权还给模型，让家族在用户跳过某个环节时依然能顺畅运转。单一职责的 Skill 可以不写，流水线成员必须写。 **法则三：状态一律落盘，会话皆可死。** 设计文档、计划文件、commit 检查点，三样东西保证任何一个会话爆炸，下一个会话都能从文件接力。这背后是对模型会话生命周期的悲观假设——不是“会不会断”，而是“何时断”。 **法则四：分权，不许一个会话独裁。** 设计者（brainstorming 会话）不施工，施工者（executing 会话）不改设计，实现者（subagent）不污染调度者（主会话）的上下文。superpowers 真正的产物不是某个功能，而是这套**权力结构**。 ```mermaid mindmap root((superpowers)) 想清楚阶段 brainstorming 一次一问 出口是设计文档 writing-plans 任务粒度硬约束 计划写给失忆者 动手阶段 executing-plans 逐任务commit 无权改计划 test-driven-development 先红后绿 禁止假设失败 救火阶段 systematic-debugging 先复现禁乱改 四阶段根因 基础设施 using-git-worktrees 物理隔离 subagent派发 上下文防腐 ``` ## 安装与使用 superpowers 以 Claude Code plugin 形式分发，先加作者的 marketplace 再安装： ```bash # 添加 marketplace claude plugin marketplace add obra/superpowers-marketplace # 安装插件 claude plugin install superpowers@superpowers-marketplace ``` 安装后重启 Claude Code，技能自动进入可用池。日常使用不需要背命令——直接描述需求，brainstorming 会按触发条件接管；也可以显式点名："用 superpowers 的流程帮我实现 XX"。具体安装方式可能随版本更新变化，以仓库 README 为准。 **适用**：多天的中型功能开发、需求还模糊的项目起点、容易上下文爆炸的长会话、想要强制测试纪律的团队。 **不适用**：五分钟的脚本小改（流程开销大于收益）、需要即兴探索的实验性玩耍、对提交粒度有严格外部规范限制的仓库。 ## 推荐排行榜 - **最值得优先体验**：brainstorming——单独安装这一个就能改变模型“拿到需求就冲”的习惯； - **对团队最有价值**：test-driven-development——把测试纪律从“提醒”变成“流程”； - **最容易被低估**：writing-plans——“计划写给失忆的工程师”这一条设计值得所有写文档的人抄； - **组合增益最大**：executing-plans + subagent 派发——长会话防腐的完整答案。 ## 结语：Skill 的尽头是流程 单个 Skill 的天花板是“把一件事做好”，superpowers 示范了天花板之上的玩法：把十个好习惯焊成一条流水线，让每个 Skill 成为流程中的一站，用文件交接、用 commit 断点、用分权防篡改。今天回看，它更像 Claude Code 生态的“宪法文本”——后续大量技能库的编排结构都能在其中找到原型。对想写自己第一个多 Skill 工作流的开发者，没有比通读它的 SKILL.md 更好的教材。 ## 参考来源 1. [obra/superpowers](https://github.com/obra/superpowers) — 本文主体拆解对象，各 Skill 的 SKILL.md 原文所在仓库 2. [obra/superpowers-marketplace](https://github.com/obra/superpowers-marketplace) — 插件 marketplace 仓库，安装命令来源 3. [blog.fsck.com](https://blog.fsck.com) — 作者 Jesse Vincent 的博客，2025 年 10 月前后连载其 Claude Code 工作流系列文章 4. [anthropics/skills](https://github.com/anthropics/skills) — Anthropic 官方 Skills 仓库，官方插件与 Skill 编写规范参照 5. [skills.sh](https://skills.sh) — Skills 生态热门榜，用于观察 superpowers 系技能的传播情况 > [!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 等场景全覆盖。