Superpowers 深度剖析：从架构到 14 个 Skill 逐个拆解Superpowers 深度剖析：从架构到 1

Superpowers 深度剖析：从架构到 14 个 Skill 逐个拆解

0. 太长不读

Superpowers 不是某一个很强的 skill，它更像一套给编码 Agent 用的流程规矩。看完仓库后，我的感觉很明确：它关心的重点不是“再把模型抬高一点”，而是“别让它上来就乱写”。

核心思路可以压成 4 句：

用 SessionStart Hook 在每次会话开头塞进一条规则：先判断 skill 适不适用，再做别的
用 using-superpowers 把“先找流程，再执行”变成默认动作
用一组 process skills 把设计、规划、实现、调试、验证、收尾串起来
用几道 quality gate 把 TDD、验证、review 从“建议”升级成“门槛”

从实现上看，这套东西其实挺省力的：

没有很重的 CLI 层
没有常驻状态机
没有塞一堆 Node/Python 编排程序
主要靠 Hook + Skills + 少量 commands + 一个 reviewer agent

这也是它和 GSD 那类更重的系统最明显的区别。

如果只用一句话概括，我会这么说：

Superpowers 做的事，是把工程纪律写成 Agent 能反复执行的流程。

1. 它到底是什么

Superpowers 在 README 里的自我定义其实已经说得很直白：

它是一套构建在可组合 skills 之上的完整软件开发 workflow。

这句话拆开看，会更清楚。

1.1 它不是单个 Prompt

它不是那种“贴一段神奇 system prompt，模型立刻开窍”的东西。

它有：

skills/：14 个 skill
hooks/：会话启动注入逻辑
commands/：少量显式命令入口
agents/：辅助 reviewer agent
.claude-plugin/ / .cursor-plugin/ / .codex/ / .opencode/：平台适配

所以它已经不只是几篇文档，而是一套围绕 skill 机制组织起来的跨平台 workflow 包。

1.2 它也不是重型工作流引擎

它没有像很多 Agent 系统一样做这些事情：

没有统一的 .planning/STATE.md
没有复杂 CLI 安装器负责运行时编排
没有持久化项目状态机
没有显式的多阶段文件系统协议来承载全部上下文

它还是把大量控制逻辑留在 skill 文本里。

所以它更像：

Hook 注入元规则 + Skill 按需加载 + 子 Agent review 回路

而不是：

CLI 工具链 + 状态机 + 文件总线 + orchestration engine

1.3 它卖点不在“更强”，而在“更稳”

Superpowers 里最显眼的词不是 “speed”，而是：

TDD
systematic
verify
review
plan
worktree

它想解决的问题也很具体：

把一个容易抢跑、容易自信、也容易糊弄过去的 Agent，往工程师该有的工作方式上拽一把。

2. 从仓库结构看整体架构

基于当前本地快照，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 个，而是谁拿着入口控制权：

不是等用户主动说“请使用 brainstorming”
而是 hook 在 session 一开始，就把“先判断 skill 是否适用”塞进上下文

这一点决定了后面的整套行为。

3. 第一层：SessionStart Hook 怎么把流程接进来

入口就在这两个位置：

hooks/session-start
skills/using-superpowers/SKILL.md

3.1 Hook 做了什么

session-start 做的事很朴素：

找到 plugin 根目录
读取 using-superpowers/SKILL.md
转义成 JSON 可注入文本
根据不同平台输出不同字段
- Claude Code：hookSpecificOutput.additionalContext
- Cursor：additional_context
- 其他平台：fallback

它不是塞一段摘要，而是把 完整的入口 skill 放进会话里。

3.2 为什么不是只注入一句简短规则

原因也不复杂。Superpowers 不只是想提醒一句：

“请记得使用 skills”

它要注入的是一整套上游规则：

skill 使用优先级
用户指令和 skill 的优先级关系
什么时候必须先调用 skill
哪些思维模式是借口和 rationalization
process skill 和 implementation skill 的先后顺序

说白了，它想先把玩法讲清楚，再让 Agent 开始干活。

3.3 这个设计的意义

