alookdlna投屏t
17.07MB · 2026-04-04
Superpowers 不是某一个很强的 skill，它更像一套给编码 Agent 用的流程规矩。看完仓库后，我的感觉很明确：它关心的重点不是“再把模型抬高一点”，而是“别让它上来就乱写”。
核心思路可以压成 4 句：
SessionStart Hook 在每次会话开头塞进一条规则：先判断 skill 适不适用，再做别的using-superpowers 把“先找流程，再执行”变成默认动作从实现上看，这套东西其实挺省力的：
Hook + Skills + 少量 commands + 一个 reviewer agent这也是它和 GSD 那类更重的系统最明显的区别。
如果只用一句话概括，我会这么说：
Superpowers 在 README 里的自我定义其实已经说得很直白：
这句话拆开看，会更清楚。
它不是那种“贴一段神奇 system prompt，模型立刻开窍”的东西。
它有：
skills/：14 个 skillhooks/：会话启动注入逻辑commands/：少量显式命令入口agents/：辅助 reviewer agent.claude-plugin/ / .cursor-plugin/ / .codex/ / .opencode/：平台适配所以它已经不只是几篇文档，而是一套围绕 skill 机制组织起来的跨平台 workflow 包。
它没有像很多 Agent 系统一样做这些事情：
.planning/STATE.md它还是把大量控制逻辑留在 skill 文本里。
所以它更像：
而不是：
Superpowers 里最显眼的词不是 “speed”，而是：
它想解决的问题也很具体：
基于当前本地快照，Superpowers 的结构大致是：
superpowers/
├── skills/ # 14 个核心 skills
├── hooks/ # 会话注入与平台 hook 配置
├── commands/ # brainstorm / write-plan / execute-plan
├── agents/ # code-reviewer agent
├── .claude-plugin/
├── .cursor-plugin/
├── .codex/
├── .opencode/
└── README.md
如果按运行时去理解，大概是这样：
flowchart TD
A["用户请求"] --> B["SessionStart Hook"]
B --> C["using-superpowers"]
C --> D["判断是否需要流程 skill"]
C --> E["判断是否需要质量 gate"]
D --> F["具体 skill"]
E --> F
F --> G["必要时派发子 agent"]
F --> H["必要时调用 command / 工具"]
这里关键的不是 skill 有 14 个，而是谁拿着入口控制权：
这一点决定了后面的整套行为。
入口就在这两个位置：
hooks/session-startskills/using-superpowers/SKILL.mdsession-start 做的事很朴素：
using-superpowers/SKILL.mdhookSpecificOutput.additionalContextadditional_context它不是塞一段摘要，而是把 完整的入口 skill 放进会话里。
原因也不复杂。Superpowers 不只是想提醒一句：
它要注入的是一整套上游规则：
说白了，它想先把玩法讲清楚，再让 Agent 开始干活。
很多 skill 系统最后没跑起来，不是因为内容写得差，而是模型总会这样：
Superpowers 的做法很直接：这些都算违规，不给你留“先随便看两眼”的空间。
所以 SessionStart Hook 虽然代码不多，但位置非常关键。它卡在最前面，专门管第一步。
如果你想从“控制权”这个角度看它，Hook 的位置基本是这样的：
sequenceDiagram
participant U as 用户
participant H as SessionStart Hook
participant S as using-superpowers
participant A as Agent 主会话
U->>A: 发起会话 / 提问题
H->>A: 注入 using-superpowers 全文
A->>S: 先按元规则判断 skill
S-->>A: 给出 skill 使用顺序与约束
A->>U: 再开始真正响应
using-superpowers 不处理业务，它管的是更前面的东西：
最著名的一句是：
这条规则表面看很夸张，实际上是在对抗模型最常见的失败模式：
在 Superpowers 看来，这些都属于绕流程走。
using-superpowers 规定了两个顺序：
甚至连：
这些都得往后排，先过 skill check。
比如：
brainstormingsystematic-debugging这一步很关键，因为它把“先定流程”放到了“立刻行动”前面。
using-superpowers 明确写了优先级：
这一点我挺认同。很多流程系统的问题不在流程本身，而在于它总想压过用户。
Superpowers 没往这个方向走。它很强势，但边界也写得清楚：
README 里那条主流程我觉得写得很好，把仓库里的 skill 串起来，大概就是下面这条线：
flowchart TD
A["用户提出需求 / 问题"] --> B["using-superpowers"]
B --> C["brainstorming"]
C --> D["using-git-worktrees"]
D --> E["writing-plans"]
E --> F{"执行方式"}
F --> G["subagent-driven-development"]
F --> H["executing-plans"]
G --> I["TDD / Review / Verification"]
H --> I
I --> J["finishing-a-development-branch"]
K["systematic-debugging"] -. 出现异常时插入 .-> I
这条链最有意思的地方有两个，也正是这两个地方，让它和“想到就写”的 Agent 工作流拉开了距离。
用户一上来提需求，不是直接：
而是先：
它默认的工作方式其实就是：
对 Superpowers 来说，完成不等于：
完成至少要经过：
换句话说，在这套系统里，“看起来差不多”不算完成。
Superpowers 对这个原则的处理挺克制。它没有一路冲到“全部工具化”，也没停在“全靠 prompt 自觉”。
和 GSD 这类系统不同，Superpowers 没有把大量流程逻辑外化成：
相反，它把不少规则放在文本层。
例如：
这些还是靠 skill 来约束。
但它也不是纯文档，还是做了三层加固：
用 SessionStart 把元规则稳定注入。
每个 skill 都有：
namedescription这比松散文档强很多。
subagent-driven-development 和 dispatching-parallel-agents 明确要求：
这已经不是简单的“提示词写得更细”了，而是在主动管上下文边界。
我会把 Superpowers 放在一个中间位置。
它没有重到 GSD 那个级别，但也绝对不是“放一堆 skill，触发到了算运气”。更贴切一点的说法是：它用 hook 管入口，用 skill 管流程，用子 agent 管隔离。
如果把这个位置画出来，大概是这样：
flowchart LR
A["纯 Prompt 套路"] --> B["Superpowers"]
B --> C["重型 Workflow Engine"]
A1["优点：轻、快"] --- A
A2["缺点：不稳定"] --- A
B1["优点：流程清晰、约束强"] --- B
B2["缺点：仍依赖模型遵循"] --- B
C1["优点：确定性强、状态完整"] --- C
C2["缺点：重、复杂、学习成本高"] --- C
常驻的不是所有 skill，而只有 using-superpowers。
这样做有几个很实际的好处：
它的结构其实很简单：
常驻层
└── using-superpowers
按需层
└── 具体 process / quality gate skills
这就是很典型的 index + on-demand load。
writing-skills 里把这个原则写得很细，甚至给它起了名字：
核心思想是：
description 只说明什么时候该用原因也很现实：
如果 description 把流程都讲完了，模型可能直接照 description 做，而不去读 skill 全文。
这里能看出来，它不是随手写说明文，而是在认真处理检索和触发稳定性。
subagent-driven-development 和 dispatching-parallel-agents 的共同核心是：
这一点我很认同。上下文不是越多越好，准一点反而更有用。
Superpowers 里和多 agent 最相关的有两个 skill：
subagent-driven-developmentdispatching-parallel-agents这两个 skill 对应的是两种不同的并行方式。
它的主模式是：
flowchart TD
A["Controller"] --> B["读取 Plan"]
B --> C["派发 Implementer"]
C --> D["Spec Reviewer"]
D --> E{"规格通过？"}
E -- 否 --> C
E -- 是 --> F["Code Quality Reviewer"]
F --> G{"质量通过？"}
G -- 否 --> C
G -- 是 --> H["标记 Task 完成"]
H --> I{"还有任务？"}
I -- 是 --> C
I -- 否 --> J["Final Code Review"]
这个设计的重点不在“多”，而在分工：
而且 review 顺序不能反：
这个 skill 管的是另一类场景：
它强调的不是实现，而是 独立问题域拆分：
条件是：
所以这种并行更像几个调查组同时查不同方向，不是装配线。
和 GSD 那种 wave 式并行相比，Superpowers 这边更轻：
所以它的多 agent 更接近：
我觉得 Superpowers 最值钱的部分，不是 skill 数量，而是它真把几条工程规则写成了硬约束。
test-driven-development 的核心不是“推荐先写测试”，而是：
而且它非常强硬：
一般团队文档很少写这么死，但它这里就是这么定的。
systematic-debugging 直接规定：
它把调试拆成 4 阶段：
比起“先改一把试试”，这套做法显然要稳很多。
verification-before-completion 规定：
这个 skill 有意思的地方不在技术细节，而在它专门管“别乱报喜”：
它就是在防一件事：为了显得高效，提前宣布完成。
requesting-code-review 和 receiving-code-review 一起构成了 review 的正反面协议。
前者要求：
后者要求：
这两个 skill 放在一起看，处理了两个常见问题：
下面这部分我不想只做功能罗列，而是想把每个 skill 放回整条链路里看：它拦什么问题，和别的 skill 怎么接上。
先给一张总图，读完这张图再看后面的逐项拆解，会轻松很多：
flowchart TD
A["using-superpowers"] --> B["brainstorming"]
B --> C["using-git-worktrees"]
C --> D["writing-plans"]
D --> E["subagent-driven-development"]
D --> F["executing-plans"]
E --> G["test-driven-development"]
E --> H["requesting-code-review"]
E --> I["verification-before-completion"]
F --> G
F --> I
J["systematic-debugging"] -. 异常时介入 .-> E
J -. 异常时介入 .-> F
K["dispatching-parallel-agents"] -. 独立问题并行时介入 .-> J
E --> L["finishing-a-development-branch"]
F --> L
M["writing-skills"] -. 用于扩展整个系统 .-> A
在逐个展开之前，先给一个总表：
| Skill | 类型 | 主要作用 | 在主链路中的位置 |
|---|---|---|---|
using-superpowers | 元 skill | 定义 skill 使用规则 | 会话入口 |
brainstorming | 流程 skill | 把想法变成设计和 spec | 实现前 |
using-git-worktrees | 环境 skill | 创建隔离工作区 | 设计后、实现前 |
writing-plans | 流程 skill | 把 spec 变成可执行计划 | 设计后 |
subagent-driven-development | 执行 skill | 推荐执行引擎，task + review loop | 实现阶段 |
executing-plans | 执行 skill | 无法高质量用 subagent 时的 fallback | 实现阶段 |
test-driven-development | 质量 gate | 强制 RED-GREEN-REFACTOR | 实现阶段 |
requesting-code-review | 质量 gate | 主动发起 review | task / feature 完成后 |
receiving-code-review | 质量 gate | 正确接收并处理 review 反馈 | 收到反馈时 |
systematic-debugging | 流程 skill | 根因导向调试 | 出现 bug / 异常时 |
verification-before-completion | 质量 gate | 无证据不宣称完成 | 结束前 |
dispatching-parallel-agents | 并行 skill | 独立问题域并行调查 | 多故障并行时 |
finishing-a-development-branch | 收尾 skill | merge / PR / 保留 / 丢弃分支 | 实现完成后 |
writing-skills | 元开发 skill | 用 TDD 思维创建新 skill | 扩展系统时 |
这个 skill 不做业务，它只做一件前置工作：先把整套系统的使用顺序钉住。没有它，后面的 13 个 skill 很容易沦为“想起来才用”的说明书。
它最狠的地方就是 1% 规则。只要有一点可能适用，就先调 skill，不许靠感觉跳过去。再加上 process skill 优先、用户指令优先级更高，这个入口层就算是搭稳了。
brainstorming 是所有创造性任务的第一站。新功能、重构、交互改造、架构调整，这些都不能直接写。
它卡住的是几种很常见的抢跑行为：
这里我最喜欢的有三条：
docs/superpowers/specs/这就不是“先聊聊需求”那么简单了，而是把需求分析、方案比较和确认边界收成了一个标准动作。
很多人会把 git worktree 当小技巧用，但 Superpowers 不是这个态度。它把 worktree 放进主流程里，意思很明确：实现前先隔离环境。
它主要防三件事：
细节上也不含糊。目录怎么选有顺序，项目内目录要先 git check-ignore，建完 worktree 还得做 setup 和 baseline test。流程走到这里，环境已经不是“顺手整理一下”，而是交付前提的一部分。
writing-plans 干的活，是把 spec 继续往下压一层，压到可以交给执行者直接开干。
很多计划文档其实没法执行，常见问题就那几个：
TODO / TBD / edge casesSuperpowers 这里要求挺硬：每一步控制在 2 到 5 分钟；写代码步骤就给出实际代码；验证步骤就给出命令和预期。它默认执行者上下文不多，也不会替你补脑，所以计划必须写得低歧义、可复制、可验证。这一点非常工程化。
如果说前面几个 skill 负责把路铺平，那 subagent-driven-development 就是正式开工的主引擎。
它不鼓励主会话自己一头扎进去写，而是拆成几种角色：
重点不只是“用了子 agent”，而是 review 顺序不能乱。先问做没做到，再问写得好不好。这个顺序很像真实工程团队里的工作流，能明显减少那种“代码挺漂亮，但方向写偏了”的问题。
这个 skill 是兜底方案。平台能力不够，或者当前场景不适合用 subagent，就退回到单会话按 plan 执行。
但即便是 fallback，它也没有放松要求：
finishing-a-development-branch所以它只是换了执行载体，没有把流程松掉。
test-driven-development 在这里不是装饰品，而是真门槛。仓库里写得很清楚：没有先失败的测试，就不该出现生产代码。
这条线一旦拉起来，几个坏习惯基本都会被挡住：
它的流程大家都熟，RED -> Verify RED -> GREEN -> Verify GREEN -> REFACTOR。但熟是一回事，真写进系统又是另一回事。Superpowers 的意思很明确：实现的合法入口，就是那个先失败过的测试。
很多 Agent 工作流的问题，不在不会 review，而在 review 来得太晚。全做完了再一起看，代价会高很多。
requesting-code-review 要求在关键节点主动发起 review，而且 review 范围要靠 git SHAs 这种硬边界来定。reviewer 只拿必要上下文，不把主会话的噪音一股脑倒过去。
这样做的好处很实际：review 不再是最后礼貌性补一刀，而是 task 流程本身的一环。
这个 skill 我觉得很少见，也很有价值。很多系统只管“怎么发起 review”，不太管“收到 review 后别犯蠢”。
它盯住的是三种反应：
所以它要求的顺序是：先理解，再验证，最后决定是实施还是 push back。甚至还把 “You’re absolutely right!” 这种社交化台词单独拎出来反对。这个味道很真实，因为它防的不是技术错误，而是工程讨论里常见的失真。
systematic-debugging 统一接管所有 bug 和异常场景。这里最核心的一条规则是：别在没找到根因前就急着修。
它把调试拆成 4 步：
更见功夫的是后面的细节要求。多组件系统先加诊断埋点，深调用链问题要反向 trace data flow，三次 fix 还不对就别再硬补丁了，开始怀疑架构。能把这些写进 skill，说明作者对调试这件事是有实战焦虑的。
这个 skill 专门管“别太早宣布胜利”。
它的要求很简单，也很烦人，但确实有用：
它不是为了多跑一遍测试，而是为了把“我觉得差不多了”挡在门外。很多 Agent 最大的问题不是不会做，而是太爱提前收工。
dispatching-parallel-agents 不是用来炫并发的。它只在一种情况下有价值：问题域彼此独立，串行查太浪费时间。
适用条件也很克制：
所以它更像多组人同时调查不同方向，而不是一个自动化大流水线。Superpowers 的并行能力就到这里，不贪。
很多系统前面都讲得很细，最后收尾反而很随意。Superpowers 没把这一段省掉。
finishing-a-development-branch 主要处理这些脏活：
它的流程也很朴素：先验证，再给用户几个清楚的选项，然后按选项处理后续。收尾这一步被单独拿出来，我觉得是对的，因为很多工程事故其实就出在“最后随手一弄”。
最后这个 skill 很有意思，它不是用来做业务，而是用来继续造 skill。
仓库在这里给出的判断我很认同：写 skill 这件事，本身也应该按 TDD 来做。先看 Agent 没有 skill 时怎么失败，再写最小 skill 去修，再补掉暴露出来的新漏洞。
它解决的问题也很现实：
description 写得不可检索，结果永远触发不到做到这一步，Superpowers 就不只是“会用 skill”，而是在认真处理这套系统怎么长出来、怎么继续维护。
除了 14 个 skill，当前仓库里还有 3 类辅助结构。
当前有 3 个 command 文件：
brainstorm.mdwrite-plan.mdexecute-plan.md这说明它现在已经不是只能靠自动路由，部分平台也能手动点名走流程。
agents/code-reviewer.md 是一个 reviewer agent prompt。
它负责的不是笼统 code review，而是：
这说明它的 review 不是“顺便看看”，而是专门切了一个角色出来做。
hooks.json、hooks-cursor.json 和 run-hook.cmd 说明：
所以别看它理念上偏轻，落到接入层其实挺认真。
很多团队也相信：
问题是，大多数时候这些只停在口头上。
Superpowers 做得更彻底一点，它把这些东西落成了：
它没有试图把一切都工具化，也没有完全依赖模型自觉。
它选择的抽象粒度是：
结果就是一个挺舒服的平衡：
因为它擅长的是：
所以放在现有项目里持续演进，这套方法会比较顺手。
这套东西当然也有代价，而且代价不小。
如果用户只想改一个小地方，Superpowers 依然倾向于：
所以在很小的改动上，它会显得有点正式，甚至有点慢。
尽管有 hook 注入和 1% 规则，但最终：
仍然依赖宿主和模型行为。
它比纯 prompt 稳很多，但终究不是严格状态机。
它有 spec、plan、git history，但没有像 GSD 那样统一的活态状态机。
所以它更适合：
但不算特别擅长：
如果用户更想要：
那 Superpowers 可能会让人觉得“管得太多”。
这不一定算缺陷，更像它故意做出的取舍。
我会更建议在下面这些场景里用它：
反过来，这几类场景就没那么合适：
如果只看表面，很容易把它理解成一套写得更细的 skill 集合。但我看完仓库后，觉得重点不在这里。更值得抄的是它后面的几个判断：
压成一句话的话，我会这么写：
它要解决的也不是“模型会不会写代码”，而是更现实的问题：
所以我觉得这套东西值得认真看一遍。它碰到的已经不是“prompt 怎么润色”这种层面，而是：
obra/superpowers — GitHubREADME.mdhooks/session-startskills/using-superpowers/SKILL.mdskills/brainstorming/SKILL.mdskills/using-git-worktrees/SKILL.mdskills/writing-plans/SKILL.mdskills/subagent-driven-development/SKILL.mdskills/executing-plans/SKILL.mdskills/test-driven-development/SKILL.mdskills/requesting-code-review/SKILL.mdskills/receiving-code-review/SKILL.mdskills/systematic-debugging/SKILL.mdskills/verification-before-completion/SKILL.mdskills/dispatching-parallel-agents/SKILL.mdskills/finishing-a-development-branch/SKILL.mdskills/writing-skills/SKILL.mdagents/code-reviewer.md
