Superpowers:让 AI 像高级工程师一样开发软件

Cursor Agent 在未安装插件时，接到开发任务通常会直接修改仓库文件。测试编写、设计核对、任务拆分，往往排列在代码变更之后。

Superpowers 是一套面向编码 Agent 的 Skill 插件，支持 Cursor、Claude Code、Codex 等平台。它约束的是 Agent 动手改代码之前必须完成的步骤：先把需求澄清、设计提交确认、计划拆解到文件级，然后才进入 TDD 与子 Agent 分工。

每个 Skill 对应仓库 skills/ 里的一份 SKILL.md。YAML 头部写明触发条件，正文写明操作步骤和检查项。任务上下文匹配到某个 Skill，Agent 就依照该文件执行；匹配不到，行为和没装插件时一样。

安装后的执行顺序

Cursor 可以在 Agent 对话中执行 /add-plugin superpowers，或者在插件市场里搜索并安装。安装完成之后，Skill 会随着插件版本同步更新，不必手动复制仓库内容。

会话启动阶段，using-superpowers 会把引导信息写入 Agent 上下文。此后出现开发类任务，按下面几步展开。

问需求和确认设计

这一步由 brainstorming 负责。Agent 一轮轮提问，把模糊需求弄清楚，把设计方案拆成几段短文字展示出来，等待确认。没确认之前，不会修改代码。

拉分支、写计划

设计确认之后，通常会调用 using-git-worktrees：在独立分支上搭建环境，确认测试基线干净。然后 writing-plans 输出实现计划，列清要改哪些文件。计划遵循三条原则：先写测试再写实现代码；不提前做用不上的功能；相同逻辑不写第二遍。

动手执行

收到「开始」指令之后，进入执行阶段。此处对应两套 Skill，同一轮任务里只会启用其中一套。

subagent-driven-development 将计划拆成多个小任务。每完成一项，主 Agent 唤起一个子 Agent，上下文仅包含该任务的说明。子 Agent 提交结果后，主 Agent 连续审查两次：先对照计划核对范围与结论，再审查代码质量。两次审查均通过后，才进入下一项，并重新唤起子 Agent。执行以 Agent 自行推进为主，中途很少暂停向人确认。

executing-plans 同样按计划拆分任务，但会把若干项合并为一批。每批完成之后，主 Agent 暂停执行，展示改动摘要，待确认后再继续下一批。检查点由人工卡断，Agent 不会连续跑完全部条目。

执行过程中始终启用 test-driven-development：先编写预期失败的测试，再编写满足测试的最少实现代码。阶段之间 requesting-code-review 列出问题并按严重程度分级，未解决的严重项阻塞后续步骤。

收尾

任务全部完成之后，finishing-a-development-branch 运行测试，再决定合并、开立 PR、保留或丢弃分支。

上述整条链路在文档里称为 Mandatory workflows，属于强制流程。Agent 会自动匹配该用哪个 Skill，不必人工指定名称。

十四份 Skill 的分工

前文讲的是主流程先后关系。下面按名字说明每一份 Skill 具体约束 Agent 做什么事。14 份 Skill 在 README 里分成三组。

测试与调试

test-driven-development 负责「先测后码」。Agent 要写新功能或修 bug，必须先写测试，并且运行一次。这时测试理应失败：代码里还没有对应实现，测试过不去才算数。如果失败是因为测试本身写错了（比如函数名拼错、引用路径不对），要先修正测试，说明测试还没写对，此时不能开始写实现代码。测试失败原因确认无误之后，再写刚好能让测试通过的最少实现代码，跑通之后再整理结构。如果 Agent 已经偷偷写了实现代码，Skill 要求删掉重来，不许「先写后补测」。文件末尾还列了一批 Agent 爱找的借口（「这次改动太小」「回头再测」），逐项堵住。