很多 skill 系统最后没跑起来，不是因为内容写得差，而是模型总会这样：

忘了先检查 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: 再开始真正响应

4. 第二层：using-superpowers 在管什么

using-superpowers 不处理业务，它管的是更前面的东西：

这套 skill 以后该怎么用，顺序是什么，什么时候不能跳步。

4.1 它最关键的规则

最著名的一句是：

如果你觉得某个 skill 有 1% 的概率适用，那你就必须调用它。

这条规则表面看很夸张，实际上是在对抗模型最常见的失败模式：

“这只是个简单问题”
“我先看看代码再说”
“我需要更多上下文后再决定”
“我记得这个 skill 的内容，不用重读”

在 Superpowers 看来，这些都属于绕流程走。

4.2 它管的是“先做什么”

using-superpowers 规定了两个顺序：

顺序一：先 skill check，再做任何事

甚至连：

clarifying questions
探索代码库
查看 git
收集信息

这些都得往后排，先过 skill check。

顺序二：先 process skills，再 implementation skills

比如：

“做个新功能” → 先 brainstorming
“修 bug” → 先 systematic-debugging
“要进入 plan mode” → 先判断有没有流程 skill

这一步很关键，因为它把“先定流程”放到了“立刻行动”前面。

4.3 它也把优先级说清楚了

using-superpowers 明确写了优先级：

用户明确指令最高
Superpowers skills 次之
默认系统提示最低

这一点我挺认同。很多流程系统的问题不在流程本身，而在于它总想压过用户。

Superpowers 没往这个方向走。它很强势，但边界也写得清楚：

用户决定 WHAT，skill 决定 HOW。

5. 整体工作流：从想法到交付的主链路

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 工作流拉开了距离。

5.1 它把“写代码”推迟得很晚

用户一上来提需求，不是直接：

create file
写函数
修改组件

而是先：

需求澄清
设计方案
规格确认
计划拆分

它默认的工作方式其实就是：

先把设计和实现的边界说清楚，再动手。

5.2 它把“完成”定义得很严格

对 Superpowers 来说，完成不等于：

代码写完了
自己觉得对了
子 agent 说成功

完成至少要经过：

测试优先或测试证明
review
verification
结束分支流程

换句话说，在这套系统里，“看起来差不多”不算完成。

6. 它的设计取向：Skill-First，不是 Tool-First

不要把确定性逻辑放进上下文；能外化成工具和系统规则的，就外化。

Superpowers 对这个原则的处理挺克制。它没有一路冲到“全部工具化”，也没停在“全靠 prompt 自觉”。

6.1 它并不彻底工具化

和 GSD 这类系统不同，Superpowers 没有把大量流程逻辑外化成：

CLI 状态机
结构化状态文件
JSON 配置与调度器

相反，它把不少规则放在文本层。

例如：

“先用哪个 skill”
“什么算 blocker”
“什么时候必须停下来问用户”
“review 的顺序”

这些还是靠 skill 来约束。

6.2 但它也不是纯 Prompt 魔法

但它也不是纯文档，还是做了三层加固：

1. Hook 级硬化

用 SessionStart 把元规则稳定注入。

2. 结构级硬化

每个 skill 都有：

name
description
use conditions
checklist / flowchart / hard gate

这比松散文档强很多。

3. 子 agent 隔离

subagent-driven-development 和 dispatching-parallel-agents 明确要求：

fresh subagent
不继承主会话历史
主会话负责构造上下文

这已经不是简单的“提示词写得更细”了，而是在主动管上下文边界。

6.3 所以它到底落在哪

我会把 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

7. 上下文工程：Superpowers 怎么防止 Context Rot

7.1 入口常驻，细节按需

常驻的不是所有 skill，而只有 using-superpowers。

这样做有几个很实际的好处：

常驻 token 小
只把“找 skill 的元规则”放到最前面
具体 skill 只有在触发时才加载

它的结构其实很简单：

常驻层
  └── using-superpowers

按需层
  └── 具体 process / quality gate skills

这就是很典型的 index + on-demand load。

