Superpowersをはじめる
インストールは一度だけ。AIの動き方が永遠に変わります。
Superpowersとは何か？（技術的な説明）
Superpowersはアジェンティックスキルフレームワークです。AIコーディングエージェントに読み込む、構造化された行動プロトコルのセットです。Request Tracker（歴史上最も広く普及したissueトラッキングシステムの一つ）の作者として知られるJesse Vincentが作成しました。
このフレームワークは、ソフトウェア開発においてAIエージェントがどのように考え、どのように振る舞うべきかを定義します。単に「どんなコードを書くか」だけでなく、「いつ立ち止まって確認するか」「どのように計画するか」「どのように検証するか」「何かが本当に完成したとはどういうことか」まで定めています。
技術的には、Superpowersはスキル（プラットフォームによってプラグインやルールとも呼ばれる）の集合です。各スキルは特定の条件下で起動する、集中した命令セットです。SuperpowersをあなたのAIツールにインストールすると、機械が読み取れるプロトコルとして構築されたプロフェッショナルなソフトウェアエンジニアリングの規律が与えられます。
コア哲学
Superpowersはすべてのスキルに貫かれる3つの原則の上に成り立っています。
1. TDD ファースト（Test-Driven Development）
失敗するテストなしには本番コードを書かない。 これはガイドラインではなく、強制されるルールです。AIはいかなる実装も書く前に、失敗するテストを書かなければなりません。このステップをスキップしたくなった場合、Superpowersはテストなしに書かれたコードをすべて削除してやり直すことを明示的に要求します。
なぜ重要か：コードの後に書かれたテストは、コードが「すべきこと」ではなく、コードが「していること」をテストする傾向があります。先に書かれたテストは意図を捉え、早い段階で前提を検証します。
2. YAGNI（You Aren't Gonna Need It）
明示的に要求されているものだけを作る。 投機的な抽象化も、「将来のための」準備も、「念のための」追加設定オプションも不要です。コードベースへのあらゆる追加にはメンテナンスコストがかかります。Superpowersはそのタスクに集中させます。
3. 証拠 > 主張
テストが通ったのを見ることが証拠です。動くはずだと言うことは主張です。 Superpowersは、何かが完成したと主張する前に、AIが実際の出力（本物のテスト結果、本物のコマンド出力、本物のファイルdiff）を提示することを要求します。「動くはず」は完了を示す言葉として許容されません。
インストール
Superpowersは複数のプラットフォームで動作します。お使いのツールを選んでください。
Claude Code
/plugin install superpowers@claude-plugins-official
これでフルのSuperpowersスキルスイートがClaude Codeセッションにインストールされます。スキルはコンテキストに基づいて自動的に起動します。
Cursor
/add-plugin superpowers
プラグインを追加すると、Cursorがスキル定義を読み込みます。Cursorセッションの再起動が必要な場合があります。
Gemini CLI
gemini extensions install superpowers
プロンプトに従って拡張機能を承認してください。次のGemini CLIセッションからすべてのスキルが利用可能になります。
Codex
Codex設定ファイルを通じてカスタム命令セットとしてSuperpowersを追加します。プラグインのインストールパスについては公式Codexドキュメントを参照してください。
OpenCode
opencode plugin add superpowers
スキルはセッション開始時に自動的に読み込まれます。
インストールの確認
インストール後、AIエージェントに次のように聞いてください。
"What Superpowers skills are available?"
正しくインストールされたSuperpowersスイートはアクティブなスキルの一覧を表示します。brainstorming、writing-plans、executing-plans、test-driven-developmentなどのスキルが表示されるはずです。
エージェントがスキルを認識しない場合は、インストールコマンドを再実行してセッションを再起動してください。
7ステップのコアワークフロー
インストール後、Superpowersは構造化された7ステップのプロセスで開発をガイドします。以下は概要です。各ステップには専用の章があります。
| ステップ | Skill | 説明 |
|---|---|---|
| 1 | BRAINSTORM | 問題空間の探索 |
| 2 | ISOLATE | 安全な作業環境の作成 |
| 3 | PLAN | 詳細なタスクリストの作成 |
| 4 | EXECUTE | サブエージェントで実装 |
| 5 | TEST | TDD サイクル: Red → Green → Done |
| 6 | REVIEW | 2段階の品質ゲート |
| 7 | COMPLETE | 検証済みの納品 |
ステップ1：ブレインストーミング
AIはコードに触れる前にあなたと一緒に問題を探求します。一度に一つの明確化の質問をし、トレードオフを含む2〜3つのアプローチを提示し、承認を待ちます。設計が承認されるまでコードが書かれないよう、ハードゲートが設けられています。
→ 詳細はブレインストーミングとデザインで説明します
ステップ2：分離
作業はgit worktree（リポジトリの分離されたコピー）で行われます。変更は意図的にマージされるまで格納されます。あなたのmain branchは常に安全です。
→ 実行ワークフローの一部として説明します
ステップ3：計画の作成
実行開始前に、詳細な実装計画が作成されます。計画内の各タスクは自己完結しており、完全なコードスニペット、正確なファイルパス、正確なコマンドが含まれています。計画はレビューされ承認されます。
→ 詳細は計画の作成で説明します
ステップ4：実行とSubagent
計画のタスクは新鮮なsubagentプロセス（以前のタスクの記憶を持たない、分離されたAIインスタンス）に配信されます。これにより一つのタスクのエラーが次のタスクに影響することを防ぎます。各完了タスクは2段階のレビューを受けます。
→ 詳細は実行とSubagentで説明します
ステップ5：Test-Driven Development
すべての機能は失敗するテストから始まります。RED-GREEN-REFACTORサイクルが厳格に守られます。テストスイートを実行して実際の合格出力を確認するまで、機能は完成とマークされません。
→ 詳細はTest-Driven Developmentで説明します
ステップ6：レビュー
2段階のレビュープロセスで、仕様への準拠（要求されたものを作ったか？）とコード品質（コードはメンテナブルで正確か？）の両方を確認します。これらの2つの観点は別々に評価されます。
→ 実行とSubagentの章の一部です
ステップ7：完了
すべての検証ゲートが通過した後、エージェントはクリーンな完了レポートを提示し、pull requestの作成を支援し、作業が適切に統合されることを確認します。証明できるまで「完了」ではありません。
→ finishing-a-development-branchスキルのドキュメントで説明します
クイックリファレンス：主要コマンド
| アクション | AIに言うこと |
|---|---|
| 新機能を開始する | "I want to add [機能]. Use the brainstorming skill." |
| 計画を作成する | "We've agreed on the design. Write an implementation plan." |
| 計画を実行する | "Execute this plan using subagents." |
| TDDを実行する | "Implement [機能] using test-driven development." |
| 作業をレビューする | "Review this implementation before we complete." |
次に読む場所
このガイドはワークフローの各ステップを詳しく説明します。各章は最初の通読では順番に読み、その後は参考資料として使ってください。
- ブレインストーミングとデザイン — 早まったコードからあなたを守るハードゲート
- 計画の作成 — 設計を実行可能なタスクに変える方法
- 実行とSubagent — コンテキスト分離で計画を安全に実行する
- Test-Driven Development — 証拠に基づいた納品の鉄則
覚えておいてください： Superpowersはスピードを落とすためのものではありません。「書く → 壊れる → 修正する → また壊れる」という高コストなサイクルを止めるためのものです。最初の規律が後のコストを何倍にも節約します。