Superpowers
定义与身份
Superpowers 在本文语境中，首先不是“增强模型能力”的代码插件，而是一套把工程纪律以文本形式分发给 AI 编程 Agent 的工作流系统。
它的最小核心单元是 Markdown skill 文件：每个 skill 都直接写明“当你遇到某类任务时，必须按什么流程执行”。这些约束不是辅助提示，而是流程性的行为规范。
原文强调，Superpowers 解决的问题不是 Agent“不会做”，而是 Agent“会偷步骤”。也就是说，它试图修正的不是能力缺口，而是执行纪律缺口。
在被引用的版本中，该项目在 GitHub 上于 2026 年 5 月、v5.1.0 附近达到 185,000 stars；文中同时指出，很多用户实际上只使用了其中一小部分能力，常见情况只是调用一次 /brainstorming 后就直接进入写代码。
核心思想：纪律优先于能力扩展
Superpowers 的核心判断是：AI 编程 Agent 缺的往往不是知识和代码生成能力，而是在压力、催促和长会话里持续遵守工程流程的能力。
例如，Agent 可能“知道应该写测试”，但在“先帮我快速跑一下”的语境里会跳过；也可能“知道调试应该先找根因”，但在“快帮我修一下”的指令下直接猜测并修改代码。
因此 Superpowers 的价值不在于提供新的工具调用，而在于把工程师本应遵守的设计、计划、调试、审查和收尾纪律，写成可以被 Agent 明确遵守的文本规则。
原文对此的概括非常直接：AI 编程工具最大的问题不是智力，而是纪律；而纪律可以用纯文本分发。
skill 体系与覆盖范围
文中提到当前插件包含 14 个 skill，大体分为三类：
- 测试类：
test-driven-development - 调试类：
systematic-debugging、verification-before-completion - 协作与工作流类：
brainstorming、writing-plans、executing-plans、subagent-driven-development、dispatching-parallel-agents、requesting-code-review、receiving-code-review、using-git-worktrees、finishing-a-development-branch、writing-skills、using-superpowers
从覆盖面看，Superpowers 不是单点工具，而是一套贯穿完整开发生命周期的工作流约束：
- 设计阶段：
brainstorming - 任务拆解阶段：
writing-plans - 实现阶段：
subagent-driven-development或executing-plans - 测试阶段：
test-driven-development - 调试阶段：
systematic-debugging - 提交前审查：
requesting-code-review - 结束与清理阶段：
finishing-a-development-branch - 会话失焦后的重置：
using-superpowers
因此它并不只管“写代码”，而是覆盖设计、调试、审查、验证、并行协作和收尾。
角色职责
作为实体，Superpowers 在工程实践中的职责可以概括为四层：
1. 约束 Agent 行为
它通过 hard gate 和阶段性规则，阻止 Agent 在缺乏设计批准、缺乏根因分析或缺乏验证结果时直接动手。
2. 固化中间产物
它要求设计阶段产出并提交 spec，计划阶段产出可执行计划，而不是只把意图停留在会话上下文里。这一点直接针对长会话中的上下文漂移。
3. 让执行过程可审查
通过细粒度任务、显式检查点、两轮审查和完成判定标准，把“AI 做事”变成一个能被人检查、暂停、确认和纠偏的过程。
4. 强制干净收尾
它把测试验证、分支处理、worktree 清理等经常被忽略的结尾步骤制度化，避免“任务看似做完，仓库却一地鸡毛”。
关键 skill 一：brainstorming
brainstorming 是文中最常被使用、也最常被误用的 skill。很多用户把它当成问答器或需求讨论器，回答几个问题后就直接让 Agent 开始实现，但原文强调这只走了前面很小一部分流程。
其最关键的约束是一个明确的 HARD-GATE：
在向用户展示设计且得到批准之前，不得调用任何实现类 skill，不得写任何代码，不得搭脚手架，也不得采取任何实现动作。
这意味着它不是“建议先想一下”，而是“没有设计批准，一行代码都不许写”。
brainstorming 的完整 9 步
文中列出完整流程为 9 步：
- 探索项目现状，包括查看文件、提交记录和文档。
- 如果问题涉及视觉内容，先提供可视化伴侣，并且以独立消息给出。
- 逐条提出澄清问题，每次只问一个。
- 给出 2 到 3 个设计方案，并说明推荐理由。
- 按章节展示设计方案，并对每一段都进行确认。
- 将设计写入
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md并提交。 - 自检 spec，扫描
TBD、TODO、内部矛盾、范围问题与歧义。 - 让用户审阅 spec 文件。
- 移交给
writing-plans。
文中指出，最常被跳过的是第 6 到第 8 步，即“把设计真正落成文档、检查其质量并让用户基于文件审阅”。一旦这几步被省略，执行阶段就会重新退化为依赖会话记忆的临场发挥。
brainstorming 的边界
brainstorming 的终态只有一个：移交给 任务颗粒化计划|writing-plans。
原文特别说明，它不允许在完成设计后跳去别的实现类能力，也不允许绕过计划阶段直接编码。这个设计意图是强制形成“设计 → 计划 → 实现”的链条，而不是让 Agent 在中途跳流程。
简单任务也不能省
一个反直觉但被原文反复强调的边界是：越觉得任务简单，越不能跳过设计流程。
原因是简单任务里最容易藏着未说出的假设；这些隐含假设恰恰是返工来源。即便只是配置修改，也必须走完整流程，只是 spec 可以很短、只有几句话，但不能没有。
文中给出一个经验对比：一次重构任务，第一次完整走完 9 步大约用了 40 分钟，感觉偏慢；但之后执行几乎没有返工。相比之下，直接上手虽然在前期省了约 30 分钟，后面却改了 3 轮，总时间反而多了 2 小时。
关键 skill 二：systematic-debugging
根因调试 在 Superpowers 中对应的核心 skill 是 systematic-debugging。原文认为这是整套体系里最被低估的能力之一。
它针对的，是 Agent 和很多工程师都容易陷入的“猜测式修 bug”模式：看到报错，先猜一个原因，改一下；没好，再猜第二个；如此循环，越改越乱。
其铁律是：
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
也就是：没有根因调查，就不允许修复。
四阶段流程
systematic-debugging 必须按顺序经历四个阶段，前一阶段未完成不得进入下一阶段：