7.2 Skill description 只写触发条件，不写流程摘要

writing-skills 里把这个原则写得很细，甚至给它起了名字：

CSO - Claude Search Optimization

核心思想是：

description 只说明什么时候该用
不要在 description 里总结 skill 的流程

原因也很现实：

如果 description 把流程都讲完了，模型可能直接照 description 做，而不去读 skill 全文。

这里能看出来，它不是随手写说明文，而是在认真处理检索和触发稳定性。

7.3 子 agent 隔离上下文污染

subagent-driven-development 和 dispatching-parallel-agents 的共同核心是：

主会话不把所有历史倒给子 agent
子 agent 只拿当前 task 所需上下文
主会话保持干净，继续做协调和判断

这一点我很认同。上下文不是越多越好，准一点反而更有用。

8. 多 Agent 设计：它不是“多开几个 agent”，而是受控回路

Superpowers 里和多 agent 最相关的有两个 skill：

subagent-driven-development
dispatching-parallel-agents

这两个 skill 对应的是两种不同的并行方式。

8.1 subagent-driven-development：串行任务 + 两阶段 review

它的主模式是：

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"]

这个设计的重点不在“多”，而在分工：

一个 agent 负责产出
一个 agent 负责对照规格
一个 agent 负责代码质量

而且 review 顺序不能反：

先看有没有按 spec 做
再看代码写得好不好

8.2 dispatching-parallel-agents：并行调查不同问题域

这个 skill 管的是另一类场景：

多个故障彼此独立，串行排查太浪费时间。

它强调的不是实现，而是 独立问题域拆分：

一个 agent 查 A 测试文件
一个 agent 查 B 子系统
一个 agent 查 C race condition

条件是：

没有共享状态
不会互相改同一批东西
每个问题都可以自洽理解

所以这种并行更像几个调查组同时查不同方向，不是装配线。

8.3 它和 GSD 式 Wave 并行的不同

和 GSD 那种 wave 式并行相比，Superpowers 这边更轻：

更依赖人或 controller 的任务拆分质量
更强调上下文精确构造
没有很重的状态同步与文件锁体系

所以它的多 agent 更接近：

轻量但受控的子 agent 协作

9. 工程纪律层：哪些规则在这里真的是硬门槛

我觉得 Superpowers 最值钱的部分，不是 skill 数量，而是它真把几条工程规则写成了硬约束。

9.1 TDD 不再是建议，而是铁律

test-driven-development 的核心不是“推荐先写测试”，而是：

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

而且它非常强硬：

先写了代码？删掉
不允许把旧实现当参考
不允许“先写完再补测试”

一般团队文档很少写这么死，但它这里就是这么定的。

9.2 Debugging 不是试错，而是科学方法

systematic-debugging 直接规定：

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

它把调试拆成 4 阶段：

Root cause investigation
Pattern analysis
Hypothesis and testing
Implementation

比起“先改一把试试”，这套做法显然要稳很多。

9.3 验证先于宣告

verification-before-completion 规定：

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

这个 skill 有意思的地方不在技术细节，而在它专门管“别乱报喜”：

没跑命令就不能说 pass
不能说“应该可以了”
不能用部分验证替代完整验证

它就是在防一件事：为了显得高效，提前宣布完成。

9.4 Review 不是礼貌，而是工序

requesting-code-review 和 receiving-code-review 一起构成了 review 的正反面协议。

前者要求：

关键节点必须 review
reviewer 要拿精确上下文，不继承主会话历史

后者要求：

收到 review 不能先表演式同意
先理解，再验证，再决定是否实施
如果 reviewer 错了，要技术性 push back

这两个 skill 放在一起看，处理了两个常见问题：

Agent 不 review 就往前冲
Agent 收到反馈就无脑照单全收

10. 14 个 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	扩展系统时

10.1 using-superpowers

这个 skill 不做业务，它只做一件前置工作：先把整套系统的使用顺序钉住。没有它，后面的 13 个 skill 很容易沦为“想起来才用”的说明书。

