Superpowers、31万スターの「コードを書く前に立ち止まる」手順

今週のGitHubトレンドで最もスターを集めたリポジトリは、モデルでもフレームワークでも、スタートアップのOSS損失先行商品でもない。コーディングエージェントの振る舞いを定めるMarkdownファイルのフォルダだ。

Jesse VincentによるSuperpowersは約311,000スター、直近1週間で約5,900を追加した。説明はこうだ。コーディングエージェントのための完全なソフトウェア開発方法論で、組み合わせ可能なスキル群と、エージェントがそれを実際に使うようにする初期指示から成る。

方法論に31万スターというのは妙な光景だ。この10年で最大の開発者集団が一斉にプロセスを求めたのか、スターのボタンが「あとで考えよう」のブックマークになったのか。おそらく両方だ。だが中身は真剣に取る価値がある。エージェントがコードを書く前に何をすべきかという問いに、これまでに出た中で最も主張の強い答えだからだ。

最初の一手は「始めないこと」

READMEに描かれているワークフローはこうだ。エージェントはあなたが何かを作っていると見るや、コードを書き始めない。一歩下がって、本当は何をしようとしているのかを尋ねる。

会話からスペックを引き出したら、読める長さの塊に分けて見せる。要件の壁を1枚どんと出すのではない。塊で出す。承認したら、READMEの言葉でいえば「熱意はあるが趣味が悪く、判断力もプロジェクト文脈もなく、テストを嫌うジュニアエンジニア」が従えるほど詳細な実装計画を作る。

この一文がリポジトリで最良の部分だ。そして、LLMの悪い日の姿を正確に描写してもいる。その読み手のために計画を書くのは、多くのエンジニアが飛ばす規律だ。読み手は自分の文脈を共有していると仮定してしまうからだ。

そして「進め」と言えば、サブエージェント駆動開発が始まる。エージェントが各タスクを進め、自分の仕事を検査しレビューし、動き続ける。READMEは、エージェントがプランから逸れずに2時間ほど自律で働くのは珍しくないと主張している。

中身は何か

15ほどのスキルが機能ごとにまとまっている。

テストは1項目だけで、しかもそれが重要だ。test-driven-development、赤緑リファクタのサイクルで、テストのアンチパターンに関する参照文書が付く。デバッグにはsystematic-debugging、4フェーズの根本原因追跡プロセスで、トレース、多層防御、条件ベースの待機の技法を含む。加えてverification-before-completion、その仕事は「直っていないものに勝利宣言するエージェントを止める」ことだけだ。

本当に重いのはコラボレーションの部分だ。意図を引き出すbrainstorming、writing-plans、executing-plans、dispatching-parallel-agents、コードレビューの依頼と受領、using-git-worktrees、finishing-a-development-branch、そして2段階レビュー付きのsubagent-driven-development。まずスペック準拠、次にコード品質。

2つのメタスキルが輪を閉じる。新しいスキルを作るためのwriting-skillsと、会話の冒頭でモデルにシステムを読み込ませる導入のusing-superpowers。スキルは自動で発火するので、理論上は何も覚えておく必要がない。エージェントが持っている。

インストール、ハーネスごとに16回

ここを見るとエージェントツール市場がどれだけ分断されているか分かる。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はエージェントチャットで /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はどちらも公式プラグインマーケットプレイス経由だ。

複数のハーネスを使うなら、それぞれに別々に入れる。つまり同じ12個のスキルが12個のコピーとして存在し、共通の更新経路がない。READMEの更新についての助言は「コーディングエージェント次第だが、多くの場合自動」だ。これはこのプロジェクトへの批判ではない。エコシステムの現状であり、方法論のリポジトリがそれに対処する様子はなかなか勉強になる。

コントリビューション方針が本音

コントリビューションの節に埋もれている。新しいスキルの貢献は原則受け付けない、スキルの更新はサポートする全エージェントで動かなければならない、そして他人が起票したissueを直すエージェント作成のPRは、メンテナが依頼した場合を除いて受け付けない。あなたが同じ問題にぶつかっていても、だ。

最後のルールが何のためか考えてみてほしい。こういうリポジトリの明白な失敗の形は、スキルが統制しようとしている当のエージェントが生成した、もっともらしいスキルで埋め尽くされることだ。Vincentはそれを見越して先回りした。不親切に見えることを代償に。

もっと微妙な含意もある。エージェントが何でもスキルを生成できるなら、希少な資源はスキルではなく「どのスキルを持つ価値があるか」という判断になる。その判断こそがこのリポジトリの実際の商品であり、プルリクエストは受け付けない。

方法論が破れるところ

4つ、実際に噛まれた回数の順に。

プロセスはセンスを直せない。ひどい発想の機能に対する完璧に実行された計画は、よくテストされた間違ったものを生む。brainstormingは本当に欲しいものを問うことで助けになるが、そのアイデアがつまらないとは教えてくれない。

トークン経済。スペック、塊ごとのレビュー、計画、サブエージェントの配車、タスクごとの2段階レビュー、完了前の検証。小さなタスクでは途方もないオーバーヘッドだ。この方法論は日単位の仕事のために設計されていて、1行の修正には馬鹿げて感じる。

計画は漂流する。0分目に書いた計画に対して2時間の自律作業がうまくいくのは、計画が正しかったときだけだ。3番目のタスクで2番目が誤った前提に立っていたと分かると、あなたは間違った方向への2時間の自信ある仕事を得る。レビューだけが、あなたと巨大な差分の間に立っている。

そして正直なところ、スキルはプロンプトであり、プロンプトは提案にすぎない。ここにあるすべては、モデルが他に知っている5つのことではなくスキルに従うことを選ぶかにかかっている。using-superpowersがブートストラップとして存在するのはそのためだ。他のプロンプトを読み込ませるためのプロンプトである。

誰向けか

他人が依存するコードを出していて、直っていないものにエージェントが自信満々に完了マークを付けるのを見たことがあるなら、これは妥当なガードレールで、試すのにコマンド1つしかかからない。まずtest-driven-developmentとverification-before-completionから始め、1週間は残りを無視する。この2つが最も行動を変える。

プロトタイピング中なら入れなくていい。この方法論はゴミを出さないために最適化されていて、アイデアが成立するかを見つけるのとは目的が違う。

31万スターは方法論への判定ではない。時代への判定だ。多くの人が、自分が監督できるより速くコードを書くエージェントを持ち、監督を安くする何かを探している。Superpowersはその1つの答えだ。それがMarkdownでできているという事実が、最も面白い部分である。