Superpowers徹底解説2026｜TDD強制×7段階ワークフローでAIコーディングが激変する

AIコーディングエージェントに「規律」を注入するフレームワーク

AIコーディングエージェントに「このファイルを修正して」と依頼したとき、エージェントはいきなりコードを書き始める。仕様の確認もなく、テストもなく、設計レビューもなく——ただコードを生成する。小さな修正なら問題ない。だが、数時間の自律作業を任せたいとき、この「とりあえず書く」アプローチは崩壊する。

Superpowersは、この問題を根本から解決するスキルフレームワークだ。GitHub Stars 155,000超、Forks 13,500超。開発者Jesse Vincent氏（Prime Radiant）が設計した14個のスキルセットが、AIコーディングエージェントに「仕様確認→設計→計画→TDD→サブエージェント実行→コードレビュー→完了処理」の7段階ワークフローを強制注入する。

対応プラットフォームはClaude Code、Cursor、Codex、OpenCode、GitHub Copilot CLI、Gemini CLI。MIT Licenseで公開されており、誰でも無料で利用できる。

SuperpowersのREADMEには、設計思想を象徴するフレーズがある——「趣味が悪く、判断力がなく、プロジェクト文脈を知らず、テストを嫌がる熱意だけのジュニアエンジニアでも追従できる明確さ」。つまり、プロセスの力で、エージェントの品質を底上げするという発想だ。

Claude Codeのベストプラクティス完全ガイドで紹介したCLAUDE.mdやスキルの基本を理解している読者なら、Superpowersはその「スキル活用の究極形」として位置づけられる。本記事では、14スキルの全貌、7段階ワークフローの詳細、実際のスキル定義ファイル、そして導入手順までを日本語で徹底解説する。

Superpowersの設計思想：4つの核原則

Superpowersを理解するには、まず4つの設計原則を押さえる必要がある。これらはすべてのスキルに通底する思想であり、「なぜこのフレームワークがここまで支持されるのか」の答えでもある。

1. Test-Driven Development——テストが先、常に

最も重要な原則だ。プロダクションコードを書く前に、まずテストを書く。テストが失敗することを確認してから、そのテストを通す最小限のコードを書く。RED-GREEN-REFACTORサイクルの厳守。

Superpowersの test-driven-development スキルには、こう明記されている：

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Write code before the test? Delete it. Start over.

No exceptions:
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete

テストより先にコードを書いた場合、そのコードは削除される。「参考として残す」ことすら許されない。この厳格さがSuperpowersの品質保証の核心だ。

2. Systematic over ad-hoc——プロセスで解決する

推測や直感ではなく、体系的なプロセスで問題を解決する。systematic-debugging スキルでは、バグが見つかったらまずバグを再現するテストを書き、そのテストが通るまで修正する。「なんとなく直った」は許されない。

3. Complexity reduction——シンプルさが最優先

YAGNI（You Aren’t Gonna Need It）原則が自動適用される。「将来必要になるかもしれない」機能は実装しない。テストが要求する最小限のコードだけを書く。

4. Evidence over claims——証拠で判断する

「できた」ではなく「テストが通った」で完了を判断する。verification-before-completion スキルが、全テストの通過を確認してから完了処理に進むことを保証する。

7段階ワークフローの全貌

Superpowersの中核は、7つのステップで構成されるワークフローだ。各ステップは独立したスキルとして定義されており、前のステップが完了しないと次に進めないゲート構造になっている。

Step 1: brainstorming（仕様の抽出と設計承認）

ユーザーが「〜を作って」と依頼した瞬間、Superpowersはいきなりコードを書き始めない。brainstormingスキルが発火し、エージェントは質問を投げ始める。

brainstormingスキルのSKILL.mdには、明確なゲートが定義されている：

Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.

設計が承認されるまで、一切の実装行為が禁止される。「ちょっとした変更だから設計は不要」という例外もない——スキル定義に “No ‘too simple’ exception” と明記されている。

具体的なプロセスは以下の通りだ：

