Superpowersはコーディングエージェントの作業順序をどう変えるか
Superpowers は、設計、計画、テスト、デバッグ、レビュー、ブランチの完了をカバーする反復可能なエンジニアリング プラクティスをエージェント スキルとしてパッケージ化しています。
ひと目でわかる
- これは何？
- obra/superpowersは、仕様整理から設計、テスト、レビュー、ブランチ完了までをスキルとして組み合わせる開発方法論です。
- 誰に向いている？
- Superpowersは、コード生成の速さだけでなく、仕様を確定し、計画を読み、テストとレビューを通して変更を閉じる運用をエージェントに求めたいチームに向きます。READMEには多くのハーネス向け手順がありますが、各環境での互換性や自律実行の安定性を保証する資料ではないため、導入前に小さなリポジトリでスキルの発火、権限、停止条件を確認してください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Shell です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
コードを書く前に会話を仕様へ変える
Superpowersの出発点は、エージェントにいきなり編集を始めさせないことです。READMEでは、何を作ろうとしているのかを尋ね、会話から仕様を取り出し、読める大きさのまとまりに分けて提示する流れが説明されています。利用者が設計を確認してから、実装計画へ進みます。
この順番は、プロンプトに一度で要求を詰め込む方式とは違います。仕様の抜けや前提のずれを、ファイルを変更する前に見つけるための段階です。スキルは構成可能な部品として用意され、起動条件に合うと自動で呼び出される設計です。ただし、自動発火が各ハーネスで同じように動くことや、利用者の意図を正しく理解することまで、READMEが数値で示しているわけではありません。
計画、TDD、レビューを一続きにする
設計の承認後、エージェントは実装計画を作ります。READMEは、プロジェクトの背景を知らず、テストを嫌う新人でも手順を追えるほど具体的な計画を目指すと説明しています。ここで重視されるのがred-green-refactorのTDD、YAGNI、DRYです。短いタスクに分け、先に失敗するテストを書き、実装してから整理する順番を保ちます。
作業開始後はsubagent-driven-developmentの流れで、個々のエンジニアリングタスクを処理し、成果を検査してレビューします。仕様に合っているかと、コードの質が保たれているかを分けて見る考え方です。READMEには、計画から外れずにエージェントが数時間ほど自律して作業することがあると記されています。これはプロジェクトの宣伝上の説明であり、利用環境で同じ時間と品質を再現する証拠ではありません。
七つのスキルが担当する工程
基本ワークフローは七つの番号付き工程で組まれています。brainstormingは設計文書を作る前段、using-git-worktreesは作業を分離したワークスペースとテストの基準を用意する段階です。writing-plansは各タスクにファイルパス、実装内容、確認方法を与えます。
その後はexecuting-plansまたはsubagent-driven-developmentで実装を進め、requesting-code-reviewで区切りごとにレビューを求めます。test-driven-developmentはテストの赤、緑、整理の循環を扱い、systematic-debuggingは失敗を根本原因から追います。最後のfinishing-a-development-branchは、検証後にマージ、プルリクエスト、保持、破棄の選択肢を整理します。using-superpowersは関連スキルを作業前に確認させるメタ層です。ここまで工程を固定すると、便利なコマンド集ではなく、判断の順番を共有する仕組みとして見えてきます。
ハーネスごとに導入方法が分かれる
READMEにはClaude Code、Antigravity、Codex App、Codex CLI、Cursor、Devin CLI、Factory Droid、Gemini CLI、GitHub Copilot CLI、Grok Build CLI、Kimi Code、OpenCode、Pi、Hermes Agent向けの入口が並びます。複数のハーネスを使う場合、環境ごとにSuperpowersを導入する必要があります。Claude Codeでは公式マーケットプレイスとSuperpowers側のマーケットプレイスが案内され、Gemini CLIやPiではリポジトリからの導入例が示されています。
OpenCode向けには、リポジトリ内のINSTALL指示をURLから取得する手順があります。Codex Appではプラグイン画面から追加する流れです。手順が多いことは選択肢の広さを示しますが、共通のインストーラーが全環境を抽象化しているわけではありません。導入時は対象ハーネスのバージョン、スキルが置かれる場所、セッション開始時に指示が読み込まれるかを個別に記録するのが安全です。
評価、貢献、テレメトリの境界
貢献者向けの説明では、リポジトリをフォークし、devブランチで作業する流れが示されています。新しいスキルは一般的な追加提案としては受け付けず、既存スキルの更新も対応するすべてのコーディングエージェントで動く必要があるとREADMEは述べています。スキルの挙動はsuperpowers-evalsのdrill評価ハーネス、プラグイン基盤はtests/で検査します。
brainstormingには任意のビジュアルコンパニオンがあります。READMEの説明では、Prime RadiantのロゴとSuperpowersのバージョンを送ることがありますが、プロジェクト詳細、プロンプト、エージェント情報は含めないとされています。SUPERPOWERS_DISABLE_TELEMETRYで無効化でき、Claude Codeのオプトアウトも尊重します。実際のネットワーク経路や組織の情報管理規則との適合は、環境側で確認する項目です。
導入判断はライセンスと運用条件を分けて行う
リポジトリのメタデータでは、主な言語はShell、ライセンスはMIT、既定ブランチはmainです。2026年8月29日取得の情報として、starは278,963、forkは24,980、open issueは330件、直近のリリースはv6.3.0です。これらは活動量を読む手掛かりであって、各スキルの成功率やサポート契約を示す数値ではありません。
MITライセンスは著作権表示などの条件を保った利用、改変、再配布を認めますが、ソフトウェアは無保証です。エンタープライズ向けの商用サポートや追加ツールの案内はREADMEにあります。Superpowersを選ぶなら、開発手順をチームで揃えたいか、エージェントに計画と検証の停止点を持たせたいかを先に決めるべきです。そのうえで隔離した小規模案件を使い、権限、テレメトリ、レビューの責任者、失敗時の戻し方を確認してください。
編集部の結論
Superpowersは、コード生成の速さだけでなく、仕様を確定し、計画を読み、テストとレビューを通して変更を閉じる運用をエージェントに求めたいチームに向きます。READMEには多くのハーネス向け手順がありますが、各環境での互換性や自律実行の安定性を保証する資料ではないため、導入前に小さなリポジトリでスキルの発火、権限、停止条件を確認してください。
コミュニティノート