1. Superpowers 是什么

Superpowers 是一套给 coding agent 装上「工程纪律」的插件，由 Prime Radiant 维护。它不是 prompt 模板库，而是一套建立在 Skills（技能） 之上的完整软件工程方法论——会话启动时通过 bootstrap 机制，让 AI 在正确的时刻自动调用正确的流程。

核心设计：

1. Skills — 用 Markdown 编写的、可版本控制的行为规范，描述「什么时候用」「必须做什么」「禁止做什么」
2. Bootstrap — 会话开始时注入 using-superpowers 技能，教会 agent：有技能就必须用，在回复或行动之前先检查技能
3. 自动触发 — 不需要手动输入 /brainstorm。agent 判断你在「开始一项任务」时，默认进入设计讨论，而不是直接写代码

项目刻意保持零第三方依赖——skills 是纯文本，hooks 是 shell 脚本，可在任何支持插件/hooks 的 harness 上运行。

• 项目仓库：https://github.com/obra/superpowers
• 原文发布：https://blog.fsck.com/2025/10/09/superpowers/
• 当前版本：v6.x（2026 年 6 月）

支持 Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Pi、Antigravity、Kimi Code 等十余种 harness。

2. 为什么需要它

AI 编程助手已经能写代码，但常见体验是：

• 你说「帮我做一个 React Todo 列表」，AI 立刻建项目、写组件——还没问清楚你要什么
• 代码能跑，但架构随意、测试缺失、边界情况没考虑
• 改了一个 bug，又引入两个新 bug
• 长会话里 AI 逐渐「忘记」最初的设计约定

Superpowers 解决的是流程问题：把设计、隔离开发、细粒度计划、TDD、审查、收尾编码进系统，而不是每次靠人提醒。

3. 核心工作流

Superpowers 把一次功能开发拆成七个阶段，每个阶段对应一个 skill，按顺序自动衔接：

brainstorming → using-git-worktrees → writing-plans
       → subagent-driven-development / executing-plans
       → test-driven-development（贯穿实现）
       → requesting-code-review → finishing-a-development-branch

3.1 Brainstorming — 先设计，后编码

触发时机： 任何创造性工作之前——新功能、新组件、行为修改。

做什么：

• 探索项目上下文（文件、文档、最近提交）
• 一次只问一个问题，逐步澄清目的、约束、成功标准
• 提出 2–3 种方案并给出权衡与推荐
• 分块展示设计，每块都等你确认
• 写入设计文档（docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md）
• 设计获批后，才进入 writing-plans

HARD-GATE： 在用户批准设计之前，禁止写代码、搭脚手架或调用任何实现类 skill。「太简单了不需要设计」是被明确禁止的反模式。

可选的 Visual Companion 会在「展示比描述更清楚」时打开本地 Web 界面，方便做选择题式的需求澄清。

3.2 Using Git Worktrees — 隔离的工作空间

设计通过后，在 git 仓库中创建独立 worktree 和新分支，运行项目 setup，确认测试基线干净。同一项目上可并行多个任务，互不干扰。

v5.1+ 改进：若 agent 已在 worktree 内运行则跳过创建；创建前会征求同意；优先使用 harness 原生 worktree 工具。

3.3 Writing Plans — 给「零上下文的初级工程师」看的计划

计划写得足够详细，以至于没有项目上下文的 implementer 也能照做。强调 YAGNI、DRY 和真正的 RED/GREEN TDD。

v6.0 新增结构：

• Global Constraints — 每个任务都必须遵守的全局规则（版本下限、依赖限制、命名规范等）
• Interfaces — 每个任务明确「消费什么、产出什么」
• 任务粒度 — 每个任务 2–5 分钟量级，含精确文件路径、完整代码片段、验证步骤

3.4 Subagent-Driven Development — 子 agent 流水线

你说「go」之后，主 agent 作为协调者：

1. 为每个任务 dispatch 一个全新的 implementer 子 agent
2. 子 agent 实现、测试、提交、自审
3. 每个任务完成后 dispatch task reviewer，同时检查 spec 合规与代码质量
4. 全部任务完成后，做一次整分支 broad review
5. 调用 finishing-a-development-branch 处理合并/PR/保留/丢弃

主 agent 不会在任务之间停下来问「要继续吗？」——你批准了计划，它就执行到底。

v6.0 审查流程重构（eval 中约 2× 速度、~50% token 节省）：

进度记录在 .superpowers/sdd/。

替代路径 executing-plans： 任务紧密耦合、或你希望人工把控节奏时，可选批量执行 + 人工检查点模式。

3.5 Test-Driven Development — 铁律

贯穿整个实现阶段：

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

• RED： 写失败测试，亲眼看到它失败
• GREEN： 写最少代码让测试通过
• REFACTOR： 在绿灯下整理

先写了实现代码？删掉，重来。没有「先留着当参考」的例外。

3.6 Requesting Code Review

按严重程度报告问题，Critical 问题阻塞后续进度。

3.7 Finishing a Development Branch

验证测试、呈现选项（合并 / 开 PR / 保留分支 / 丢弃）、清理 worktree。已 forge-neutral，不再硬编码 gh pr create。

