Superpowers 系列（总览）：整体设计、目标与价值
如果直接从某个 Skill 开始读 Superpowers，很容易把它看成一组“好用的提示词模板”：先 brainstorm，再写 plan，再 TDD，再 code review。这个理解不算错，但会低估它真正的设计野心。
Superpowers 更像是一套安装在编码 Agent 身上的软件开发方法论。它的目标不是让 Agent 多知道几个技巧，而是改变 Agent 在关键时刻的默认行为：不要一听到目标就写代码，不要用自己的理解替代用户确认，不要用计划标题替代可执行契约，不要用完成声明替代新鲜证据，也不要让子代理共享一团混乱上下文。
这篇总览不从某个 Skill 的用法切入，而是先回答三个更上层的问题：Superpowers 想控制什么，为什么这些控制会让 Agent 更稳定，后续文章会如何按行为机制继续拆开分析。
Superpowers 要解决的问题
编码 Agent 的问题通常不是“不会做”。很多时候，它的问题是太快进入行动状态。
一个没有流程约束的 Agent 往往会这样工作：
收到需求 -> 自己解释目标 -> 直接读代码 -> 尝试实现 -> 补测试 -> 宣布完成这条路径看起来积极，实际隐藏了几个工程风险：
- 目标解释没有外化，用户不知道 Agent 到底理解成了什么。
- 设计没有冻结，后续实现会不断吸收新假设。
- 计划粒度太粗，执行者仍然需要现场判断大量细节。
- 验证发生太晚，测试可能只是为已有实现背书。
- 多 Agent 协作时，上下文、责任和审查边界容易混在一起。
- 交付收尾时，merge、PR、worktree 清理等动作可能越过用户决策。
Superpowers 的设计目标，就是把这些隐性的默认动作改成显性的工程门禁。它不依赖 Agent “自觉谨慎”，而是把谨慎拆成一组可触发、可检查、可恢复的行为。
它的整体架构：入口、方法链和证据门
Superpowers 的 README 把它描述为一套基于可组合 Skills 和初始指令的软件开发方法。README 里的 Basic Workflow 把 brainstorming、worktree、plan、执行、TDD、review 和 branch finishing 串成连续步骤；下图把这条序列抽象成三层控制结构。
第一层是入口层。session-start hook 会把 using-superpowers 注入会话上下文。using-superpowers 的职责不是完成某个业务任务，而是要求 Agent 在任何响应和行动前先检查是否有相关 Skill。它把“是否使用方法”变成入口门禁。
第二层是方法链。Superpowers 的基本工作流从 brainstorming 开始，把粗略想法变成可批准设计；再通过 using-git-worktrees 隔离工作空间；然后由 writing-plans 生成低上下文执行者也能跟随的计划；最后进入 subagent-driven-development 或 executing-plans 执行。
第三层是证据层。test-driven-development、systematic-debugging、requesting-code-review、receiving-code-review 和 verification-before-completion 都在控制同一件事：不要让 Agent 用“我觉得已经好了”替代可复核证据。
这三层共同形成一个闭环：入口层决定什么时候调用方法，方法链决定下一步怎么推进，证据层决定什么时候允许宣称完成。
它的价值不是“更多步骤”，而是更少漂移
Superpowers 会让开发过程看起来多了很多步骤：先问、先设计、先批准、先计划、先写失败测试、先审查、先验证。表面看这是成本，实际它换来的是抗漂移能力。
Agent 开发最怕的不是慢一点，而是方向漂移后继续高速前进。Superpowers 用四类约束降低这种风险。
| 约束 | 控制的默认行为 | 产生的价值 |
|---|---|---|
| 入口约束 | Agent 直接回答或直接行动 | 先选择方法，再处理任务 |
| 意图约束 | Agent 把推理当成确认 | 用户先批准设计，再进入实现 |
| 执行约束 | Agent 按模糊计划自由发挥 | 用 plan、brief、ledger 限定局部任务 |
| 证据约束 | Agent 用语言声明完成 | 用测试、审查和验证支撑完成判断 |
这就是 Superpowers 稳定的原因。它不是让模型少犯错，而是在模型容易犯错的位置设置拦截器。每个 Skill 都在反制一种常见的 Agent 合理化：这个任务很简单、我先改一点、测试等会儿补、review 我自己看就行、命令刚刚跑过应该没问题。
它为什么适合软件开发 Agent
软件开发和普通问答不同。代码会留下状态，状态会影响后续任务；一次错误修改可能继续被后续 Agent 当成事实。Superpowers 的设计抓住了这个特点。
它把软件开发拆成四类可管理对象：
- 设计对象：用户想要什么，哪些方案被接受，哪些选择被拒绝。
- 执行对象：计划分成哪些任务，每个任务改哪些文件，如何验证。
- 证据对象：哪些测试先失败后通过，哪些 review 发现已处理，哪些命令是新鲜结果。
- 交付对象：当前分支如何收尾，是否合并、开 PR、保留或丢弃。
这些对象让 Agent 不再只靠上下文窗口工作。设计、计划、ledger、review package 和验证结果都在把“聊天里的意图”转成“工程里的状态”。这也是 Superpowers 能支撑较长时间自主执行的关键。
这套系列怎么读
后续文章不会按 Skill 名称写说明书，而是按“它到底控制了哪种行为习惯”来拆。这样更容易看清它的架构价值。
| 章节 | 主题 | 主要回答的问题 |
|---|---|---|
| 01 | 行为控制面 | Superpowers 如何从 Skills 集合变成 Agent 行为控制面 |
| 02 | 入口门禁 | 为什么 Skill 发现要发生在任何行动之前 |
| 03 | 意图冻结 | 为什么 brainstorm 和用户批准要早于实现 |
| 04 | 计划契约 | 为什么 plan 要写给低上下文执行者，而不是写给自己看 |
| 05 | 上下文治理 | subagent、task brief、ledger 和 review loop 如何治理多 Agent 执行 |
| 06 | 证据门禁 | TDD、debugging、verification 如何防止“完成幻觉” |
| 07 | 审查反力 | reviewer 为什么既要独立，又不能被盲从 |
| 08 | 交付边界 | worktree、分支收尾和不可逆操作如何保护交付决策 |
| 09 | 方法自举 | writing-skills 如何把失败经验沉淀为可复用方法 |
| 10 | 边界对照 | Superpowers 这种方法链和更正式流程的边界在哪里 |
如果只想快速理解整体，先读本文和第 01 篇。第 01 篇会把“行为控制面”讲透。之后可以按自己的关注点跳读：关心需求前置就看 02、03、04；关心多 Agent 执行就看 05、07；关心质量和交付就看 06、08；关心方法如何持续演化就看 09；关心它和更正式流程的区别，就看第 10 篇。
总结
Superpowers 的核心价值可以压缩成一句话：它把 Agent 的聪明放进一条不容易漂移的软件开发方法链。
这条方法链不是普通提示词，也不是重型项目管理系统。它介于二者之间：比提示词更硬，因为它有触发规则、门禁、反模式和证据要求；比流程系统更轻，因为它主要控制 Agent 在当前任务里的工程习惯。
理解这一点后，再看每个 Skill，就不会只看到“某个阶段该做什么”。你会看到一套更底层的行为设计：它在改变 Agent 的起手方式、确认方式、执行方式、验证方式和交付方式。
参考资料：
下面的源码链接固定到同一提交版本，避免后续仓库变化影响阅读和复核。
- Superpowers README
- using-superpowers/SKILL.md
- brainstorming/SKILL.md
- subagent-driven-development/SKILL.md
系列导航：