1. 既存のコード・ドキュメント・コミット履歴を調査
2. 1つずつ質問して目的・制約・成功基準を明確化（複数選択式を優先）
3. 2-3個のアプローチを提案し、トレードオフと推奨を提示
4. 設計ドキュメントを docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md に保存
5. セルフレビュー（プレースホルダー・矛盾・曖昧さをチェック）
6. ユーザーの承認を待つ

Step 2: using-git-worktrees（隔離環境の構築）

設計承認後、git worktreeで隔離されたブランチを自動作成する。既存のコードに影響を与えない安全な環境で作業を開始する。

# Superpowersが自動実行するworktree構築の流れ
git worktree add -b feature/my-task ../worktree-my-task
cd ../worktree-my-task

# プロジェクトのセットアップ
npm install   # または pip install, cargo build 等

# テストがクリーンに通ることを確認してから作業開始
npm test
# All tests passed → 作業開始

worktreeを使う理由は明確だ。メインブランチを汚さず、失敗してもworktreeごと破棄できる。複数タスクを並列実行する際にも、worktree単位で隔離できる。

Step 3: writing-plans（実装計画の作成）

設計ドキュメントを元に、具体的な実装計画を作成する。各タスクは2-5分で完了する粒度に分解される。

計画に含まれる情報：

• 対象ファイルの正確なパス
• 書くべきコードの全体像
• 検証ステップ（何をもって完了とするか）

この粒度が重要だ。「ユーザー認証を実装する」のような曖昧なタスクではなく、「src/auth/validator.ts にメールバリデーション関数を追加し、空文字列・不正フォーマット・正常入力の3テストケースを書く」レベルまで分解される。

Step 4: subagent-driven-development（サブエージェント駆動実行）

計画の各タスクに対して、個別のサブエージェントが起動される。これがSuperpowersの「数時間の自律稼働」を可能にする核心技術だ。

プロセスは以下の通り：

1. タスクごとにフレッシュなサブエージェントをディスパッチ
2. サブエージェントが実装 + セルフレビュー + コミット
3. 仕様準拠チェック（Spec Compliance Review）
4. コード品質チェック（Code Quality Review）
5. 両方のレビューを通過したら次のタスクへ

サブエージェントのステータスは4種類で管理される。

モデル選択も最適化される——「各役割を処理できる最も安価なモデルを使う」原則により、単純な実装にはコスト効率の高いモデル、アーキテクチャ判断やレビューには高性能モデルが使い分けられる。

Step 5: test-driven-development（TDD）

各サブエージェントの内部で、RED-GREEN-REFACTORサイクルが強制される。これがSuperpowersの品質保証の最終防衛線だ。

TDDスキルのSKILL.mdから、実際のコード例を引用する：

// RED: まず失敗するテストを書く
test('retries failed operations 3 times', async () => {
  let attempts = 0;
  const operation = () => {
    attempts++;
    if (attempts < 3) throw new Error('fail');
    return 'success';
  };

  const result = await retryOperation(operation);
  expect(result).toBe('success');
  expect(attempts).toBe(3);
});

// テストが失敗することを確認
// FAIL: expected 'success', got undefined

// GREEN: テストを通す最小限のコード
async function retryOperation<T>(
  fn: () => Promise<T>
): Promise<T> {
  for (let i = 0; i < 3; i++) {
    try {
      return await fn();
    } catch (e) {
      if (i === 2) throw e;
    }
  }
  throw new Error('unreachable');
}

// テストが通ることを確認
// PASS

// REFACTOR: 必要に応じてリファクタリング

スキル定義には「よくある言い訳」とその反論も網羅されている：

Step 6: requesting-code-review（コードレビュー）

タスク間でレビューが実行される。問題は重大度別に分類される：

• Critical（重大）：ブロッキング。解決するまで次のタスクに進めない
• Warning（警告）：できれば修正
• Suggestion（提案）：任意

Criticalが検出されると、修正→再レビューのサイクルが回る。レビュー段階をスキップすることは許されない。

Step 7: finishing-a-development-branch（完了処理）

全テストの通過確認後、4つの選択肢が提示される：

1. マージ: メインブランチにマージ
2. PR作成: Pull Requestを作成して人間のレビューを待つ
3. ブランチ維持: 追加作業のためにブランチを保持
4. 破棄: worktreeごとクリーンアップ

