25 万 Star 的 skill 框架，Jesse Vincent 把方法论做成了插件

大家好，我是若风。

Jesse Vincent 是个有意思的人。他做过 Perl 的邮件框架 Email::Sender，做过 RT(Request Tracker)工单系统，做过 Vershandy 手写笔记应用。2025 年 10 月，他在 GitHub 上传了一个叫 superpowers 的项目。

九个月后，252,734 个 Star。

一个全是 Markdown 文件和 Shell 脚本的仓库，凭什么？

一句话定位

Superpowers 是一套完整的软件开发方法论，被打包成 14 个可组合的 Agent Skills，通过 session-start hook 自动注入到你的 coding Agent(Claude Code、Codex、Cursor、Antigravity 等)里。它不是一个工具库，是一套强制执行的开发流程。

它到底在做什么

很多人第一次看 superpowers，以为它就是一堆 prompt 模板。翻进 skills/using-superpowers/SKILL.md,你会发现它的第一句话就非常强硬。

If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

不是建议，是必须。这个 Skill 定义了一张「红旗」表，列出 Agent 可能用来逃避使用 Skill 的所有借口，然后逐一打脸。「这只是个简单问题」「让我先看看代码库」「我记得这个 skill」——每一个都被标记为 rationalization(合理化逃避)。

这个设计的核心在于，它不信任 Agent 的「自由意志」。不是给 Agent 一堆工具让它自己选，而是用 Skill 自动触发机制，强迫 Agent 在做任何事之前先检查有没有适用的 Skill。

这是 superpowers 和其他 Skill 库的根本区别。大多数 Skill 库是可选菜单,superpowers 是强制流程。

14 个 Skill 怎么编排

打开 skills/ 目录，14 个 Skill 分成四组。

流程组(整个开发周期的骨架):

• brainstorming,开工前用苏格拉底式提问帮你把模糊想法磨成设计文档
• writing-plans,把设计拆成 2-5 分钟的细粒度任务，每个任务带确切文件路径和验证步骤
• executing-plans,批量执行任务，设人工检查点
• finishing-a-development-branch,收尾，合并或建 PR

执行组(核心创新):

• subagent-driven-development,这是整个框架的灵魂
• dispatching-parallel-agents,并发派发子 Agent

质量组:

• test-driven-development,强制 RED-GREEN-REFACTOR
• systematic-debugging,4 阶段根因分析
• requesting-code-review / receiving-code-review,任务间代码审查
• verification-before-completion,声明完成前必须验证

基建组:

• using-git-worktrees,用 git worktree 做隔离开发
• writing-skills,教你写新 Skill
• using-superpowers,Skill 系统的入门引导

这个编排不是随意排列的。brainstorming → writing-plans → subagent-driven-development → requesting-code-review → finishing-a-development-branch,构成了一条从「我有想法」到「代码合进主干」的完整流水线。

subagent-driven-development 为什么重要

skills/subagent-driven-development/SKILL.md 是这个框架最值得深挖的部分。它定义了一个非常清晰的循环。

每个任务的执行流程是，派遣一个全新的 implementer subagent(用 implementer-prompt.md 构造上下文),让它实现、测试、提交、自我审查。然后派遣一个独立的 task reviewer subagent(用 task-reviewer-prompt.md),做两阶段审查，先查 spec 合规性，再查代码质量。如果 reviewer 报了 Critical 或 Important 级别的问题，派遣 fix subagent 修复后重新审查。全部任务完成后，最后派遣一个 final reviewer 做全分支审查。

关键设计在于，每个 subagent 的上下文都是隔离的。implementer 不知道 reviewer 的存在，reviewer 不知道前一个任务的历史。你（主 Agent）负责构造每个 subagent 需要的确切上下文，而不是让它继承你的 session 历史。

为什么这么设计？因为 LLM 的上下文窗口是有限且有噪声的。如果 implementer 继承了你的全部 session 上下文，它会被无关信息干扰。给它一个干净的上下文 + 精确的任务描述，它的表现会比在长 session 里好得多。这同时也保护了主 Agent 的上下文，让你专注于协调而不是实现细节。

SKILL.md 里有一句话很关键，「Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration」。这不是三个功能的简单叠加，是一个乘法关系。隔离上下文保证了每个任务的执行质量，独立审查保证了代码质量，全分支审查保证了整体一致性。

还有一条硬规则藏在流程描述里，「Continuous execution，不要在任务之间停下来问人类」。全部任务一口气跑完，除非遇到 BLOCKED 状态、真正无法推进的歧义、或全部完成。这条规则直接打掉了 Agent 最浪费时间的行为，频繁问用户「要继续吗？」

session-start hook 怎么把一切串起来

hooks/session-start 是一个 Bash 脚本，它在 Agent session 启动的瞬间执行。脚本做了一件很聪明的事。