4. Skills 机制

工作流本身不是重点，Skills 才是。Skills 是给 LLM 的可执行规范——在适用场景下是强制流程，不是建议。

Skill 文件通常包含：

• YAML frontmatter（name、description）— description 决定何时被检索/触发
• 流程图（Graphviz dot）
• Checklist（agent 必须为每项建 todo）
• Red Flags 表 — 列出 agent 常见的自我合理化借口及反驳
• HARD-GATE — 不可逾越的门槛

4.1 Bootstrap：using-superpowers

每个 harness 在会话启动时加载 bootstrap，核心规则：

只要有 1% 的可能某个 skill 适用，就必须 invoke 该 skill——在回复、澄清问题、读文件之前。

常见 Red Flags：

优先级：用户显式指令 > Superpowers skills > 默认 system prompt。

4.2 Skills 也会「TDD」

writing-skills skill 要求新 skill 经过对抗性压力测试：用子 agent 模拟真实场景（生产宕机、沉没成本、时间压力），而不是做问答题式的「满分测验」。测试失败后，skill 文案会被加强——这就是 skills 的 RED/GREEN。

4.3 说服原理

writing-skills/persuasion-principles.md 记录了 Meincke et al. (2025) 的研究：对 LLM 使用 Cialdini 的七种说服原则，合规率从 33% 提升到 72%。Superpowers 用 Authority、Commitment、Scarcity、Social proof 等杠杆，让 engineering discipline 在压力下仍被遵守——对抗 LLM 天生的「先动手再说」倾向。

5. Skills 库一览

测试

调试

协作 / 流程

元技能

6. 设计哲学

Skills 里刻意使用 「your human partner」 而非「user」——强调结对关系，这是经过测试的设计选择。

7. 安装与支持平台

Superpowers 是 harness-neutral 的：同一套 skills，通过各平台的 hooks/bootstrap 适配不同 runtime。

集成标准： 必须在会话启动时加载 using-superpowers bootstrap。手动复制 skill 文件、或需要每会话手动 opt-in 的方案，不算合格集成。

验收测试

在全新会话中发送：

Let's make a react todo list

若 brainstorming 在写任何代码之前自动触发，则集成有效。

8. 版本演进

仍在推进的方向：Sharing（个人 skills 共享机制）、Memories（remembering-conversations 各组件已写好，尚未完全串联发布）。

9. 测试与质量保障

Superpowers 把测试分成两层：

1. tests/ — 插件基础设施测试（hooks、manifest、跨平台 shell）
2. evals/（superpowers-evals）— 用 Drill harness 驱动真实 Claude Code / Codex / Gemini 会话，LLM verifier 判断 skill 合规性

修改 skill 内容有极高门槛：需要 adversarial pressure testing、before/after eval 证据。

10. 使用建议

10.1 第一次体验

安装后，发一句 Let's make a react todo list，观察 agent 是在问「你要什么样的 Todo」，还是已经 npm create vite 了——差别本身，就是 Superpowers 存在的理由。

10.2 与 OpenSpec 的关系

两者都强调「先对齐再写代码」，但路径不同：

可以组合使用：OpenSpec 管「做什么」，Superpowers 管「怎么做」。

10.3 Telemetry

Brainstorming 的 Visual Companion 默认会从 Prime Radiant 网站加载 logo（含版本号），用于粗略统计使用量——不含项目内容。可通过 SUPERPOWERS_DISABLE_TELEMETRY=1 关闭。

11. 常见问题

Q: Superpowers 会增加多少流程负担？

A: 简单功能的设计可以只有几句话，但 brainstorming 流程不能跳过。收益是减少返工、测试缺失和架构随意。

Q: 必须用 Superpowers 才能用 AI 编程吗？

A: 不是。但如果你经历过「AI 理解偏差导致返工」或「代码能跑但没有测试」的痛苦，这套纪律的投资回报率很高。

Q: 支持 Cursor 吗？

A: 支持。在 Agent 聊天中用 /add-plugin superpowers 或从插件市场安装，确保 bootstrap 在会话启动时加载。

Q: 如何贡献？

A: PR target dev 分支，必须填写 PR template、披露 authoring environment、附 human partner 审阅。详见 CONTRIBUTING。

12. 小结

Superpowers 的核心洞察：

1. LLM 会写代码，不等于 LLM 会做工程。 设计、测试、审查、版本隔离需要被编码进系统。
2. Skills 是行为即代码。 可版本控制、可测试、可组合、可跨 harness 移植。
3. 自动触发是关键。 Bootstrap + description 驱动的检索，让「先 brainstorm 再写代码」成为默认路径。

完整工作循环：

1. brainstorming 对齐设计
2. worktree 隔离开发
3. writing-plans 细粒度计划
4. subagent-driven-development 逐任务实现 + 审查
5. TDD 贯穿实现
6. finishing-a-development-branch 收尾

如果你已经在用 AI 编程助手，Superpowers 值得试一次。安装后从 Let's make a react todo list 开始，看 agent 是否先问需求再写代码。