worktreeの自動クリーンアップも行われる。

14個のスキルセット完全解説

Superpowersの14スキルは、4つのカテゴリに分類される。各スキルはSKILL.mdファイルとして定義されており、エージェントが状況に応じて自動的に呼び出す。

テスト関連（1スキル）

test-driven-development — RED-GREEN-REFACTORサイクルを強制する。新機能・バグ修正・リファクタリング・動作変更のすべてに適用。例外は「捨てるプロトタイプ」「生成コード」「設定ファイル」の3つだけで、いずれも人間の承認が必要。

デバッグ関連（2スキル）

systematic-debugging — バグを体系的に調査する。推測で修正するのではなく、まず再現テストを書き、原因を特定してから修正する。

verification-before-completion — 完了宣言の前に全テストの通過を確認する。「できたと思う」ではなく「テストが通った」ことを証拠とする。

コラボレーション関連（9スキル）

brainstorming — 仕様の抽出と設計承認。実装の前段階で、ユーザーの要求を掘り下げ、設計ドキュメントを生成する。

writing-plans — 設計を2-5分粒度のタスクに分解する。対象ファイルの正確なパス、書くべきコード、検証ステップを明記。

executing-plans — 計画を実行する。並列セッションが利用できる場合のメインスキル。

dispatching-parallel-agents — 独立したタスクを並列のサブエージェントに分配する。

subagent-driven-development — 単一セッション内でサブエージェントを駆動する。2段階レビュー（仕様準拠→コード品質）を経て進行。

requesting-code-review — 計画に対するレビューを要求する。Critical/Warning/Suggestionの3段階で分類。

receiving-code-review — レビュー結果を受け取り、修正を実行する。

using-git-worktrees — git worktreeで隔離された開発環境を構築する。

finishing-a-development-branch — マージ/PR/維持/破棄の4選択肢を提示し、worktreeをクリーンアップ。

メタ（2スキル）

using-superpowers — 会話開始時に自動発火するメタスキル。全14スキルの呼び出しを制御する司令塔。SKILL.mdの冒頭に「1%でもスキルが適用される可能性があれば、即座にスキルを呼び出す」と定義されている。

writing-skills — 新しいスキルを作成するためのスキル。Claudeが自分自身のスキルを書くための「スキル・クリエーター・スキル」だ。

スキル定義ファイルの構造：SKILL.mdの中身

Superpowersの各スキルは、SKILL.mdファイルとして定義されている。Claude Skillsの仕組みで解説したSKILL.md形式と同じフォーマットだ。

実際のスキル定義を見てみよう。以下は test-driven-development スキルのSKILL.md冒頭部分だ：

---
name: test-driven-development
description: >
  Use when implementing any feature or bugfix,
  before writing implementation code
---

# Test-Driven Development (TDD)

## Overview

Write the test first. Watch it fail. Write minimal code to pass.

Core principle: If you didn't watch the test fail,
you don't know if it tests the right thing.

Violating the letter of the rules is violating
the spirit of the rules.

using-superpowers スキルの定義も見てみよう：

---
name: using-superpowers
description: >
  Use when starting any conversation - establishes how
  to find and use skills, requiring Skill tool invocation
  before ANY response including clarifying questions
---

このスキルは「会話のあらゆる応答の前にスキルツールを呼び出すことを要求する」と定義されている。つまり、Superpowersをインストールすると、エージェントの全応答がスキルフレームワークの管理下に入る。

brainstorming スキルの定義も興味深い：

---
name: brainstorming
description: >
  Use when the user requests any new feature,
  change, or project initialization
---

# Hard gate:
# Do NOT invoke any implementation skill, write any code,
# scaffold any project, or take any implementation action
# until you have presented a design and the user has
# approved it.

スキル間の連携も定義されている。brainstormingの終端状態は「writing-plansスキルの呼び出し」であり、他の実装スキルは許可されない。このスキル間のゲート構造が、Superpowersのワークフローを強固にしている。

スキルのディレクトリ構造

リポジトリの skills/ ディレクトリは以下の構成だ：