它读取 skills/using-superpowers/SKILL.md 的完整内容，做 JSON 转义（用 Bash 参数替换处理反斜杠、引号、换行、制表符），然后包装成一段 <EXTREMELY_IMPORTANT> 标签的上下文注入。关键是，它根据当前平台动态选择输出格式。

• Cursor 期望 additional_context(snake_case)
• Claude Code 期望 hookSpecificOutput.additionalContext(嵌套)
• Copilot CLI 期望 additionalContext(顶层，SDK 标准)

同一个 hook，适配三家平台的 API 差异。这就是为什么 superpowers 能同时支持 Claude Code、Cursor、Codex、Antigravity、Copilot CLI 等 10+ 个 Agent 平台。

using-superpowers 的内容被注入后，Agent 的第一条系统上下文里就有了「你必须先检查 skill」的指令。从这一刻起，Agent 做任何事之前都会先查 Skill 库。

这套机制的本质是，在不修改 Agent 核心代码的前提下，用 hook 注入改变 Agent 的行为模式。这是插件架构的力量。

TDD 铁律有多硬

skills/test-driven-development/SKILL.md 有一条 The Iron Law:

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

然后它写了这么一段，「Write code before the test? Delete it. Start over. No exceptions. Don’t keep it as “reference”. Don’t “adapt” it while writing tests. Don’t look at it. Delete means delete.」

如果你在写测试之前就写了实现代码，删掉它，从头来。不许留着当「参考」，不许「适配」，连看都不许看。

这种极端的措辞不是矫情。LLM Agent 的一个固有倾向是，一旦写了代码就会倾向于保留它、修修补补，而不是推翻重来。TDD Skill 用最强烈的措辞对抗这个倾向。

这种「用 skill 对抗 agent 的固有缺陷」的思路贯穿了整个框架。systematic-debugging 对抗 Agent 跳过根因分析直接打补丁的倾向，verification-before-completion 对抗 Agent 没验证就声明完成的倾向。

遥测和商业模式

README 里有一段很诚实的说明，关于 telemetry。superpowers 的 brainstorming Skill 有一个 optional 的视觉伴侣功能，会从 Prime Radiant(Jesse 的公司)的网站加载 logo。这个请求会带上版本号，不带你的项目信息、prompt 内容或任何交互数据。

你可以设置 SUPERPOWERS_DISABLE_TELEMETRY 环境变量关闭它。

这段说明的坦诚值得注意。很多开源项目偷偷收集遥测数据，superpowers 选择明确告知用户它在收集什么、怎么关。这可能和 Jesse 长期做开源社区（RT 工单系统活了 20 年）的经验有关，他懂得信任比数据更重要。

README 还提到了商业服务，企业用户可以通过 sales@primeradiant.com 获取商业支持、额外工具或托管服务。同时他们在招聘全职的 community engineer。这说明 superpowers 已经从个人项目走向公司化运营。

这套方法论适合你吗

说句实话，superpowers 不是万能的。issue #743 有 20 条评论，标题是「I’m seeing slowness in responses since using the skill」。强制 Skill 检查 + subagent 派遣带来了明显的延迟。对于快速原型、一次性脚本、探索性编程，这套流程太重了。

它真正适合的场景是，你在做一个需要长期维护的项目，代码质量比速度更重要，团队对 TDD 和 code review 有共识。这种场景下，superpowers 把「该做但经常偷懒不做的开发实践」变成了 Agent 的默认行为。

issue #429 有 21 条评论，请求支持 Claude Code Agent Teams(TeammateTool, SendMessage, TaskList),说明社区在推 superpowers 做更复杂的 multi-agent 协作。v6.1.1(2026-07-02)的迭代速度说明 Jesse 在认真维护这个项目。

带走什么

我觉得 superpowers 最值得思考的不是某个具体的 Skill，而是一个设计判断，把方法论编码为强制流程，而不是可选建议。

大多数开发工具的做法是，给你一堆最佳实践文档，读完是你的事。superpowers 做的是，把最佳实践变成 Agent 自动执行的流程，跳过「人类的惰性」这个中间环节。

brainstorming 不是建议你在开工前想想，是 Agent 在你还没开口之前就先问你到底想做什么。TDD 不是建议你写测试，是 Agent 在你写实现之前先删掉你已经写的代码。

这个思路可以迁移到很多场景。你团队的 code review 规范是不是变成了 Jira 里的模板？你的 CI/CD pipeline 是不是把部署手册变成了自动化脚本？superpowers 把这个模式推到了极致，从「人读文档执行流程」变成「agent 自动执行流程，人只需要审批」。

如果你在做 Agent 开发，不管用不用 superpowers，这个「方法论即代码」的思路值得认真想一下。14 个 Skill 的编排，本质上就是 14 个 if-then 规则，但组合起来产生了质变。这就是流程设计的力量。