它最狠的地方就是 1% 规则。只要有一点可能适用，就先调 skill，不许靠感觉跳过去。再加上 process skill 优先、用户指令优先级更高，这个入口层就算是搭稳了。

10.2 brainstorming

brainstorming 是所有创造性任务的第一站。新功能、重构、交互改造、架构调整，这些都不能直接写。

它卡住的是几种很常见的抢跑行为：

目标还没讲清楚，就开始实现
方案只有一个，连比较都没有
觉得“只是小改动”，于是跳过设计

这里我最喜欢的有三条：

没有设计批准，不进入 implementation skill
一次只问一个问题，避免把用户问烦
spec 要落盘到 docs/superpowers/specs/

这就不是“先聊聊需求”那么简单了，而是把需求分析、方案比较和确认边界收成了一个标准动作。

10.3 using-git-worktrees

很多人会把 git worktree 当小技巧用，但 Superpowers 不是这个态度。它把 worktree 放进主流程里，意思很明确：实现前先隔离环境。

它主要防三件事：

在主工作区直接开搞
多个任务互相污染
工作目录建得很随意，最后还进了版本库

细节上也不含糊。目录怎么选有顺序，项目内目录要先 git check-ignore，建完 worktree 还得做 setup 和 baseline test。流程走到这里，环境已经不是“顺手整理一下”，而是交付前提的一部分。

10.4 writing-plans

writing-plans 干的活，是把 spec 继续往下压一层，压到可以交给执行者直接开干。

很多计划文档其实没法执行，常见问题就那几个：

步子太大，一口气写“实现支付模块”
留一堆 TODO / TBD / edge cases
验证写得很虚，像“确保测试通过”

Superpowers 这里要求挺硬：每一步控制在 2 到 5 分钟；写代码步骤就给出实际代码；验证步骤就给出命令和预期。它默认执行者上下文不多，也不会替你补脑，所以计划必须写得低歧义、可复制、可验证。这一点非常工程化。

10.5 subagent-driven-development

如果说前面几个 skill 负责把路铺平，那 subagent-driven-development 就是正式开工的主引擎。

它不鼓励主会话自己一头扎进去写，而是拆成几种角色：

implementer 负责产出
spec reviewer 看是否按规格来
code quality reviewer 看代码质量
final reviewer 做收尾检查

重点不只是“用了子 agent”，而是 review 顺序不能乱。先问做没做到，再问写得好不好。这个顺序很像真实工程团队里的工作流，能明显减少那种“代码挺漂亮，但方向写偏了”的问题。

10.6 executing-plans

这个 skill 是兜底方案。平台能力不够，或者当前场景不适合用 subagent，就退回到单会话按 plan 执行。

但即便是 fallback，它也没有放松要求：

先完整读 plan，再批判性 review
按任务一个个做，不随手跳步
遇到 blocker 立刻停下来
最后还得接到 finishing-a-development-branch

所以它只是换了执行载体，没有把流程松掉。

10.7 test-driven-development

test-driven-development 在这里不是装饰品，而是真门槛。仓库里写得很清楚：没有先失败的测试，就不该出现生产代码。

这条线一旦拉起来，几个坏习惯基本都会被挡住：

先写代码，之后再补测试
测试只拿来给现有实现背书
一赶时间就把测试先放一边

它的流程大家都熟，RED -> Verify RED -> GREEN -> Verify GREEN -> REFACTOR。但熟是一回事，真写进系统又是另一回事。Superpowers 的意思很明确：实现的合法入口，就是那个先失败过的测试。

10.8 requesting-code-review

很多 Agent 工作流的问题，不在不会 review，而在 review 来得太晚。全做完了再一起看，代价会高很多。

requesting-code-review 要求在关键节点主动发起 review，而且 review 范围要靠 git SHAs 这种硬边界来定。reviewer 只拿必要上下文，不把主会话的噪音一股脑倒过去。

这样做的好处很实际：review 不再是最后礼貌性补一刀，而是 task 流程本身的一环。

10.9 receiving-code-review

这个 skill 我觉得很少见，也很有价值。很多系统只管“怎么发起 review”，不太管“收到 review 后别犯蠢”。

