夜雨聆风
它火的不是“提示词”，而是反人性的流程门禁
最近看 AI Coding 生态，很容易看到一类仓库：skills、hooks、commands、agents、memory、MCP 配置，全都打包成“让 Claude Code / Codex / OpenCode 更强”的工具箱。
这些仓库有流量，也容易被误读。
最常见的误读是：
是不是把这些提示词复制进本机，Agent 就会变强？看 Superpowers 源码之前，我也以为它大概率是一个更强势的 Prompt Pack。
读完以后，我觉得这个判断不准。
Superpowers 的核心不是“写了几段更聪明的提示词”，而是把 AI Coding 里最容易失控的几件事，改写成一套强制流程：
先想清楚需求再写设计再拆计划再实现实现时先测完成前验证重要节点要 review最后再决定怎么合并这套流程看起来像常识。
但 AI Coding 最容易翻车的地方，恰好就是常识失效。
模型会急着写代码。
模型会把讨论稿当设计稿。
模型会跳过失败复现。
模型会说“应该好了”，但没跑验证。
模型会在一个大上下文里越做越乱。
Superpowers 做的事，就是把这些“人类工程师本来应该坚持的纪律”，变成 Agent 每一步都能触发的技能合同。
这也是它值得写源码解析的原因。
它不是一个工具推荐问题。
它是一个 Agent Harness 设计问题：
怎么让一个会写代码的模型，按软件工程流程工作？先看仓库形态：它不是一个 App，而是一套插件化流程系统
obra/superpowers 在 GitHub 页面显示已经是二十万 star 级别的仓库。这个数字会变，真正重要的不是 star，而是仓库结构。
本地安装的版本是 5.1.0，对应代码里能看到这几个关键入口：
.codex-plugin/plugin.json.claude-plugin/plugin.json.cursor-plugin/plugin.json.opencode/plugins/superpowers.jshooks/session-startskills/*/SKILL.mdREADME.mdtests/*README.md 对项目的定义很直白：Superpowers 是一套给 coding agents 用的软件开发方法论，建立在一组可组合 skills 和初始指令之上。
这句话要拆开看。
第一，它不是单宿主项目。
README 里列了 Claude Code、Codex CLI、Codex App、Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI 等入口。也就是说，Superpowers 不是绑定某一个 IDE 或 CLI 的业务应用。
它更像一个“方法论插件包”。
不同宿主负责加载插件、发现 skills、提供工具能力；Superpowers 负责把 Agent 的行为导向一条工程流程。
第二，它把能力放在 skills/，不是放在一个大 prompt。
本地 skills/ 下有 14 个 SKILL.md：
brainstormingwriting-planstest-driven-developmentsystematic-debuggingverification-before-completionsubagent-driven-developmentrequesting-code-reviewreceiving-code-reviewusing-git-worktreesexecuting-plansdispatching-parallel-agentsfinishing-a-development-branchwriting-skillsusing-superpowers这就是它和普通提示词合集的分水岭。
普通 prompt pack 往往是：
把规则都塞给模型希望模型记得希望模型照做Superpowers 的结构更像：
启动时注入一个入口技能入口技能要求先判断是否有相关 skill相关 skill 再按任务类型被加载每个 skill 只管一个流程问题这其实是“渐进式披露”。
不是一次性把所有规范塞进上下文，而是在任务需要时加载对应的流程合同。
插件层：先让宿主知道“我有 skills”
看 .codex-plugin/plugin.json，能看到几个关键信息：
{ "name": "superpowers", "version": "5.1.0", "description": "An agentic skills framework & software development methodology that works: planning, TDD, debugging, and collaboration workflows.", "skills": "./skills/", "interface": { "displayName": "Superpowers", "category": "Coding", "capabilities": [ "Interactive", "Read", "Write" ] }}这里最值得注意的是 skills: "./skills/"。
这意味着它不是只注册一个命令，也不是只给宿主塞一个系统提示词。
它把 skills/ 目录作为能力边界暴露给宿主。
宿主能发现这些技能，Agent 才能在不同任务里加载不同流程。
再看 OpenCode 适配代码 .opencode/plugins/superpowers.js，它做了两件很典型的事：
1. 把 Superpowers 的 skills 目录注入到 OpenCode config.skills.paths2. 在聊天消息 transform 阶段，把 using-superpowers 作为 bootstrap 放进第一条用户消息源码里有这样一段逻辑：
config: async (config) => { config.skills = config.skills || {}; config.skills.paths = config.skills.paths || []; if (!config.skills.paths.includes(superpowersSkillsDir)) { config.skills.paths.push(superpowersSkillsDir); }}这一步解决的是“技能发现”。
Agent 不可能凭空知道 skills/brainstorming/SKILL.md 在哪。插件必须先告诉宿主：这里有一组 skills。
第二步是 bootstrap。
OpenCode 适配代码会读取：
skills/using-superpowers/SKILL.md然后包进：
<EXTREMELY_IMPORTANT>You have superpowers....</EXTREMELY_IMPORTANT>再插到第一条用户消息前面。
这一步解决的是“入口激活”。
如果只注册 skills，但没有入口规则，模型可能根本不会主动想起要用。
所以 Superpowers 的插件层可以概括成两句话：
先让宿主发现 skills。再让 Agent 知道必须先查 skills。这就是它作为插件的最低层架构。
Bootstrap 层：using-superpowers是整个系统的总开关
真正的总开关不是 brainstorming，也不是 TDD，而是 using-superpowers。
这个 skill 的 frontmatter 很短：
name: using-superpowersdescription: Use when starting any conversation - establishes how to find and use skills但正文非常强硬。
它要求：
只要有 1% 可能有 skill 适用，就必须调用 skill。它还定义了指令优先级：
用户显式指令最高Superpowers skills 其次默认系统提示词最低这点很重要。
很多工作流类 prompt 最大的问题，是会和用户规则打架。
比如 skill 要求 TDD，但项目 AGENTS.md 说某类配置改动不需要 TDD，那到底听谁的？
using-superpowers 明确写了：用户控制权最高。
这让它不是一个“强行接管 Agent 的黑盒”，而是一个在用户规则下运行的流程约束层。
再看 Claude Code / Cursor 方向的 hook。
hooks/session-start 会读取 skills/using-superpowers/SKILL.md，然后根据当前宿主输出不同字段：
Cursor: additional_contextClaude Code: hookSpecificOutput.additionalContextCopilot CLI 或未知平台: additionalContext这段实现非常工程化。
同一个 bootstrap 内容，不同宿主需要不同注入字段。
Superpowers 没有假设所有 Agent 平台都有同一种插件协议，而是在适配层做了兼容。
这也是为什么我说它不是单纯 prompt pack。
它至少有三层：
插件元数据层会话注入层skills 流程层只有这三层连起来，Agent 才会从“知道有这些文档”，变成“每次任务都先检查流程”。
Skills 层：每个Skill.md都是一份流程合同
Superpowers 的 skills 不是知识库文章。
它们更像流程合同。
以 brainstorming 为例，它在 frontmatter 里写得很明确：
description: "You MUST use this before any creative work..."正文里有一个硬门禁：
在展示设计并获得用户确认前，不要写代码、不要 scaffold、不要进入实现动作。这不是普通建议。
它是在阻止 Agent 最常见的坏习惯：
用户说“我想做个功能”模型马上开始写文件中途才发现需求根本没对齐writing-plans 解决的是另一个问题：计划太粗。
它要求把任务拆成 2-5 分钟的小步骤，每一步包含：
具体文件路径具体代码具体验证命令预期输出这很反直觉。
很多人写计划喜欢写：
实现用户登录增加错误处理补充测试这种计划对人类高级工程师也许够用，但对 Agent 不够。
因为 Agent 最容易在模糊计划里自由发挥。
Superpowers 的做法是把计划写到几乎可以交给“没上下文但会照做的人”执行。
这就是 Agent 友好的计划。
再看 test-driven-development。
它不是说“建议先写测试”，而是写了铁律：
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST甚至规定：
如果先写了生产代码，就删除，重新从测试开始。这听起来有点极端。
但你把它放到 AI Coding 里，就能理解为什么要这么硬。
模型特别擅长直接给出看起来完整的实现。
一旦实现先出现，测试很容易变成“证明这段实现没错”的附属品，而不是定义行为的约束。
TDD skill 要打断的，正是这个顺序错误。
systematic-debugging 也类似。
它要求先做根因调查，再提修复方案：
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST这和人类工程事故很像。
线上 bug 来了以后，最危险的不是不会修，而是修得太快。
AI 更容易这样：看到报错，立刻猜一个原因，改一处代码，说“现在应该好了”。
Superpowers 把“别猜，先复现、读错误、追数据流、查最近变更”写进流程。
最后是 verification-before-completion。
它抓的是 AI Coding 里最常见的信任问题：
模型说完成了，但没有真实验证。这个 skill 的核心规则是：
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE也就是说，不能凭感觉说好了。
必须识别验证命令、运行、读输出、确认，再说完成。
到这里你会发现，Superpowers 的每个 skill 都在对抗一个具体坏习惯。
不是为了显得流程多。
而是因为 Agent 默认行为确实会跳过这些门禁。
工作流层：它把 AI Coding 压成一条流水线
把几个 skill 串起来看，Superpowers 的主工作流很清楚。
README 里列出的 Basic Workflow 是：
brainstormingusing-git-worktreeswriting-planssubagent-driven-development / executing-planstest-driven-developmentrequesting-code-reviewfinishing-a-development-branch这不是简单排序。
它对应一条软件交付链路：
想清楚要做什么隔离工作区写可执行计划分任务实现用测试约束实现中途 review完成前验证合并或保留分支这里面最有意思的是 subagent-driven-development。
它要求每个任务派发 fresh subagent，并且每个任务后有两阶段 review：
spec compliance reviewcode quality review它的解释很直接：子 Agent 不应该继承当前会话历史，你要精确构造它需要的上下文。
这个设计很重要。
很多长任务失败，不是因为模型不会写代码，而是因为上下文越来越脏：
前面的讨论中途的失败已经废弃的方案用户反复修正的要求工具输出里的噪声模型自己的猜测全部堆在一个上下文里，模型后面就会开始混。
fresh subagent 的价值，是把每个实现任务压成一个干净、局部、可 review 的执行单元。
这其实和我们写软件很像。
不要让一个函数做所有事。
也不要让一个 Agent 上下文背着所有历史做所有任务。
测试层：连“注入一次”这种细节都有测试
Superpowers 仓库里还有一层容易被忽略：测试。
比如 OpenCode 插件里有一个缓存逻辑：
let _bootstrapCache = undefined;getBootstrapContent() 第一次读取 using-superpowers/SKILL.md 后会缓存结果。
原因写在注释里：OpenCode 的 transform 可能在每个 agent step 触发，如果每次都 existsSync + readFileSync + regex，会重复做磁盘读取和解析。
对应测试在：
tests/opencode/test-bootstrap-caching.mjs这个测试会 monkey patch fs.existsSync 和 fs.readFileSync，统计读取次数，然后验证：
第一次 transform 注入一个 bootstrap part第二次 transform 不再重复读取 SKILL.mdmissing file 场景也会缓存 exists 结果这说明作者关心的不只是“提示词写得对不对”。
它关心插件作为运行时组件时的行为：
会不会重复注入？会不会每步重复读文件？missing file 会不会反复检查？还有一类测试在 tests/codex-plugin-sync/，覆盖把上游仓库同步到 Codex plugin 形态的脚本行为。
这对跨宿主插件很关键。
同一套 Superpowers 要同时跑在 Claude Code、Codex、OpenCode、Cursor 等环境里，光写 README 不够。
必须有同步和适配测试，否则某个宿主的 manifest 或目录结构很容易漂移。
这也是源码里能看到的一个工程判断：
跨 Agent 宿主的能力包，本质上是多平台插件。多平台插件最怕的不是 prompt 写错，而是加载、注入、同步和兼容行为漂移。它给我们的真正启发：Agent 能力要外置成工程系统
如果只把 Superpowers 当成“Claude Code 增强包”，收获会很浅。
真正值得学的是它的架构思想。
它把 Agent 能力拆成四层：
宿主层：Claude Code / Codex / OpenCode / Cursor插件层：manifest、marketplace、skills path、capabilities注入层：session-start hook、message transform、bootstrap context流程层：brainstorming、planning、TDD、debugging、review、verification这四层解决的问题完全不同。
宿主层解决“跑在哪里”。
插件层解决“能力怎么被发现”。
注入层解决“入口规则怎么生效”。
流程层解决“Agent 做事按什么纪律走”。
很多团队做内部 AI Coding 规范时，容易只做最后一层：
写一份 AGENTS.md写几条 prompt 规则让大家复制这能起一点作用，但不够稳定。
因为模型可能不加载，加载了也可能忘，忘了也没人拦。
更稳的做法应该接近 Superpowers：
规则要能被发现入口要能被注入流程要能被触发完成要有验证证据重要节点要能 review这就是从“提示词”到“Agent 工程系统”的差别。
普通开发者应该学什么，不该照搬什么
我不建议普通开发者一上来把所有 Superpowers 流程照单全收。
它很强，也很重。
尤其是 brainstorming 这种硬门禁，对一些小修小改会显得过度。
但它里面有几条非常值得拿走：
第一，别让 Agent 直接从想法跳到代码。
至少让它先写清楚：
目标非目标涉及文件验收条件风险点第二，计划要能执行，不要只是愿望清单。
好的 AI Coding plan 应该能回答：
改哪个文件？为什么改这里？先写哪个测试？运行什么命令？什么输出才算通过？第三，完成前必须有新鲜验证。
“看起来对了”不算。
“我觉得修好了”不算。
“模型说完成了”更不算。
至少要有一次真实的测试、构建、lint、页面行为或命令输出。
第四，长任务要切上下文。
如果一个任务已经变成：
设计 + 实现 + 排错 + 重构 + review + 继续修那就不要让一个上下文从头扛到尾。
拆任务、隔离上下文、分阶段 review，通常比堆长上下文更可靠。
第五，团队规范最好产品化，不要只写在文档里。
如果你的团队真的依赖 AI Coding，不要只写一句“请先跑测试”。
应该把它做成：
命令hookskill模板CI gatereview checklist文档是提醒。
系统才是约束。
最后：Superpowers 的本质，是给 Agent 加工程刹车
AI Coding 的第一阶段，大家都在比谁写得快。
这很正常。
模型第一次能改一整个文件、跑一个命令、修一个 bug 的时候，确实很爽。
但真正进入工程以后，快不是唯一问题。
更大的问题是：
它有没有想清楚？它有没有按计划？它有没有验证？它有没有把失败原因找对？它有没有在错误方向上越跑越远？Superpowers 的源码和架构说明了一件事：
Agent 能力不只来自模型。它还来自外部流程系统。模型负责生成和推理。
插件负责注入能力。
skills 负责约束行为。
hooks 负责启动门禁。
tests 负责防止插件行为漂移。
这才是 Superpowers 最值得看的地方。
它不是让 Agent 多几句“最佳实践”。
它是在给 Agent 加一套软件工程刹车系统。
对今天的 AI Coding 来说，这可能比再换一个更强模型更重要。
资料来源
官方仓库和源码
• obra/superpowersGitHub 仓库：https://github.com/obra/superpowers• Superpowers README： README.md• Codex 插件描述： .codex-plugin/plugin.json• OpenCode 插件适配： .opencode/plugins/superpowers.js• 会话启动 hook： hooks/session-start• Skills 目录： skills/*/SKILL.md• OpenCode bootstrap 缓存测试： tests/opencode/test-bootstrap-caching.mjs• Codex plugin 同步测试： tests/codex-plugin-sync/test-sync-to-codex-plugin.sh