systematic-debugging 负责「别瞎改」。测试红了、编译挂了、行为不对，Agent 不能凭直觉改一行试试。要先做根因调查：读完报错和堆栈、稳定复现、对照最近提交；再拿仓库里正常工作的类似代码做对比，找差异；再只提一个假设、做最小改动验证；确认根因之后，先写能复现问题的失败测试，再动修复代码。连续改了三轮还不行，要停下来讨论架构有没有问题，而不是继续堆补丁。Skill 目录里另有 root-cause-tracing.md 等补充材料，教 Agent 沿调用链往上追坏数据从哪来。

verification-before-completion 负责「别说空话」。Agent 想汇报「测试全过了」「 bug 修好了」「可以提交了」，必须先当场跑完对应的验证命令，把完整终端输出贴出来核对：几条失败、退出码多少。不许说「应该没问题了」「上次跑过」。子 Agent 报成功也不行，主 Agent 得自己看 diff、自己跑测试。

协作与计划

brainstorming 负责需求和设计。动手改代码之前，Agent 通过提问把含糊的地方问明白，把方案拆成几段短文字，等待人工确认。没确认就不写代码。

writing-plans 负责实现计划。设计确认之后，把活拆成很多小任务，每个任务写清楚要动哪些文件、每一步怎么验证。计划粒度细到「两三分钟能干完一项」。

using-git-worktrees 负责隔离开发环境。开新分支时，在独立 git worktree 里搭环境、跑一遍测试，确认基线干净，避免和当前工作区搅在一起。

subagent-driven-development 负责「一项一子 Agent」的执行方式：子 Agent 只带当前任务上下文，做完由主 Agent 审查两遍。

executing-plans 负责「一批一批干」的执行方式：每批做完暂停，等待人工确认再继续。

dispatching-parallel-agents 负责并行排错。多个测试文件、多个子系统各自独立地挂掉时，可以同时唤起多个子 Agent，各盯一块，而不是一个 Agent 从头查到尾。前提是问题之间没有共享状态、改一处不会影响另一处。

requesting-code-review 负责阶段评审。每个任务或每批任务做完，对照计划检查一遍，把问题按严重程度列出来，严重项没处理不能往下走。

receiving-code-review 负责回应评审意见。收到修改建议时，先核实技术上是否成立，再决定改不改，而不是为了表态迅速全收或全拒。

finishing-a-development-branch 负责分支收尾。全部任务完成之后，跑测试，再决定合并进主分支、开 PR、保留分支还是直接丢掉。

元技能

using-superpowers 在每次会话启动时注入，教 Agent 怎么识别该加载哪份 Skill，是整个体系的入口说明。

writing-skills 给维护者用，规定怎么编写新的 SKILL.md、怎么给 Skill 做行为测试。普通使用者安装插件即可，一般不需要碰这里。

各平台的安装方式

不同 Agent 平台的安装命令并不相同，需要分别配置。

Cursor 在 Agent 对话中执行 /add-plugin superpowers。

Claude Code 执行 /plugin install superpowers@claude-plugins-official，或者从 obra/superpowers-marketplace 安装。

Codex 在侧边栏 Plugins 中添加，或者在 CLI 中通过 /plugins 搜索并安装。

Gemini CLI、OpenCode、Pi、Factory Droid 等平台的命令参见仓库 README 对应章节。Skill 内容相同，安装入口各自独立。

流程偏重

Superpowers 把步骤卡得比较死。有时只想改一行配置，也可能被拉进完整的 brainstorming——一轮轮提问、分段确认设计，全套走完才动代码。若本次只想做小改动，需要在对话开头写明范围（例如「只修改某文件某一行，不要动其他文件」），或者临时卸载插件再改。

拾遗小结

Superpowers 将固定的工程顺序写入 Agent 可读取的 Markdown 文件：先澄清需求与设计，再拆解计划，再按 TDD 实现，中途穿插评审与分支管理。

它不替换底层模型，改的是 Agent 接到开发任务之后的默认动作。测试、设计和计划会排在改代码之前，不容易被 Agent 略过；代价是步骤偏紧，小改动也可能经历完整流程。

开源拾遗 · 每天推荐一个优质开源项目

觉得这篇文章有帮助？点个关注，每天带你挖一个优质开源项目。

本期项目：https://github.com/obra/superpowers

本文为「开源拾遗」原创深度解读，转载请注明出处。