它盯住的是三种反应：

表演式认同
不验证就照改
reviewer 说一句，自己就失去判断

所以它要求的顺序是：先理解，再验证，最后决定是实施还是 push back。甚至还把 “You’re absolutely right!” 这种社交化台词单独拎出来反对。这个味道很真实，因为它防的不是技术错误，而是工程讨论里常见的失真。

10.10 systematic-debugging

systematic-debugging 统一接管所有 bug 和异常场景。这里最核心的一条规则是：别在没找到根因前就急着修。

它把调试拆成 4 步：

Root cause investigation
Pattern analysis
Hypothesis and testing
Implementation

更见功夫的是后面的细节要求。多组件系统先加诊断埋点，深调用链问题要反向 trace data flow，三次 fix 还不对就别再硬补丁了，开始怀疑架构。能把这些写进 skill，说明作者对调试这件事是有实战焦虑的。

10.11 verification-before-completion

这个 skill 专门管“别太早宣布胜利”。

它的要求很简单，也很烦人，但确实有用：

先找出能证明结果的命令
重新运行
把输出读完
再决定能不能说 done

它不是为了多跑一遍测试，而是为了把“我觉得差不多了”挡在门外。很多 Agent 最大的问题不是不会做，而是太爱提前收工。

10.12 dispatching-parallel-agents

dispatching-parallel-agents 不是用来炫并发的。它只在一种情况下有价值：问题域彼此独立，串行查太浪费时间。

适用条件也很克制：

至少两个独立任务
没有共享状态
可以并行，不会互相踩

所以它更像多组人同时调查不同方向，而不是一个自动化大流水线。Superpowers 的并行能力就到这里，不贪。

10.13 finishing-a-development-branch

很多系统前面都讲得很细，最后收尾反而很随意。Superpowers 没把这一段省掉。

finishing-a-development-branch 主要处理这些脏活：

测试没过，不能合并
别再抛一句“接下来怎么办”
branch 和 worktree 要不要清理，得明确
放弃工作也要确认，不是直接删

它的流程也很朴素：先验证，再给用户几个清楚的选项，然后按选项处理后续。收尾这一步被单独拿出来，我觉得是对的，因为很多工程事故其实就出在“最后随手一弄”。

10.14 writing-skills

最后这个 skill 很有意思，它不是用来做业务，而是用来继续造 skill。

仓库在这里给出的判断我很认同：写 skill 这件事，本身也应该按 TDD 来做。先看 Agent 没有 skill 时怎么失败，再写最小 skill 去修，再补掉暴露出来的新漏洞。

它解决的问题也很现实：

skill 写得太随意，根本验证不了
一次性的经验被误当成可复用方法
description 写得不可检索，结果永远触发不到

做到这一步，Superpowers 就不只是“会用 skill”，而是在认真处理这套系统怎么长出来、怎么继续维护。

11. skill 之外：commands、agent、hook 配置分别干什么

除了 14 个 skill，当前仓库里还有 3 类辅助结构。

11.1 commands

当前有 3 个 command 文件：

brainstorm.md
write-plan.md
execute-plan.md

这说明它现在已经不是只能靠自动路由，部分平台也能手动点名走流程。

11.2 code-reviewer agent

agents/code-reviewer.md 是一个 reviewer agent prompt。

它负责的不是笼统 code review，而是：

对照原计划检查 plan alignment
检查 code quality
评估架构与设计
分类 issue：Critical / Important / Suggestions

这说明它的 review 不是“顺便看看”，而是专门切了一个角色出来做。

11.3 hooks 配置

hooks.json、hooks-cursor.json 和 run-hook.cmd 说明：

它在认真做跨平台落地
不是把 skill 丢给用户自己想办法接入

所以别看它理念上偏轻，落到接入层其实挺认真。

12. 这套系统最强的地方

12.1 把工程纪律写成显式规则

很多团队也相信：

要先设计
要有计划
要做 TDD
要验证
要 review

问题是，大多数时候这些只停在口头上。

Superpowers 做得更彻底一点，它把这些东西落成了：