skills/
├── brainstorming/
│   └── SKILL.md
├── dispatching-parallel-agents/
│   └── SKILL.md
├── executing-plans/
│   └── SKILL.md
├── finishing-a-development-branch/
│   └── SKILL.md
├── receiving-code-review/
│   └── SKILL.md
├── requesting-code-review/
│   └── SKILL.md
├── subagent-driven-development/
│   └── SKILL.md
├── systematic-debugging/
│   └── SKILL.md
├── test-driven-development/
│   ├── SKILL.md
│   └── testing-anti-patterns.md    ← 参考ファイル同梱
├── using-git-worktrees/
│   └── SKILL.md
├── using-superpowers/
│   └── SKILL.md
├── verification-before-completion/
│   └── SKILL.md
├── writing-plans/
│   └── SKILL.md
└── writing-skills/
    └── SKILL.md

注目すべきは test-driven-development スキルに testing-anti-patterns.md という参考ファイルが同梱されている点だ。スキルはフォルダ単位の「知識パッケージ」であり、SKILL.md以外のファイルも同梱できる。この設計はClaude Skillsの解説記事で詳しく紹介した仕組みそのものだ。

Superpowers vs 通常のClaude Code：何が変わるか

Superpowersを導入する前後で、AIコーディングの体験がどう変わるのかを具体的に比較する。

Superpowers vs 他のスキルフレームワーク

Superpowersは唯一のスキルフレームワークではない。他のアプローチとの比較も整理しておこう。

Superpowersの最大の差別化ポイントは「ゲート構造」だ。CLAUDE.mdに「TDDをやれ」と書いても、エージェントはそれを「推奨事項」として扱う可能性がある。Superpowersのスキルは「次のステップに進む条件」としてTDDを定義しているため、スキップが構造的に不可能になる。

Vibe Codingガイド2026年版で紹介した「AIに任せきりのコーディング」の課題——品質の不安定さ、テスト不足、設計の欠如——に対して、Superpowersは最も体系的な解を提供している。

インストールと導入手順

各プラットフォームでのインストール方法を整理する。いずれも1-2コマンドで完了する。

Claude Code（公式マーケットプレイス）

最も簡単な方法だ：

# 公式マーケットプレイスから直接インストール
/plugin install superpowers@claude-plugins-official

カスタムマーケットプレイス経由の場合：

# マーケットプレイスを追加してからインストール
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Cursor

# Cursorのプラグイン機能でインストール
/add-plugin superpowers

またはCursorのマーケットプレイスUIで「superpowers」を検索してインストールする方法もある。

GitHub Copilot CLI

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

Gemini CLI

gemini extensions install https://github.com/obra/superpowers
gemini extensions update superpowers

Codex / OpenCode

それぞれのリポジトリに専用のインストール手順が用意されている：

# Codexの場合
# .codex/INSTALL.md の手順に従う

# OpenCodeの場合
# .opencode/INSTALL.md の手順に従う

インストール後の確認

インストール後、特別な設定は不要だ。using-superpowers スキルが会話開始時に自動発火し、以降のすべての応答がSuperpowersのワークフロー管理下に入る。

動作確認は簡単だ——何かタスクを依頼してみればよい。Superpowersが正しくインストールされていれば、エージェントはいきなりコードを書き始めるのではなく、brainstormingスキルを起動して質問を投げ始める。

TDDスキルの実践：RED-GREEN-REFACTORの自動化

Superpowersの test-driven-development スキルは、14スキルの中で最も詳細に定義されている。バグ修正の実践例でフローを見てみよう。

実践例：空メール受け入れバグの修正

Superpowersの公式スキル定義に含まれているバグ修正例だ：

// ===== RED: 失敗するテストを書く =====
test('rejects empty email', async () => {
  const result = await submitForm({ email: '' });
  expect(result.error).toBe('Email required');
});

テストを実行して、失敗を確認する：

$ npm test
FAIL: expected 'Email required', got undefined

テストが「正しい理由で」失敗していることを確認する。タイポやインポートエラーではなく、「機能が未実装だから」失敗している——これが重要だ。

