Superpowers：31 万星的 Markdown，教 agent 先别写代码

这周 GitHub 趋势榜上星最多的仓库不是模型，不是框架，也不是哪家创业公司的开源引流品。它是一个文件夹，里面全是 Markdown，告诉你的 coding agent 该怎么做事。

Jesse Vincent 的 Superpowers 大约 31.1 万星，过去一周涨了约 5,900。它自己的描述是：给 coding agent 的一套完整软件开发方法论，建立在一组可组合的 skill 之上，再加一些开场指令，确保 agent 真的会用它们。

一套方法论拿到三十万星，看着有点怪。要么是十年来最大的一批开发者同时决定他们想要流程，要么是星标按钮已经变成了“这个我以后得想想”的书签。大概两者都有。但这东西本身值得认真对待，因为对“agent 在写代码之前该做什么”这个问题，它是目前最有个性的答案。

第一步是不要开始

README 描述的工作流是这样。agent 一看出你在做东西，不会直接跳进写代码。它退一步，先问你到底想干什么。

等它从对话里抠出一份 spec，会分块给你看，每块短到能读完。不是一整墙需求。是分块。你点头之后，它产出一份实现计划，按 README 的说法，详细到“一个热情很高、品味很差、没有判断力、不了解项目背景、还讨厌测试的初级工程师”也能照着做。

这句话是这个仓库里最好的东西。它也是对 LLM 状态不好那天的精确描述，而按这个读者去写计划，是一种大多数工程师会跳过的纪律，因为我们默认读者和自己共享背景。

然后你说开始，它就进入子 agent 驱动的开发：agent 逐个任务推进，检查并评审自己的工作，继续往下。README 说 agent 连续自主工作几个小时而不偏离计划，并不罕见。

盒子里到底有什么

十五个左右的 skill，按功能分组。

测试只有一个条目，就是最关键的那个：test-driven-development，红-绿-重构循环，外加一份测试反模式的参考文档。调试有 systematic-debugging，一个四阶段的根因流程，带追踪技巧、纵深防御和基于条件的等待，还有 verification-before-completion，它唯一的职责是不让 agent 在东西还没修好的时候宣布胜利。

协作是真正吃重的地方：brainstorming 把意图挖出来，writing-plans、executing-plans、dispatching-parallel-agents、请求和接收代码评审、using-git-worktrees、finishing-a-development-branch，以及带两段式评审的 subagent-driven-development——先看是否符合 spec，再看代码质量。

两个元 skill 把环闭上：writing-skills 用来写新的，using-superpowers 是那段开场，提示模型在对话开始时就加载这套系统。因为 skill 是自动触发的，理论上你什么都不用记。agent 自己就有。

安装：按 harness 来，装十六遍

这部分能告诉你 agent 工具市场碎成什么样了。Superpowers 给了 Claude Code、Antigravity、Codex 应用和 CLI、Cursor、Devin CLI、Factory Droid、Gemini CLI、GitHub Copilot CLI、Grok Build、Kimi Code、OpenCode、Pi、Qwen Code、Hermes 和 Muse 的安装说明。

Claude Code，走官方市场：

/plugin install superpowers@claude-plugins-official

或者走 Vincent 自己的市场：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Cursor，在 agent 对话里：/add-plugin superpowers。Gemini CLI：gemini extensions install https://github.com/obra/superpowers。Copilot CLI：先注册市场，再 copilot plugin install superpowers@superpowers-marketplace。Antigravity：agy plugin install https://github.com/obra/superpowers。Devin：devin plugins install obra/superpowers。Factory Droid：注册，然后装。Codex 应用和 CLI 都走官方插件市场。

如果你用不止一个 harness，就得每个都单独装一遍。也就是说同一批 skill 存在十二份副本，没有共享的更新路径，而 README 对更新的建议是“多少取决于 coding agent，但通常是自动的”。这不是对这个项目的批评。这就是生态的现状，而看一个方法论仓库怎么应付它，本身就挺有信息量。

贡献政策才是露底的地方

贡献那一节里埋着：一般不接受新 skill 的贡献；对 skill 的更新必须在所有支持的 agent 上都能用；不接受 agent 写的、去修别人提的 issue 的 PR，除非维护者要求过——哪怕你自己也撞上了同一个问题。

想想最后那条是干什么用的。这类仓库最明显的失败模式，就是被一堆看起来很像那么回事的 skill 淹没，而那些 skill 恰恰是这些 skill 本该管住的 agent 生成的。Vincent 预见到了，提前堵上，代价是看起来不太友好。

这还有个更微妙的含义。如果你的 agent 能为任何事生成一个 skill，稀缺资源就不再是 skill，而是判断哪些 skill 值得要。那个判断才是这个仓库真正在卖的东西，而它不接受 PR。

方法论在哪里断掉

四点，按我见到它们咬人的频率排。

流程修不了品味。一个执行得完美的计划，用在一个想错了的功能上，产出的是一个测试充分、方向错误的东西。brainstorming 这个 skill 靠追问你真正想要什么来帮忙，但它不会告诉你这个点子很无聊。

token 经济。spec、分块评审、计划、子 agent 派发、每个任务两段评审、完成前验证。在个小任务上，这是惊人的开销。这套方法论是为以天计的工作设计的，用在一行修复上会显得荒谬。

计划会漂。对着第零分钟写下的计划自主干两小时，如果计划本来是对的就没问题。当第三个任务暴露出第二个任务建立在错误假设上，你得到的是两小时方向错误的自信工作，而评审是挡在你和一份巨大 diff 之间的唯一东西。

还有最诚实的一点：skill 就是 prompt，而 prompt 只是建议。这里的一切都取决于模型选择遵守这个 skill，而不是它同时知道的另外五件事。这也是为什么要有 using-superpowers 这么一个引导——它是一段 prompt，职责是让别的 prompt 被加载。

这是给谁用的

如果你在发布别人依赖的代码，而且你见过 agent 信誓旦旦地把没做完的事标成完成，这是一套合理的护栏，试一次只要一条命令。先从 test-driven-development 和 verification-before-completion 开始，其余一周内别管。这两个最能改变行为。

如果你在做原型，跳过。这套方法论是为“不发布垃圾”优化的，而那是和“这想法行不行”完全不同的目标。

三十万星不是对这套方法论的判决，是对这个时刻的判决：很多人手上的 agent 写代码比他们能监督的速度还快，他们在找能让监督变便宜的东西。Superpowers 是一个答案。它由 Markdown 构成，这才是最有意思的地方。