31 萬顆星的一疊 Markdown：Superpowers 要 agent 先別急著寫程式

這週 GitHub 趨勢榜上星數最多的 repo，不是模型、不是框架，也不是哪家新創的開源誘餌。它是一個資料夾的 Markdown 檔，告訴你的 coding agent 該怎麼行為。

Jesse Vincent 的 Superpowers，大約 31.1 萬顆星、過去一週多了約 5,900 顆。它自己的描述是：一套給 coding agent 的完整軟體開發方法論，建立在一組可組合的 skill 上，外加一些確保 agent 真的會用它們的初始指令。

一套方法論拿到三十萬顆星，是看起來很怪的事。要嘛這十年來最大一批開發者同時決定他們想要流程，要嘛那顆星星按鈕已經變成「我之後該想想這件事」的書籤。大概兩者都有。但這東西本身值得認真看待，因為在「agent 寫程式之前該做什麼」這個問題上，它是目前最有意見的答案。

第一步是不開始

README 描述的流程是這樣。agent 一看到你在做東西，不會跳進寫程式。它會退一步，問你到底想幹嘛。

等它從對話裡逼出一份 spec，它會切成短到讀得完的段落給你看。不是一整面需求牆。是段落。你簽核之後，它產出一份實作計畫，用 README 的話說，詳細到「一個熱情有餘、品味不佳、沒有判斷力、沒有專案脈絡、又討厭測試的初階工程師」都能照著做。

那句話是這個 repo 裡最好的東西。它同時精準描述了 LLM 狀況不好時的樣子，而為那樣的讀者寫計畫，是多數工程師會跳過的紀律，因為我們假設讀者跟我們共享脈絡。

然後，你說 go 之後，它啟動 subagent 驅動的開發：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。

兩個 meta skill 收尾：writing-skills 用來建立新的 skill，using-superpowers 是那段開場白，提示模型在對話開始時載入整套系統。因為 skill 會自動觸發，理論上你什麼都不用記。你的 agent 就是有。

安裝：每個 harness 各一次，總共十六次

這部分告訴你 agent 工具市場碎到什麼程度。Superpowers 為 Claude Code、Antigravity、Codex app 與 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 app 和 CLI 都走官方外掛市集。

如果你用不只一個 harness，每個都要分開裝。也就是同一批十二個 skill 存在十二份副本，沒有共用的更新路徑，而 README 對更新的建議是「某種程度上取決於 coding agent，但通常是自動的」。這不是對這專案的批評。這是生態系的現況，而看一個方法論 repo 怎麼應付它，本身就很有資訊量。

貢獻政策才是線索

埋在貢獻那一節裡：他們一般不接受新 skill 的貢獻、skill 的更新必須在全部支援的 agent 上都能用，而且他們不接受由 agent 寫的、去修別人開的 issue 的 PR，除非有 maintainer 要求，即使你遇到同一個問題。

想想最後那條規則是為了什麼。這種 repo 顯而易見的壞法，是被那些「看起來很有道理」的 skill 淹沒——而產出它們的，正是這些 skill 要管的 agent。Vincent 看到它要來了，先擋住，代價是看起來不太友善。

它還有一個更細的含意。如果你的 agent 能為任何事生成一個 skill，稀缺的資源就不再是 skill，而是「哪些 skill 值得有」的判斷。那個判斷才是這個 repo 真正在賣的東西，而它不接受 pull request。

方法論會斷掉的地方

四件事，按我看過它們咬人的頻率排。

流程救不了品味。一個構想很糟的功能，計畫執行得再完美，也只是產出一個測試齊全的錯誤東西。brainstorming 這個 skill 靠問你真正想要什麼來幫忙，但它不會告訴你這個點子很無聊。

Token 經濟。Spec、分段審查、計畫、subagent 派工、每個任務兩階段審查、完成前驗證。在小任務上，這是驚人的開銷。這套方法論是為以「天」計的工作設計的，套在一行修正上會顯得荒謬。

計畫會漂。對著零分鐘時寫的計畫自主工作兩小時，在計畫是對的時候沒問題。當第三個任務揭露第二個建立在錯誤假設上，你會得到兩小時朝錯方向的自信工作，而審查是唯一擋在你和一份巨大 diff 之間的東西。

還有最誠實的一點：skill 就是 prompt，而 prompt 是建議。這裡的一切都取決於模型選擇照著 skill 走，而不是它同時也知道的另外五件事。這就是為什麼 using-superpowers 以 bootstrap 的形式存在——它是一個 prompt，職責是讓其他 prompt 被載入。

這是給誰的

如果你在出貨別人要依賴的程式碼，而且你看過 agent 很有自信地把沒做完的事標成完成，這是一組合理的護欄，試用成本一行指令。先從 test-driven-development 和 verification-before-completion 開始，其餘一週內都別管。這兩項對行為的改變最大。

如果你在做原型，跳過。這套方法論是為「不要出垃圾」優化的，而這跟「搞清楚這點子行不行」是不同目標。

三十萬顆星不是對這套方法論的判決。它是對這個時刻的判決：很多人現在手上的 agent，寫程式比他們監督的速度還快，而他們在找讓監督變便宜的東西。Superpowers 是其中一個答案。它是由 Markdown 組成的，這是最有意思的部分。