// ===== GREEN: テストを通す最小限のコード =====
function submitForm(data: FormData) {
  if (!data.email?.trim()) {
    return { error: 'Email required' };
  }
  // ...existing code
}

$ npm test
PASS

テストが通った。ここで止まる。「ついでにパスワードのバリデーションも追加しよう」はYAGNI違反だ。次のテストを書くまで、次の機能は実装しない。

TDDスキルの検証チェックリスト

スキル定義には、完了前に確認すべきチェックリストも含まれている：

• すべての新関数・メソッドにテストがある
• 各テストが失敗するのを確認してから実装した
• 各テストが「正しい理由で」（機能未実装で）失敗した
• テストを通す最小限のコードだけを書いた
• すべてのテストが通過している
• 出力がクリーン（エラー・警告なし）
• テストは実コードを使っている（モックは必要最小限）
• エッジケースとエラーケースをカバー

全項目にチェックが入らない場合、「TDDをスキップした」と判定され、最初からやり直しになる。

サブエージェント駆動開発の詳細

subagent-driven-development スキルは、Superpowersが「数時間の自律稼働」を実現する核心技術だ。

なぜサブエージェントなのか

通常のAIエージェントは、長い会話の中でコンテキストが汚れていく。10タスク目のコードを書くとき、1-9タスク目の文脈がノイズになる。サブエージェントは各タスクを「フレッシュなコンテキスト」で実行することで、この問題を解決する。

2段階レビューの仕組み

各サブエージェントの実装が完了すると、2段階のレビューが走る：

1. Spec Compliance Review（仕様準拠チェック）：実装が設計ドキュメントの仕様に準拠しているか確認。仕様から逸脱していたら差し戻し
2. Code Quality Review（コード品質チェック）：実装がコーディング規約・ベストプラクティスに準拠しているか確認

Spec Compliance Reviewが通らないと、Code Quality Reviewには進まない。この順序も構造的に強制されている。

モデル選択の最適化

スキル定義には「各役割を処理できる最も安価なモデルを使う」という原則が明記されている：

これにより、大規模な実装でもコストを抑えつつ、品質が必要な場面では高性能モデルを投入できる。

using-superpowers：全スキルを統括するメタスキル

14スキルの中で特異な存在が using-superpowers だ。このスキルは「スキルを使うためのスキル」であり、Superpowersフレームワーク全体の司令塔として機能する。

自動発火の仕組み

using-superpowers のdescriptionは「会話開始時に使う」と定義されている。つまり、Superpowersをインストールした瞬間から、すべての会話がこのスキルの管理下に入る。

スキル定義の核心部分を見てみよう：

Invoke relevant or requested skills BEFORE any response
or action.

Even a 1% chance a skill applies requires immediate
invocation — this is not negotiable, not optional.

1%でもスキルが適用される可能性があれば、即座にスキルを呼び出す——これは「交渉不可、任意ではない」と明記されている。

指示の優先順位

using-superpowersスキルは、指示の優先順位も定義している：

1. ユーザーの明示的な指示（最高優先）
2. Superpowersスキルの指示
3. デフォルトのシステムプロンプト

つまり、ユーザーが「TDDはスキップして」と明示的に指示した場合、その指示が優先される。Superpowersは絶対的なルールではなく、ユーザーの意思が最上位にある設計だ。

よくある回避の試みへの対策

スキル定義には「エージェントがスキルを呼び出さない理由を合理化する」パターンとその対策も含まれている：

カスタマイズと拡張：自分のスキルを追加する

Superpowersは「入れたらそのまま使う」だけでなく、自分のスキルを追加して拡張できる。

writing-skillsスキルで自作する

writing-skills メタスキルを使えば、Claudeに「新しいスキルを作って」と依頼するだけで、SKILL.mdが自動生成される。

# Claude Codeでの操作例
> 「このプロジェクトのデプロイ手順をスキル化して」

# writing-skillsスキルが発火し、以下を自動生成：
# .claude/skills/deploy/SKILL.md

既存スキルの上書き

Superpowersのスキルをプロジェクト固有にカスタマイズしたい場合、同名のスキルをプロジェクトの .claude/skills/ に配置すれば上書きできる。

