简打卡
51.76M · 2026-03-28
摘要： superpowers 不是一个普通的 Prompt 仓库，而是一套面向 AI Coding Agent 的工程化工作流系统。本文基于对仓库核心 skills、平台配置文件和工作流设计的系统阅读，梳理它如何通过 brainstorming、planning、TDD、debugging、review、verification 和多代理协作，把 AI 从“会写代码”进一步约束为“按流程做开发”的协作伙伴。
项目地址： github.com/obra/superp…
superpowers 值得专门写一篇解读最近在看 AI Coding Agent 相关的开源项目时，我注意到了 obra/superpowers 这个仓库。
最初吸引我的，不是它有没有某个炫酷功能，而是它在试图解决一个更本质的问题：当 AI 真正参与软件开发时，我们到底该怎样约束它、组织它、使用它？
很多时候，我们会把 AI 当成一个“更快的程序员”。但真正用久了就会发现，AI 最大的问题往往不是不会写代码，而是缺少稳定的工程纪律。比如：
而 superpowers 做的事情，就是把这些原本依赖资深工程师经验把控的研发纪律，拆解成一组可发现、可调用、可组合的 skills，让 AI 不只是“会写代码”，而是“按流程做开发”。
所以在我看来，这个仓库最有价值的地方，并不是它教会模型某个具体技巧，而是它在尝试建立一套面向 AI Coding Agent 的研发工作流。
如果把普通 Prompt Engineering 理解成“怎么让模型更会答题”，那么 superpowers 更像是在做另一件事：
怎么让模型进入一种更接近真实工程团队的工作方式。
这也是我觉得这个项目值得认真读一遍、并且值得专门写成文章的原因。
从仓库 README.md 的介绍来看，superpowers 的官方定位非常明确：
Superpowers is a complete software development workflow for your coding agents.
也就是说，它不是单点能力增强，而是一套完整的软件开发工作流。
这个仓库面向的是 Claude Code、Cursor、Codex、OpenCode、Gemini CLI 等 AI 编码平台。它不是直接给开发者提供一个按钮或页面，而是给这些“会写代码的 AI 代理”提供一套可调用的技能系统。
从仓库里的配置文件可以看到这一点：
.claude-plugin/plugin.json.cursor-plugin/plugin.jsongemini-extension.json.codex/INSTALL.md.opencode/INSTALL.mdGEMINI.md这说明作者一开始就不是按单平台来设计，而是按“跨平台 Agent 技能分发系统”来设计的。
这个仓库最重要的目录不是 src/、app/、components/ 之类，而是：
skills/agents/commands/hooks/其中最关键的是 skills/。
每个 skill 基本都是一个结构化的 Markdown 文件，里面包含：
所以从本质上说，superpowers 更像是：
一个把工程 最佳实践 封装成可发现、可调用、可组合“技能模块”的仓库。
如果你经常使用 AI Coding Agent，大概率都见过这些问题：
你说“帮我做个功能”，AI 经常直接开始实现，甚至还没搞清楚你的真正需求。
看到报错以后，很多模型会直接给出“可能是这里有问题，改一下试试”的建议，但并没有真正定位根因。
不少时候，AI 改完代码就开始说“现在应该可以了”“问题已经修复”，但它并没有真正跑测试，也没有拿到证据。
稍复杂一点的需求，如果不先拆任务，AI 很容易出现：
当平台支持子代理、多代理并发时，如果没有流程约束，很容易出现：
而 superpowers 的思路是：
不要期待模型天然具备稳定的工程纪律，而要把这些纪律写成规则、技能和流程，让它“被迫遵守”。
这正是这个仓库最有意思的地方。
先看仓库的核心组成。
README.md项目的总说明文件，介绍了：
package.json这个文件非常简洁：
{
"name": "superpowers",
"version": "5.0.6",
"type": "module",
"main": ".opencode/plugins/superpowers.js"
}
这也从侧面说明：
package.json 在这里只承担很轻量的插件入口声明作用我重点看了以下几个文件：
.claude-plugin/plugin.json.cursor-plugin/plugin.jsongemini-extension.jsonGEMINI.mdhooks/hooks.json这些文件分别承担：
举个例子，.cursor-plugin/plugin.json 中明确声明了：
skills: ./skills/agents: ./agents/commands: ./commands/hooks: ./hooks/hooks-cursor.json这意味着：
在 Cursor 这类平台里，superpowers 其实是一组“平台可识别的结构化能力模块”。
skills/仓库真正的灵魂所在。
我这次系统阅读了 skills/ 目录下的全部核心 SKILL.md 文件，包括：
using-superpowersbrainstormingwriting-planstest-driven-developmentsystematic-debuggingsubagent-driven-developmentexecuting-plansdispatching-parallel-agentsrequesting-code-reviewreceiving-code-reviewusing-git-worktreesverification-before-completionfinishing-a-development-branchwriting-skills这些 skill 共同构成了一整套开发工作流。
agents/这里定义一些专门角色，例如：
agents/code-reviewer.md它本质上是一个“高级代码审查员”角色说明，用于在某些技能流程里被当作子代理调用。
commands/这里放的是快捷命令入口，例如：
brainstorm.mdwrite-plan.mdexecute-plan.md其中有些命令已经被标记为 deprecated，说明作者在逐步把“命令式入口”收敛到“技能式入口”。
hooks/这里主要是会话启动钩子。比如 hooks/hooks.json 中定义了 SessionStart 时触发的命令。
这意味着 superpowers 并不是只有“手动使用技能”这一个入口，它还在尝试通过 hook 把一些行为前置到会话生命周期里。
docs/这里包括：
这部分对于理解项目如何跨平台运行非常有帮助。
tests/我阅读了 tests/claude-code/README.md，它说明了项目是如何测试 skills 行为的。
这点很重要，因为它表明作者并没有把技能当成“不可验证的文字说明”，而是在尝试让它们也具备可测试性。
这是我阅读后最强烈的感受之一。
很多人理解 Prompt Engineering，还是停留在“写几段提示词”的层面。但在 superpowers 里，Prompt 已经被进一步工程化了。
以 SKILL.md 为例，开头通常会写：
---
name: using-superpowers
description: Use when starting any conversation...
---
这里的 name 和 description 并不是装饰，它们是平台进行技能发现与匹配的重要依据。
在 writing-skills/SKILL.md 里，作者反复强调一件事：
因为一旦 description 直接总结了流程，模型可能只看 description，不认真读取 skill 正文。
这个细节非常值得写进文章，因为它揭示了一个很真实的 Prompt Engineering 问题：
模型会走捷径，因此提示词设计不仅要表达规则，还要防止模型误读规则。
这些 skill 不是普通文档，它们承担的作用更像：
所以比起“提示词仓库”，我更愿意把 superpowers 理解成：
AI Coding Agent 的行为操作系统。
在具体解读各个 skill 之前，先把 superpowers 的主流程放在前面，这样后面的阅读顺序会更清晰。
按照我对 README 和全部核心 skill 的梳理，它的完整工作流大致可以分成下面几个阶段：
会话开始
↓
using-superpowers：先判断该用哪些 skill
↓
需求澄清与设计
↓
brainstorming：理解上下文、提问、比较方案、形成 spec
↓
准备实施
↓
using-git-worktrees：创建隔离工作区，验证基线
↓
writing-plans：把 spec 写成详细实施计划
↓
选择执行方式
↓
subagent-driven-development / executing-plans
↓
实现中的纪律约束
├─ test-driven-development：先测后写
├─ systematic-debugging：遇到问题先查根因
├─ requesting-code-review：完成后请求审查
├─ receiving-code-review：理性处理反馈
├─ dispatching-parallel-agents：独立问题可并行派发
└─ verification-before-completion：没有验证就不能宣称完成
↓
收尾阶段
↓
finishing-a-development-branch：测试、合并、PR、保留或丢弃分支
↓
能力演进
↓
writing-skills：把新的有效方法沉淀成 skill
从这个结构里可以看出，superpowers 并不是把 skill 零散堆在一起，而是在试图构建一条完整的、可复用的软件研发流水线。
接下来，我就按照这条工作流来依次解读各个核心 skill。
using-superpowers —— 先决定流程，再开始行动如果把整套系统比作一个研发流程框架，那么 using-superpowers 就是它的总控开关。
这个 skill 的核心要求非常激进：
也就是说，它不允许模型靠“直觉”直接进入执行状态。
作者在这个 skill 里把很多常见想法都列成 red flags，比如：
这些在人类开发者看来很正常，但在作者眼里，这些往往意味着模型正在绕开流程。
我觉得 using-superpowers 的价值在于，它不是给 AI 更多选择，而是在收紧 AI 的自由度。
只要系统里存在合适的方法论，就不能靠即兴发挥跳过去。
这正是整套 superpowers 能成立的前提。没有这个总控 skill，后面的其他 skills 很容易沦为“存在但不使用”的摆设。
brainstorming —— 先把需求讲清楚，再进入实现在 using-superpowers 判断出这是一项需要设计和实现的任务后，最先进入的核心 skill 就是 brainstorming。
这个 skill 明确要求：
也就是说，它不是“边问边写代码”，而是“先设计，再谈实现”。
我觉得这个 skill 很成熟的一点是，它连“提问姿势”都规范了：
这说明作者很清楚：
需求澄清不是随便问几个问题，而是一种需要被设计的交互过程。
这点很关键。
很多 AI 对话在需求聊清楚后就结束了，但 brainstorming 要求把结果落地成文档。这样做有两个好处：
writing-plans 有了稳定输入所以这个 skill 更像是从“对话式需求”走向“文档化设计”的桥梁。
using-git-worktrees —— 在隔离环境里启动实施设计确认后，superpowers 并不是马上开始写代码，而是先进入工作区准备阶段。这一步由 using-git-worktrees 负责。
因为作者认为，正式开始实现前，必须先保证：
这其实是一个非常典型的工程化动作，只是很多 AI 工具默认不会主动做。
它会引导代理：
.worktrees/ 或 worktrees/.gitignore 忽略我觉得它非常像一个团队里的“开工前检查清单”。
它的重点不在“Git worktree 这个功能新不新”，而在于：
正式实施之前，要先把隔离环境和验证基线搭好。
这会让后续开发、调试和收尾都更清晰。
writing-plans —— 把 spec 写成可执行施工图完成设计并建立隔离工作区之后，下一步就是 writing-plans。
这个 skill 不只是让 AI 列个待办清单，而是要求它产出一份极度具体的实施计划，包括：
因为作者默认执行代理有这些特点：
所以 writing-plans 的本质是：
在执行之前，尽可能消灭模糊空间。
没有这份详细计划，后面的：
都很容易失去统一坐标。
所以在整个工作流里，writing-plans 可以说是“从设计走向实施”的关键枢纽。
subagent-driven-development 与 executing-plans到这一步，设计、工作区、实施计划都准备好了，才真正进入“干活阶段”。但 superpowers 并没有只提供一种执行方式，而是提供了两条不同的执行路径。
subagent-driven-development：更推荐的主路径这是整个仓库里最有代表性的 skill 之一。
它的思路是：
因为它体现的不是“AI 更聪明”，而是“AI 更像一个有分工的团队”。
作者特别强调：
这一点让我觉得非常成熟。它已经不是单 agent 编码，而是流程化的多代理协作。
executing-plans：没有子代理时的替代路径如果平台不支持子代理，或者当前就想在本会话里执行，也可以走 executing-plans。
它的要求是：
finishing-a-development-branch也就是说，它虽然没有多代理那种精细流水线，但仍然遵守“先计划、再执行、最后收尾”的主逻辑。
我觉得可以这样理解：
subagent-driven-development 更像“团队协作模式”executing-plans 更像“单人按施工图施工”前者质量更高、结构更完整；后者更通用，但精度略低。
test-driven-development —— 先写失败测试，再写实现进入真正实现阶段后，第一个非常关键的纪律 skill 就是 test-driven-development。
它反复强调：
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
也就是说，没有先失败的测试，就不允许写生产代码。
它在压制的是人类和 AI 共同的一个冲动：
而这个 skill 的态度非常坚决：
因为真正开始写代码后，模型最容易滑回“先实现再说”的惯性。
所以这个 skill 的存在，本质上是在整个执行过程中不断提醒：
你不是在证明自己会写代码，而是在证明你的代码真的被测试约束住了。
systematic-debugging —— 一旦出问题，先查根因真实开发不可能一路顺滑，因此在执行阶段，另一个非常关键的 skill 就是 systematic-debugging。
这个 skill 的核心原则是：
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
它要求模型在遇到 bug、测试失败、意外行为时，按四个阶段走：
因为只要开始写代码，就一定会遇到：
而这时候，如果没有调试纪律，模型最容易做的就是拍脑袋给修复建议。
test-driven-development 约束“怎么开始实现”systematic-debugging 约束“出问题时怎么处理”前者防止无测试实现，后者防止无证据修复。
这两个 skill 放在一起，基本构成了 superpowers 在执行阶段的底层纪律框架。
requesting-code-review 与 receiving-code-review代码写完不代表流程结束，superpowers 还把 review 做成了明确的两步机制。
requesting-code-review：主动发起审查这个 skill 负责的不是“顺便看一眼”，而是结构化地发起 code review。
它要求：
这说明作者并不把 review 看成一件模糊的事，而是认为：
review 的质量，很大程度取决于 review 输入是否被结构化。
receiving-code-review：收到意见后不能表演式认同这个 skill 我个人非常喜欢，因为它很少见。
它要求模型在收到 review 后：
它甚至明确反对这种表达：
原因很简单：
review 不是情绪表演，而是技术判断。
也就是说，superpowers 不只是规范“怎么提审”，还规范“怎么接审”。
这让整个执行流程更像真实工程团队，而不是“AI 自己写、自己夸、自己结束”。
dispatching-parallel-agents —— 独立问题才适合并发处理并不是所有任务都必须串行执行。
在一些场景下，比如：
superpowers 会建议使用 dispatching-parallel-agents。
这个 skill 最重要的判断标准是：
如果相关，就不要并行；如果独立，就一域一个代理。
很多所谓的多 agent 工作流，只强调“并行更快”。
但 dispatching-parallel-agents 更强调的是：
不是能并发就该并发，而是只有在问题真正独立时，并发才是增益。
这说明 superpowers 并不是把多代理当噱头，而是把它当工程上的调度策略。
verification-before-completion —— 没有验证证据，就不能说完成在我看来，verification-before-completion 是整个仓库价值观最鲜明的一个 skill。
这个 skill 的铁律是：
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
翻译过来就是：
如果你没有在当前这条消息对应的上下文里跑过验证命令，就不能说“完成了”“修好了”“通过了”。
比如这些话：
在人类看来这可能只是口头语，但在工程语境里，这类表达其实会直接伤害信任。
所以这个 skill 明确要求：
这一点非常重要。
因为很多时候，不是 AI 不会干活，而是它太容易在没证据时做出“完成姿态”。
而 verification-before-completion 的作用，就是让“完成”这句话必须有证据托底。
finishing-a-development-branch —— 正式收尾，而不是一句“搞定了”当实现、调试、review、验证都走完之后，才轮到 finishing-a-development-branch。
这个 skill 要求先做一件事：
然后再给用户四种明确选项：
因为很多 AI 工具在最后一步往往只有一句话：
但真实开发里，完成实现不等于完成研发流程。
你还得决定：
而 finishing-a-development-branch 正是在把这些真实研发动作显式化。
它不是把“写完代码”当终点，而是把“完成一次标准研发交付动作”当终点。
这是我觉得这个项目很有意思的地方之一。
writing-skills —— 把有效经验反过来沉淀成新的 skill前面的所有 skill，解决的是“如何使用 superpowers 做开发”。而 writing-skills 解决的问题更偏向元层：
如果我们发现一种新的有效方法，应该怎样把它写成新的 skill？
这个 skill 明确提出：
例如：
description 只描述何时使用我觉得这是这个仓库特别值得学习的一点。
因为它意味着：
这已经非常接近软件工程思维了。
这一节作为“使用演示模块”，方便后续插截图。你完全可以在这里补上 Claude Code、Cursor 或其他平台中的真实对话截图、计划截图、执行截图。
/plugin marketplace add obra/superpowers-marketplace
注册插件市场
/plugin install superpowers@superpowers-marketplace
从此市场安装插件
https://github.com/obra/superpowers
我已经安装好该插件了，请你向我介绍如何使用
查看该插件功能
● Skill(superpowers:using-superpowers)
⎿ Successfully loaded skill
● Bash(:)
⎿ (No output)
● 好的，我已经通过 superpowers:using-superpowers skill 了解了整套体系。现在为你介绍 Superpowers 插件的使用方法。
--- Superpowers 是什么
Superpowers 是一套由 @obra 开发的 Claude Code
插件系统，它为你提供了一系列结构化、强制性的工作流程技能，确保在开发过程中遵循最佳实践。
---
核心原则（Important）
Superpowers 有一个不可协商的铁律：
只要有 1% 的可能性某个 skill 适用，就必须使用它。
这意味着它强制你在做以下事情前，先调用对应的 skill：
┌───────────────────┬─────────────────────────────────────────────────────────┐
│ 场景 │ 必须先调用的 Skill │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 任何创意/开发工作 │ superpowers:brainstorming │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 写代码前 │ superpowers:test-driven-development │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 修复 Bug │ superpowers:systematic-debugging │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 多步骤实现 │ superpowers:writing-plans → superpowers:executing-plans │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 子代理并行开发 │ superpowers:dispatching-parallel-agents │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 完成工作前 │ superpowers:verification-before-completion │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 接受代码审查 │ superpowers:receiving-code-review │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 代码审查他人 │ superpowers:requesting-code-review │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ 创建/修改 skill │ superpowers:writing-skills │
├───────────────────┼─────────────────────────────────────────────────────────┤
│ Git Worktrees │ superpowers:using-git-worktrees │
└───────────────────┴─────────────────────────────────────────────────────────┘
---
已安装的 Skills 列表
根据系统显示，你现在可以使用以下 skills：
流程类（Process Skills）
- superpowers:brainstorming - 任何创意工作前必须调用
- superpowers:systematic-debugging - 调试 Bug
- superpowers:writing-plans - 编写实现计划
- superpowers:executing-plans - 执行计划
- superpowers:subagent-driven-development - 子代理驱动开发
- superpowers:dispatching-parallel-agents - 并行子代理
验证类
- superpowers:test-driven-development - 测试驱动开发
- superpowers:verification-before-completion - 完成前验证
- superpowers:requesting-code-review - 请求代码审查
- superpowers:receiving-code-review - 接受代码审查
Git 相关
- superpowers:using-git-worktrees - 使用 Git Worktrees
- superpowers:finishing-a-development-branch - 完成开发分支
工具类
- superpowers:writing-skills - 编写 skills
---
基本使用方式
方式一：直接调用 Skill
/skill superpowers:brainstorming
或带参数：
/skill superpowers:writing-plans "构建用户登录系统"
方式二：使用快捷命令
Superpowers 提供了一系列快捷命令：
┌─────────────┬────────────────────┐
│ 命令 │ 作用 │
├─────────────┼────────────────────┤
│ /brainstorm │ 启动头脑风暴 │
├─────────────┼────────────────────┤
│ /plan │ 创建实现计划 │
├─────────────┼────────────────────┤
│ /execute │ 执行计划 │
├─────────────┼────────────────────┤
│ /tdd │ 测试驱动开发 │
├─────────────┼────────────────────┤
│ /debug │ 系统调试 │
├─────────────┼────────────────────┤
│ /review │ 请求代码审查 │
├─────────────┼────────────────────┤
│ /verify │ 完成前验证 │
├─────────────┼────────────────────┤
│ /worktree │ 使用 Git Worktrees │
└─────────────┴────────────────────┘
---
使用流程示例
场景：我要开发一个新功能
Step 1: 头脑风暴
/skill superpowers:brainstorming
→ 它会引导你探索需求、明确意图
Step 2: 制定计划（如果需要多步骤）
/skill superpowers:writing-plans
→ 它会帮你创建详细的实现计划
Step 3: 执行计划
/skill superpowers:executing-plans
→ 它会按步骤执行，并设置检查点
Step 4: 完成前验证
/skill superpowers:verification-before-completion
→ 确保所有测试通过、代码质量达标
Step 5: 代码审查
/skill superpowers:requesting-code-review
---
关键约束
1. 技能优先：做任何事之前，先检查是否有对应的 skill
2. 顺序执行：多个 skill 冲突时，先执行流程 skills，再执行实现 skills
3. 禁止绕过：不能"随便先看一下"再调用 skill，必须先调用
4. 用户指令最高：如果 CLAUDE.md 和 skill 冲突，听用户的
---
你现在可以做什么
试试运行：
/skill superpowers:using-superpowers --help
或者查看更多 skill 的细节：
/skill superpowers:brainstorming
这就是 Superpowers 的核心使用方法——强制纪律、结构化流程、确保质量。
Brewed for 1m 47s
using-superpowersAI 会先判断：这个任务是否涉及设计、计划、实现、测试、review。
brainstormingAI 会开始问：
它还可能提出多种方案，例如：
然后形成一份 spec。
using-git-worktreesAI 会为这次任务建立隔离工作区，并确认当前测试基线是否通过。
writing-plansAI 会把“登录失败重试机制”拆成一系列可执行任务，比如：
这里通常会有两种路线：
subagent-driven-development：每个任务交给独立子代理执行executing-plans：在当前会话里按计划逐步执行例如：
test-driven-developmentsystematic-debuggingrequesting-code-reviewreceiving-code-reviewverification-before-completionfinishing-a-development-branch最后 AI 不会直接说“完成了”，而是会：
这也是我认为 superpowers 很值得学习的一点。
根据仓库内容，它至少覆盖了：
通过 ~/.agents/skills/ 的发现机制和符号链接接入。
通过 plugin 数组注册，并用 hook 把技能目录和上下文注入进去。
通过插件 marketplace 元数据接入。
通过 GEMINI.md 指定上下文文件。
作者没有把 skill 与某个平台深度耦合，而是尽量抽象成：
然后在不同平台上做轻量适配。
这很像软件工程里“核心逻辑与运行时适配分层”的思路。
读完之后，我觉得 superpowers 最值得学习的，不是某条具体 skill，而是以下五点。
不是几段提示词，而是：
整个仓库几乎都在围绕这些弱点设计：
这个项目传达出的一个很强烈的信号是：
提升 AI 编码质量，不一定靠更强的模型，也可以靠更强的流程。
不是“有多个 agent 就厉害”，而是：
都有明确原则。
无论是 TDD、debugging、verification，还是 code review，底层都在强调同一件事：
这其实是很典型的工程思维。
当然，superpowers 也不是没有代价。
这是最明显的。
从 brainstorming 到 spec，再到 worktree、plan、子代理、review、finish，整个链路比普通聊天式编码重得多。
对于简单任务，很多人会觉得它太“官僚”。
比如：
这会直接影响 superpowers 的使用效果。
如果你的开发方式更偏：
那这套流程可能会让你觉得被束缚。
当规则非常细时，模型虽然更不容易乱来，但也可能变得：
所以它本质上是一种取舍：
用灵活性换稳定性，用速度换可控性。
如果只把这个项目看成“一个给 Claude/Cursor 用的增强仓库”，其实会低估它。
我更愿意把它理解成：
一套针对 AI Coding Agent 的流程治理实验。
它的启发不在于某条规则本身，而在于它回答了一个更重要的问题：
作者给出的答案是：
这套设计说明，未来的 AI 编码工具竞争，可能不只是模型参数的竞争，也包括：
从这个意义上说，superpowers 的价值已经不只是“好不好用”，而是“它揭示了下一阶段 Agent 工程的一种方向”。
如果你是前端、后端、全栈，甚至只是一个经常使用 AI 编码助手的开发者，我都觉得这个仓库值得读。
原因不一定是因为你会原封不动采用它的所有流程，而是因为它能帮你重新思考这几个问题：
对我来说，superpowers 最值得学习的地方，不是它把某个模型“变得更聪明”，而是它试图把模型“变得更守规矩”。
而在工程世界里，很多时候：
守规矩，往往比自作聪明更重要。
