Superpowers：误用与退出条件
框架最大的风险，不是它本身太差，而是团队把它用成“看起来很完整”的仪式，却没有把真实交付、验证和 review 绑进去。能不能及时退出错误用法，比一开始会不会写模板更重要。
常见误用
- 装了框架却没有 repo 规则、测试门禁和 owner，最后只剩复杂 ritual。
- 过度并行 subagent，导致 owner 无法解释每条 lane 在做什么。
- 跳过 TDD 和 review，只保留“skills 很多”的表面热闹。
维护成本
- 技能、模板和工作约定需要持续同步到团队真实做法。
- 需要有人负责 worktree、plan 和 review packet 的最小标准。
- 如果工具入口切换，Superpowers 的接入方式也要调整。
退出条件
- 团队已经完全绕开它，回到各自 improvisation。
- 大家能说出技能名，但说不出每个阶段产出什么。
- 框架维护成本高于它带来的返工下降和节奏稳定收益。
维护与退出矩阵
| 判断面 | 继续保留框架的条件 | 该停下来做减法的信号 |
|---|---|---|
| 执行方式 | 技能、模板和工作约定需要持续同步到团队真实做法。 | 团队已经完全绕开它，回到各自 improvisation。 |
| 团队认知 | 需要有人负责 worktree、plan 和 review packet 的最小标准。 | 大家能说出技能名，但说不出每个阶段产出什么。 |
| 长期收益 | 如果工具入口切换，Superpowers 的接入方式也要调整。 | 框架维护成本高于它带来的返工下降和节奏稳定收益。 |
团队检查清单
- 团队能不能说清每个阶段产出什么，而不只是记住框架名。
- 框架维护成本有没有低于它带来的返工下降与节奏稳定收益。
- 只要真实任务已经持续绕开这套骨架，就该先停下来做减法。
这类风险页的作用，不是证明框架“也有问题”，而是帮助你在框架开始失效时尽早识别出错方向，避免继续往一个已经不被真实任务采用的骨架里堆更多 ritual。
下一步怎么读
- BMAD：如果你需要团队角色和阶段制度，BMAD 更适合组织治理。
- Spec Kit：如果你主要想固定 spec -> plan -> tasks，Spec Kit 更直接。
- OpenSpec：如果你主要是 brownfield 小改动管理，OpenSpec 更轻。
- Terminal-First Repo Pairing：Superpowers 很适合叠加在终端式 repo pairing 上。
- Parallel Worktrees / Multi-Agent：它把 worktree 和 subagent 使用方式标准化。
- Spec-First：复杂任务可先 spec-first，再交给 Superpowers 组织日常执行。