# Superpowersのtest-driven-developmentスキルを
# プロジェクト固有にカスタマイズする場合：
mkdir -p .claude/skills/test-driven-development/
cat > .claude/skills/test-driven-development/SKILL.md << 'EOF'
---
name: test-driven-development
description: Use when implementing any feature or bugfix
---

# プロジェクト固有のTDDルール

Superpowersの標準TDDに加えて、以下を追加：

## 追加ルール
- E2Eテストは Playwright を使用
- テストファイルは `__tests__/` に配置
- カバレッジ80%以上を必須とする
EOF

継続学習：Claudeが自分でスキルを進化させる

Superpowersの設計には「継続学習」のビジョンが組み込まれている。Claudeを1日目から使い続けると、30日目のClaudeは1日目より格段に優秀になる——スキルが学習内容の蓄積装置として機能するからだ。

writing-skills スキルにより、Claudeが作業中に発見したパターンやベストプラクティスを新しいスキルとして自動保存できる。これが繰り返されることで、プロジェクト固有の知識がスキルライブラリとして蓄積されていく。

リポジトリの技術構成

Superpowersリポジトリの技術的な構成も押さえておこう。

Shell比率が最も高いのは、スキル定義の多くがShellスクリプトベースのワークフローを記述しているためだ。JavaScript/TypeScriptはテスト関連、PythonとHTMLはドキュメント・サンプルに使われている。

よくある疑問と回答

Q: Superpowersを入れたら開発速度は落ちないか？

brainstormingやTDDの工程が追加される分、最初の1ファイル修正までの時間は確かに伸びる。しかし、Superpowersが解決するのは「長時間の自律稼働」の品質だ。30分の作業を5分に短縮するツールではなく、3時間の自律作業を「手戻りなしで」完遂するためのフレームワークだと理解すべきだ。

Q: 小さな修正にもbrainstormingは必要か？

Superpowersの設計上は「No ‘too simple’ exception」だ。ただし、using-superpowersの指示優先順位ではユーザー指示が最上位にある。「brainstormingはスキップして直接修正して」と明示的に伝えれば、それが優先される。

Q: 既存のCLAUDE.mdと競合しないか？

しない。Superpowersのスキルは .claude/skills/ に配置されるPlugin/Projectスコープであり、CLAUDE.mdの常時ロードとは別の仕組みだ。CLAUDE.mdの指示とSuperpowersスキルの指示が矛盾する場合は、ユーザーが優先順位を明示すればよい。

Q: チーム全員にSuperpowersを強制できるか？

Enterprise管理のスキル配布機能を使えば可能だ。managed-settings.json経由でSuperpowersのスキルを全メンバーに強制配布できる。個別のプロジェクトでは .claude/skills/ にスキルを配置し、リポジトリにコミットすればチーム全員に適用される。

まとめ：AIコーディングに「構造」を持たせる

Superpowersが提供するのは、AIコーディングエージェントへの「規律の注入」だ。

14個のスキルが、仕様確認→設計→計画→テスト→実装→レビュー→完了の7段階を強制する。テストより先にコードを書いたら削除される。設計が承認されるまで一行も実装できない。レビューでCriticalが出たら先に進めない。

この「構造」があるからこそ、数時間の自律稼働でも品質が保たれる。「とりあえずコードを書く」から「計画に基づいて検証しながら進む」への転換だ。

4つの設計原則を最後に再掲する：

1. Test-Driven Development — テストが先、常に
2. Systematic over ad-hoc — プロセスで解決する
3. Complexity reduction — シンプルさが最優先
4. Evidence over claims — 証拠で判断する

SuperpowersのREADMEは「趣味が悪く、判断力がないジュニアエンジニアでも追従できる明確さ」を設計基準に掲げている。AIエージェントに「プロセスの力」で品質を保証させる——その発想が15万スターの支持を集めた理由だ。

参照ソース

• obra/superpowers — GitHubリポジトリ
• Superpowers skills/ ディレクトリ — 14スキル定義ファイル一覧
• test-driven-development/SKILL.md — TDDスキル定義
• Claude Skills公式ドキュメント — Extend Claude with skills