会话入口规则
skill 文本协议
硬 gate
agent 编排顺序

12.2 抽象层级拿捏得比较准

它没有试图把一切都工具化，也没有完全依赖模型自觉。

它选择的抽象粒度是：

让 hook 解决入口
让 skill 解决流程
让子 agent 解决隔离
让 commands 和 agents 做少量补强

结果就是一个挺舒服的平衡：

比“纯 prompt 套路”更稳定
比“重型 workflow engine”更轻

12.3 它很适合在现有代码库里做增量开发

因为它擅长的是：

先澄清目标
再设计
再分任务
再以 task 为单位稳定推进

所以放在现有项目里持续演进，这套方法会比较顺手。

13. 它的代价和局限

这套东西当然也有代价，而且代价不小。

13.1 流程成本高

如果用户只想改一个小地方，Superpowers 依然倾向于：

先 brainstorm
再 plan
再实现

所以在很小的改动上，它会显得有点正式，甚至有点慢。

13.2 依赖 skill 的触发和执行可靠性

尽管有 hook 注入和 1% 规则，但最终：

skill 是否真的被调用
skill 是否被完整阅读
skill 是否被严格执行

仍然依赖宿主和模型行为。

它比纯 prompt 稳很多，但终究不是严格状态机。

13.3 跨 Session 连续性不如重状态系统

它有 spec、plan、git history，但没有像 GSD 那样统一的活态状态机。

所以它更适合：

单个 feature 的连续推进
中短程开发循环

但不算特别擅长：

超长周期项目的细粒度状态恢复

13.4 对不喜欢流程的人会显得偏重

如果用户更想要：

直接开干
少问问题
少写 spec
少写 plan

那 Superpowers 可能会让人觉得“管得太多”。

这不一定算缺陷，更像它故意做出的取舍。

14. 什么时候最适合用 Superpowers

我会更建议在下面这些场景里用它：

你在做现有代码库上的功能演进，不想让 agent 乱改
你特别重视 TDD、验证和 review
你希望 agent 像一个被严格管理的初级工程师
你需要高质量增量交付，而不是高自由度探索
你想把团队工程纪律固化成流程协议

反过来，这几类场景就没那么合适：

你只是想快速试个 idea
你不愿意先做设计和计划
你更偏好重型状态机和全自动流程调度

15. 总结：Superpowers 的重点不是更强，而是更稳

如果只看表面，很容易把它理解成一套写得更细的 skill 集合。但我看完仓库后，觉得重点不在这里。更值得抄的是它后面的几个判断：

入口必须被控制
流程优先于动作
spec、plan、TDD、review、verification 都应该是系统级约束
子 agent 的上下文必须被精确限制
完成感必须建立在新鲜证据上

压成一句话的话，我会这么写：

Superpowers 用 Hook 管入口，用 Skills 管流程，用子 Agent 管隔离，再用 TDD 和验证把交付这件事卡严。

它要解决的也不是“模型会不会写代码”，而是更现实的问题：

当模型已经会写代码时，怎么让它在真实工程里少犯错、少跑偏、少自我感动。

所以我觉得这套东西值得认真看一遍。它碰到的已经不是“prompt 怎么润色”这种层面，而是：

怎么把工程纪律翻成 Agent 真能照着执行的流程。

参考资料

Superpowers 仓库：obra/superpowers — GitHub
README.md
hooks/session-start
skills/using-superpowers/SKILL.md
skills/brainstorming/SKILL.md
skills/using-git-worktrees/SKILL.md
skills/writing-plans/SKILL.md
skills/subagent-driven-development/SKILL.md
skills/executing-plans/SKILL.md
skills/test-driven-development/SKILL.md
skills/requesting-code-review/SKILL.md
skills/receiving-code-review/SKILL.md
skills/systematic-debugging/SKILL.md
skills/verification-before-completion/SKILL.md
skills/dispatching-parallel-agents/SKILL.md
skills/finishing-a-development-branch/SKILL.md
skills/writing-skills/SKILL.md
agents/code-reviewer.md
Tw93《你不知道的 Agent：原理、架构与工程实践》— 原文