目次
- はじめに — なぜ Superpowers なのか
- Superpowers とは何か
- アーキテクチャ: スキル / フック / ブートストラップ
- インストールと動作確認
- スキル一覧リファレンス
- 実践: 機能開発を最初から最後まで通してみる
- 実践: バグ修正を systematic-debugging で回す
- 実践: 自作スキルを writing-skills で書く
- 設計思想の肝: Iron Law と合理化テーブル
- v6 系の重要アップデート
- 運用のコツ・アンチパターン・トラブルシュート
- 他のアプローチとの比較
- 導入前に押さえるべき注意点
- まとめ
1. はじめに — なぜ Superpowers なのか
Claude Code を使っていて、こんな経験はないでしょうか。
- 「ログイン機能作って」と言ったら、要件を一切確認せずにいきなり
LoginController.tsを書き始めた - 「テスト書いて」と言わないとテストが存在しない。言ってもテストは実装の後に書かれる
- 「完了しました！」と宣言されたので確認したら、そもそもビルドが通らない
- バグ修正を頼んだら、根本原因を調べずに「たぶんここだろう」という修正を3回連続で外した
これらはモデルの賢さの問題ではありません。開発プロセスの規律を強制する仕組みが無いことが原因です。人間の新人エンジニアだって、レビューもテスト文化もない現場に放り込めば同じことをします。
Superpowers は、この「プロセスの不在」を埋めるためのプラグインです。作者は Jesse Vincent 氏（GitHub: obra）、Prime Radiant チームによって開発されており、MIT ライセンスのオープンソースです。GitHub リポジトリは 26万 Star 超、Anthropic 公式プラグインマーケットプレイスからのインストール数は 100万を超えています。
2. Superpowers とは何か
公式リポジトリの説明はこうです。
Superpowers is a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.
（コーディングエージェント向けの、完全なソフトウェア開発方法論。合成可能なスキル群と、エージェントに確実にそれを使わせる初期命令の上に構築されている）
ポイントは3つです。
2.1 「スキル」というMarkdownの塊である
Superpowers の実体は、skills/ 配下に置かれた Markdown ファイル群です。バイナリでもMCPサーバーでもありません。「こういう状況では、こう振る舞え」という指示書の集合体です。
各スキルは最低限これを定義しています。
| 定義項目 | 内容 |
|---|---|
| いつ使うか | トリガー条件（例: 「創作作業を始める前に必ず」） |
| 何をするか | 具体的な手順（順序・成果物・保存先まで） |
| やってはいけないこと | 禁止事項と、その言い訳への反論 |
| どう検証するか | 完了判定の基準 |
2.2 スキルが「自動的に」発火する
ここが CLAUDE.md との決定的な違いです。Superpowers はセッション開始時に using-superpowers というメタスキルをコンテキストに注入します。このブートストラップが「1%でも該当しそうならスキルを起動せよ」というルールを敷き、以降エージェントはタスク着手前に必ずスキルの棚卸しを行うようになります。
このブートストラップが無いと、スキルはディスク上に存在するだけで一度も呼ばれません。これは公式ドキュメントでも明記されている重要な点です。
2.3 上流から下流への一方向フロー
Spec（仕様合意） → Plan（計画） → Execute（実装） → Verify（検証） → Finish（統合）
各ゲートには通過条件があり、「今回は急ぎだから設計飛ばして」が原則できません。ここが好きな人と嫌いな人を分けるポイントでもあります（後述）。
3. アーキテクチャ: スキル / フック / ブートストラップ
3.1 コンポーネント構成
| コンポーネント | 役割 | 場所 |
|---|---|---|
marketplace.json |
プラグインのメタデータとソース定義 | .claude-plugin/ |
using-superpowers |
セッション起動時のブートストラップ（1%ルールの根拠） | skills/ |
| SessionStart フック | ブートストラップを毎セッション注入 | hooks/ |
各スキル SKILL.md
|
個別ワークフローの定義本体 | skills/<name>/ |
| SDD ワークスペース | サブエージェント実行時の進捗台帳・タスクブリーフ |
.superpowers/sdd/<plan名>/（git-ignore） |
3.2 スラッシュコマンドは「もう主役ではない」
初期の Superpowers は /brainstorm /write-plan /execute-plan というスラッシュコマンドを提供していましたが、v5.1.0 でこれらのスタブは削除されました。現在は「スキルの直接起動」が正式なやり方です。
| 旧コマンド | 状態 | 置き換え先スキル |
|---|---|---|
/brainstorm |
削除済 | superpowers:brainstorming |
/write-plan |
削除済 | superpowers:writing-plans |
/execute-plan |
削除済 | superpowers:executing-plans |
⚠️ ネット上の記事（本記事執筆時点で日本語記事の多くを含む）は今も
/brainstormを紹介していますが、新規インストールでは表示されないか、Deprecated 表記で出ます。混乱しやすい最大のポイントなので注意してください。実運用では「自然言語で頼めば自動発火する」が正解です。
つまり、正しい使い方はこうです。
❌ /brainstorm "ユーザープロフィール編集機能を追加"
✅ ユーザープロフィール編集機能を追加したい
→ brainstorming スキルが自動で立ち上がる
明示的に呼びたいときは「superpowers:brainstorming スキルを使って設計を詰めて」と自然言語で指定します。
4. インストールと動作確認
4.1 Claude Code へのインストール（2通り）
方法A: Anthropic 公式マーケットプレイス（推奨・最も簡単）
/plugin install superpowers@claude-plugins-official
方法B: Superpowers コミュニティマーケットプレイス（関連プラグインも欲しい場合）
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
インストール後は Claude Code を再起動してください。SessionStart フックは新しいセッションから効きます。
4.2 動作確認
新しいセッションを立ち上げて、こう投げてみます。
簡単なTODOリストのReactコンポーネントを作りたい
すぐコードを書き始めたら失敗です。正しく動いていれば、エージェントは
- プロジェクトの現状（ファイル構成、最近のコミット、既存ドキュメント）を確認し
- 「TODOの永続化は必要ですか？ a) localStorage b) API c) メモリのみ」のように1問ずつ質問してきます
これが出れば brainstorming スキルが発火しています。
4.3 アップデート
/plugin update superpowers
Claude Code は自動更新される場合もあります。バージョンは /plugin メニューから確認できます。
4.4 他ハーネスへのインストール
Superpowers は Claude Code 専用ではありません。同じスキル体系を複数のエージェントに配れます（ハーネスごとに個別インストールが必要）。
| ハーネス | コマンド |
|---|---|
| Antigravity | agy plugin install https://github.com/obra/superpowers |
| Codex CLI |
/plugins → superpowers を検索してインストール |
| Cursor | /add-plugin superpowers |
| Factory Droid |
droid plugin marketplace add https://github.com/obra/superpowers → droid plugin install superpowers@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 |
| Kimi Code |
/plugins → Marketplace → Superpowers |
| OpenCode |
.opencode/INSTALL.md を fetch して従わせる |
| Pi | pi install git:github.com/obra/superpowers |
チーム全体で「使うAIエージェントは違うが、開発プロセスは揃えたい」というケースで効きます。
5. スキル一覧リファレンス
現行の Superpowers はおおむね14スキル構成です。カテゴリ別に整理します。
5.1 コラボレーション / 計画系
| スキル | 発動タイミング | 何をするか | 成果物 |
|---|---|---|---|
| brainstorming | 創作作業の前（必須ゲート） | ソクラテス式に1問ずつ質問。2〜3の設計案とトレードオフを提示。設計を200〜300語のチャンクに区切って承認を取る | docs/plans/YYYY-MM-DD-topic-design.md |
| writing-plans | 設計承認後 | 「文脈ゼロで判断力のない新人でも follow できる」粒度に分解。1タスク2〜5分 | 実装計画 .md
|
| executing-plans | 計画完成後（別セッション推奨） | 3タスク程度のバッチ実行＋人間のチェックポイント | 進捗更新 |
| subagent-driven-development | 計画完成後（同一セッション） | タスクごとに新鮮なサブエージェントを起動し、レビューを挟んで前進 | コミット群 |
| dispatching-parallel-agents | 独立タスクが複数あるとき | 並列にサブエージェントを分配 | — |
| requesting-code-review | タスク間 | 計画との差分をレビューし、重大度別に issue を報告。Critical はブロック | レビュー結果 |
| receiving-code-review | レビュー受領時 | 指摘の取り込みプロセス。技術的根拠があれば反論も許可されている | 修正 |
5.2 品質保証系
| スキル | 鉄則 | 内容 |
|---|---|---|
| test-driven-development | 「失敗するテストなしにプロダクションコードを書いてはならない」 | RED → 失敗確認 → GREEN → 成功確認 → COMMIT → REFACTOR。テストより先に書かれたコードは削除してやり直し。「参考に残す」も禁止 |
| verification-before-completion | 「検証の証拠なしに完了宣言してはならない」 | 実際にコマンドを実行し出力を確認。「たぶん動く」は不可 |
test-driven-development に付属する参照ドキュメントは v6.2.0 で testing-anti-patterns.md から writing-good-tests.md に改名され、「良い例から入る6つのルール」の正の catalog に書き直されました。ここには反証可能性（falsifiability）の規律が入っています。
- そのテストを失敗させるプロダクション変更を名指しできるか
- 期待値をコード側から導出していないか（実装を読んで期待値を作るな）
- 最後に mutation チェックをかける
そして2つの罠が名指しで潰されています。
- string-presence trap: スクリプトやスキル、プロンプトに対する grep 的テストは反証可能性の偽物。観測対象は常に「振る舞い」であってテキストではない
- change-detector trap: 定数のアサーションは、失敗しても何も守っていない
5.3 デバッグ系
| スキル | 内容 |
|---|---|
| systematic-debugging | 4フェーズの根本原因プロセス。① Root Cause Tracing ② Pattern Detection ③ Hypothesis Testing ④ Implementation。3回修正に失敗したらアーキテクチャレビューに強制切替。root-cause-tracing / defense-in-depth / condition-based-waiting のテクニック集を同梱 |
5.4 Git 運用系
| スキル | 内容 |
|---|---|
| using-git-worktrees | 設計承認後に隔離ワークツリーを作成。プロジェクトセットアップ（npm install 等）を実行し、着手前にテストがグリーンであることを確認（＝ベースライン取得） |
| finishing-a-development-branch | 全テスト通過を確認し、4択を提示: ローカルマージ / PR作成 / ブランチ保持 / 破棄。破棄は誤操作防止のため discard の入力が必須 |
💡 v6.0.0 でワークツリーの置き場所が変わりました。旧
~/.config/superpowers/worktrees/は廃止され、プロジェクト内の.worktrees/（既存のworktrees/があればそちら） に作られます。
5.5 メタ系
| スキル | 内容 |
|---|---|
| using-superpowers | スキルシステムの入口。「1%ルール」を敷くブートストラップ |
| writing-skills | 新しいスキルを TDD の考え方で作る方法論 |
6. 実践: 機能開発を最初から最後まで通してみる
ここからが本番です。「既存の Express API に、レート制限機能を追加する」という題材で、実際のセッションの流れを追います。
Step 0. 依頼する
このAPIにレート制限を入れたい
たった1行で構いません。ここで詳細に書きすぎると、むしろ brainstorming の質問が浅くなります。あえて曖昧に投げるのがコツです。
Step 1. brainstorming — 設計を殴り合いで決める
エージェントはまずリポジトリを読みます（package.json、既存ミドルウェア、docs/、直近のコミット）。その上で1問ずつ聞いてきます。
Q1: レート制限のスコープはどれですか？
a) IPアドレス単位
b) 認証済みユーザーID単位
c) APIキー単位
d) 上記の組み合わせ
この段階でのユーザー側のベストプラクティス:
- 選択肢に無い答えがあるなら遠慮なく書く（「c だが、未認証リクエストは IP で」など）
- 「わからない、おすすめは？」と返してもよい。トレードオフを説明してくれます
- 質問が10問を超えて冗長になってきたら「残りは任せる、デフォルトで進めて」と打ち切れます
その後、設計案が 200〜300語のセクション単位で提示されます。全文を一気に出さないのは「人間が実際に読める長さ」に切るためです。各セクションで承認/修正を求められるので、ここで気に入らない部分を潰します。ここが最も費用対効果の高い介入ポイントです。
最終的に docs/plans/2026-08-04-rate-limiting-design.md のような設計ドキュメントが保存され、コミットされます。
Step 2. using-git-worktrees — 隔離環境を作る
# エージェントが実行する内容（イメージ）
git worktree add .worktrees/rate-limiting -b feature/rate-limiting
cd .worktrees/rate-limiting
npm install
npm test # ← ベースラインがグリーンであることを確認
ここでベースラインが赤い場合、エージェントは先に進みません。「元から壊れていたテスト」を自分のせいにしないための仕組みです。地味ですが非常に重要です。
Step 3. writing-plans — 実装計画に落とす
設計ドキュメントを入力に、実装計画が生成されます。タスクの粒度はこうなります。
### Task 7: レート超過時に 429 を返すテストを書く
**File**: `test/middleware/rateLimit.test.ts`
**Action**: 以下を追記する
```ts
it('returns 429 when the limit is exceeded', async () => {
const app = createApp({ windowMs: 1000, max: 2 });
await request(app).get('/api/items');
await request(app).get('/api/items');
const res = await request(app).get('/api/items');
expect(res.status).toBe(429);
});
```
**Verify**: `npm test -- rateLimit` を実行し、
`returns 429 when the limit is exceeded` が **失敗する** ことを確認する。
### Task 8: 429 を返す実装を追加する
...
注目してほしいのは、「テストを書く」「失敗を確認する」「実装する」「成功を確認する」「コミットする」が別々のタスクになっていることです。これが TDD を構造的に強制する仕掛けです。「1タスク2〜5分」というルールは、この分割から自然に導かれます。
計画ができたら必ず自分で読んでください。ここで気づける手戻りは実装後の10倍安いです。特に見るべきは:
- ファイルパスが実在するか
- 依存ライブラリの追加が妥当か
- タスクの順序に前提の飛びがないか
Step 4. 実行方式を選ぶ
2つの選択肢があります。
| subagent-driven-development | executing-plans | |
|---|---|---|
| セッション | 同一セッション内 | 別セッション推奨 |
| 単位 | タスクごとに新鮮なサブエージェント | 3タスク程度のバッチ |
| レビュー | タスクごとに自動レビュー | バッチ間で人間のチェックポイント |
| 速度 | 速い。数時間の自律走行も可能 | 遅いが安全 |
| 向く場面 | 計画に自信がある / 規模が大きい | 初導入時 / 重要な本番コード |
最初の数回は executing-plans で人間チェックポイントを挟むことを強く推奨します。Superpowers の挙動に慣れてから SDD に移行するのが安全です。
Step 5. subagent-driven-development の内部で起きていること
SDD を選んだ場合、タスクごとにこのループが回ります。
なぜ「新鮮なサブエージェント」なのか: コンテキストが汚れていないエージェントは、前のタスクの思い込みを持ち込みません。これがロングランでの品質劣化を防ぎます。
なぜ「レビューは1体で2つの判定」なのか: v6.0.0 で仕様レビュアーと品質レビュアーが1つの task-reviewer-prompt.md に統合されました。同じ diff を2回読ませるのが無駄だっただけでなく、判定が分かれると修正パスが2回走るためです。統合により evals では 約2倍速・トークン約50%削減という結果が報告されています。
さらに「diff からは検証できない」という第3の判定が追加されました。要件が触っていないコードに存在する場合、レビュアーは無理に判断せずコントローラーにエスカレートします。
Step 6. finishing-a-development-branch — 締める
全タスク完了後、ブランチ全体を最も高性能なモデルで1回だけ通しレビューします（タスクごとの再レビューを繰り返すより安く、かつ全体整合性を見られる）。その後4択が提示されます。
1. ローカルの main にマージする
2. Pull Request を作成する
3. ブランチをそのまま残す
4. ブランチを破棄する（"discard" と入力が必要）
ワークツリーのクリーンアップもここで行われます。
7. 実践: バグ修正を systematic-debugging で回す
「本番でたまに 500 が出る」というよくある依頼を投げると、systematic-debugging が発火します。
Phase 1: Root Cause Tracing（根本原因の追跡）
症状から上流に遡ります。エラーが出た場所ではなく、不正な状態が最初に生まれた場所を探します。ログ、スタックトレース、再現手順を集める段階で、まだ修正はしません。
Phase 2: Pattern Detection（パターン検出）
「同じ形のバグが他にもないか」を探します。1箇所直して満足するのを防ぐフェーズです。
Phase 3: Hypothesis Testing（仮説検証）
仮説を明示的に立て、それを反証できるテストを書きます。「たぶんこれだろう」で直接コードを触るのは禁止です。
Phase 4: Implementation（実装）
ここでようやく修正します。当然 TDD なので、まず失敗するテストから入ります。
3回ルール
修正が3回失敗したら、アーキテクチャレビューに強制的に切り替わります。これは「同じレイヤーで殴り続けても解けない問題は、設計が間違っている」という経験則の実装です。人間のデバッグでも有効な発想なので、覚えておく価値があります。
また systematic-debugging には便利なテクニック集が同梱されています。
- root-cause-tracing: 症状から原因への遡行手順
- defense-in-depth: 多層防御での再発防止
-
condition-based-waiting:
sleep(3000)のような時間待ちを条件待ちに置換する（フレーキーテストの主要因潰し） - find-polluter: テスト間の状態汚染犯を特定する
8. 実践: 自作スキルを writing-skills で書く
チーム固有のルール（「APIのエラーレスポンスは必ず RFC 7807 形式」など）をスキル化したくなります。writing-skills はスキル作成にも TDD を適用します。
| フェーズ | やること |
|---|---|
| RED | スキルなしでエージェントを走らせ、望ましくない振る舞いを記録する。これが「失敗するテスト」 |
| GREEN | その失敗を解消する最小限のスキルを書く |
| REFACTOR | 再度走らせ、エージェントが編み出した新たな言い訳を見つけ、対策行を追加する |
ポイントは「エージェントは必ず抜け道を探す」という前提に立っていることです。1回書いて終わりではなく、実際に走らせて破られたところを塞ぐという反復が前提になっています。
なお v6.2.0 では、Superpowers 自身のスキルに対して大規模な圧縮キャンペーンが行われました。「そのスキルを既に起動した読者に向けた」再掲・社会的証明・メリット訴求の散文はすべて削除され、論拠は合理化テーブルの行か、使用箇所そのものに折り畳まれています。カットのたびにサブエージェントで micro-test を行い、振る舞いが計測可能に劣化した1件だけは作り直して出荷したという記述があり、スキル執筆の姿勢として非常に参考になります。
自作スキルを本家に PR したい場合は注意。新規スキルの寄稿は原則受け付けておらず、既存スキルへの変更もサポート対象の全ハーネスで動くことが条件です。作業は
devブランチから切ります。
9. 設計思想の肝: Iron Law と合理化テーブル
Superpowers が他の「プロンプト集」と決定的に違うのは、この2つの仕掛けです。
9.1 Iron Law（鉄則）— 交渉不可能な原則
各スキルには、例外を認めない一文が置かれています。
| スキル | Iron Law |
|---|---|
| test-driven-development | 失敗するテストなしにプロダクションコードは存在してはならない |
| systematic-debugging | 根本原因の調査なしに修正してはならない |
| verification-before-completion | 検証の証拠なしに完了を宣言してはならない |
| brainstorming | 設計の承認なしに実装に入ってはならない |
「原則」ではなく「法」として書かれているのがポイントです。LLM は「原則」を状況に応じて曲げますが、「例外なし」と明示されると曲げにくくなります。
9.2 合理化テーブル（Rationalization Table）— 言い訳への先回り
さらに巧妙なのがこちらです。エージェントが規律を回避するときに実際に使う典型的な言い訳を列挙し、それぞれに反論を用意しています。
| エージェントの言い訳 | 用意された反論（要旨） |
|---|---|
| 「この変更は小さいのでテスト不要」 | 小ささはテストの有無と無関係。小さい変更のバグは見つけにくい |
| 「手動で確認したので十分」 | 手動確認は再実行できない。次の変更を守らない |
| 「後でテストを書きます」 | 後で書かれたテストは実装に合わせて書かれ、反証力を失う |
| 「参考のため実装を残しておきます」 | テスト前に書かれたコードは削除する。残せば必ず流用される |
| 「エラーは無関係なので無視します」 | 無関係の証明が先。証明できないなら関係がある |
これはLLM の振る舞いを実測して逆算した設計です。v6.2.0 では、各スキルの「Red Flags」セクションもこの合理化テーブル形式に統一されました。
自分でスキルやプロンプトを書くとき、この「言い訳先回りテーブル」は非常に応用が効くパターンです。Superpowers を使わないとしても、この発想だけは持ち帰る価値があります。
10. v6 系の重要アップデート
導入するなら知っておきたい直近の変更点です。
v6.2.0（2026-07-23）
① SDD ワークスペースが plan スコープになった
従来 .superpowers/sdd/ にはプラン識別子も終了処理も無く、同じ作業ツリーで次のプランを始めると、前のプランの進捗台帳を自分のものとして読んでしまう事故が実際に起きていました。
v6.2.0 では:
-
sdd-workspaceがプランファイルを必須引数として取り、.superpowers/sdd/<plan-basename>/を解決する -
task-briefとreview-packageはそのプランのディレクトリに書き込む（review-packageは第1引数にプランファイルを取るよう変更） - 台帳の1行目に自分のプラン名を書く
- 最終レビューがクリーンになった時点でワークスペースを削除する。永続的な記録は git 履歴が担う
ベースライン eval では、コントローラーは他プランの台帳を拒否できてはいたものの、resume のたびに 6〜13回のツールコールをクロスプラン git 調査に費やしていました。plan スコープ化はこれを構造的に解決したものです。
② レビュー修正ループが「実装者を resume する」方式に
- 修正ラウンドが「新しいエージェントを毎回投げる」から「同じ実装者を再開する」に変更
-
re-review-prompt.mdにより、再レビュー担当はタスク全体を読み直さず修正差分だけを見る - 5ラウンドのサーキットブレーカーを追加。トリップしたらコントローラーが裁定する
v6.1.x（2026-06〜07）
-
トークンコスト最適化:
using-superpowersブートストラップを圧縮。Graphviz のスキルフロー図を散文に置換し、プラットフォーム別の「スキルへのアクセス方法」解説を削除 - ハーネス別の冗長なツールマッピング表を削除（
claude-code-tools.md、copilot-tools.mdは削除） - Codex 向けのフック自動検出問題を修正（
hooks: {}を明示宣言）
v6.0.x（2026-06）
-
レビュアー統合:
spec-reviewer-prompt.md+code-quality-reviewer-prompt.md→task-reviewer-prompt.md。evals で約2倍速・トークン約50%削減 -
SDD スクラッチ領域の移動: Claude Code が
.git/を保護パスとして書き込み拒否するため、実装サブエージェントがレポート書き込みでブロックされていた。.superpowers/sdd/に移動 - 新ハーネス対応: Kimi Code、Pi、Antigravity
-
ワークツリー配置変更:
~/.config/superpowers/worktrees/→ プロジェクト内.worktrees/ - 最終レビューは1回だけ: タスクごとの再レビュー反復ではなく、最も高性能なモデルでブランチ全体を1回レビュー
⚠️ 既知の落とし穴:
.superpowers/sdd/は git-ignore された作業ツリー上のスクラッチです。git clean -fdxを打つと進捗台帳が消えます。消えた場合は git log から復元してください。
11. 運用のコツ・アンチパターン・トラブルシュート
11.1 効果を最大化する使い方
① 最初の依頼はあえて短く
brainstorming の価値は「あなたが言語化できていない要件」を掘り出すことにあります。仕様書を貼り付けると、その範囲の質問しか出ません。
② 設計フェーズにこそ時間を使う
介入コストは 設計 << 計画 << 実装 << 本番 の順に跳ね上がります。設計セクションの承認で「まあいいか」と流したものは、100%後で戻ってきます。
③ 計画ドキュメントを人間が読む
これが Superpowers 導入者と非導入者の差が一番出るポイントです。計画は Markdown なので5分で読めます。ここでの1つの指摘が数時間を節約します。
④ 長時間の自律走行は worktree の中でやらせる
using-git-worktrees が効いていれば main は汚れません。安心して数時間放置できます。逆に worktree を作らせずに SDD を回すのは危険です。
⑤ 別セッションに分ける
writing-plans と executing-plans は別セッションで動かすのが公式推奨です。計画作成時の文脈が実装時のバイアスにならず、計画書の自己完結性も検証できます（＝計画に書き忘れがあれば実装セッションで詰まる）。
11.2 よくあるトラブル
| 症状 | 原因 | 対処 |
|---|---|---|
| スキルが全く発火しない | SessionStart フックが動いておらず、ブートストラップが注入されていない | Claude Code を再起動。プラグインが有効か /plugin で確認。Windows では Git Bash 経由でフックが起動する（v6.2.0 で修正済） |
/brainstorm が無い、または Deprecated と出る |
v5.1.0 でスラッシュコマンドは廃止 | 自然言語で依頼する。明示するなら「superpowers:brainstorming を使って」 |
| 進捗台帳が消えた |
git clean -fdx で .superpowers/ ごと削除された |
git log から復元。以後 git clean は -e .superpowers を付ける |
| 前のプランの進捗を引き継いでしまう | v6.2.0 未満のワークスペース非スコープ問題 | v6.2.0 以上に更新する |
| プロセスが重い・冗長すぎる | 小さすぎるタスクに適用している | 1ファイルの軽微修正では Superpowers を使わない判断も有効（後述） |
| トークン消費が気になる | ブートストラップ + 多段レビューの構造上のコスト | v6.0/v6.1 で大幅に削減済み。それでも重い場合は executing-plans で人間レビューに寄せる |
| テストがフレーキー | 時間待ち / テスト間汚染 |
systematic-debugging の condition-based-waiting と find-polluter を使う |
11.3 テレメトリを切りたい場合
brainstorming のビジュアルコンパニオン機能では、Prime Radiant のロゴが同社サイトから読み込まれ、その際に Superpowers のバージョン情報が送信されます。プロジェクトやプロンプト、使用エージェントの情報は含まれません。
無効化するには環境変数を設定します。
export SUPERPOWERS_DISABLE_TELEMETRY=1
Claude Code の DISABLE_TELEMETRY および CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC も尊重されます。企業環境で導入する場合は、この点をセキュリティレビューに含めておくとスムーズです。
12. 他のアプローチとの比較
| 観点 | 素の Claude Code | CLAUDE.md にルール記述 | Superpowers |
|---|---|---|---|
| 導入コスト | 0 | 低（自分で書く） | 低（コマンド2行） |
| プロセス強制力 | なし | 弱い（読み飛ばされる） | 強い（1%ルール + 鉄則 + 合理化対策） |
| TDD の徹底 | 依頼次第 | 「なるべく」レベル | 構造的に強制（タスク分割レベルで） |
| 設計フェーズ | なし | 書けば一応 | 必須ゲート + 設計ドキュメント生成 |
| レビュー | なし | 自作次第 | タスク単位 + ブランチ全体の2層 |
| 長時間自律実行 | 迷子になる | 迷子になりやすい | 台帳 + worktree で数時間走れる |
| チーム標準化 | 個人のプロンプト力に依存 | リポジトリ単位で共有可 | 複数ハーネス横断で統一可 |
| トークンコスト | 低 | 低 | 中（v6 で大幅削減） |
| 小さな作業への適合 | ◎ | ◎ | △（過剰） |
CLAUDE.md との併用は普通に有効です。 Superpowers が「開発プロセスの型」を、CLAUDE.md が「このプロジェクト固有の事情（ディレクトリ規約、使用ライブラリ、デプロイ手順）」を担当する、という分担が綺麗です。実際 using-git-worktrees は worktree の配置先を CLAUDE.md の記述から読む設計になっています。
13. 導入前に押さえるべき注意点
13.1 向いている人 / 向いていない人
向いている
- AI 生成コードの品質のばらつきに困っている
- 数十ファイルにまたがる中〜大規模な機能開発を任せたい
- TDD をやりたいが、AI がテストを後回しにしがち
- チームで Claude Code を導入していて、プロセスを揃えたい
- TDD や体系的デバッグを学習教材として読みたい（スキルは全部 Markdown なので読めます）
向いていない
- ワンライナーや1ファイル修正が作業の中心
- すでに自前のスキル/ワークフローが完成している
- 探索的なプロトタイピングを高速に回したい（設計ゲートが摩擦になる）
13.2 セキュリティ・ガバナンス面
- MIT ライセンスでコードは全文読めます
- スキルの実体は Markdown であり、実行可能バイナリではありません。ただしフックはシェルスクリプトを実行します。企業導入時はここを確認してください
- サードパーティ製プラグインであることに変わりはありません。組織のポリシーに応じてリポジトリを監査するか、フォークして社内マーケットプレイスから配布する運用が安全です
- 前述のテレメトリの扱いを事前に確認・無効化しておくこと
13.3 コスト感
多段レビュー + サブエージェントという構造上、素の Claude Code よりトークンを消費します。ただし v6.0.0 でレビュアー統合により evals で約50%削減、v6.1.0 でブートストラップ圧縮が行われており、「手戻り込みの総コスト」で見ればむしろ安くなるケースが多いというのが導入者の一般的な感想です。まずは小さめの機能1本で計測してみることをおすすめします。
14. まとめ
Superpowers の本質は、「AI にプロセスを教える」のではなく「AI がプロセスを破れない構造を作る」ことにあります。
押さえるべき要点を再掲します。
- 実体は Markdown のスキル集。SessionStart フックが
using-superpowersを注入して初めて機能する - スラッシュコマンドは v5.1.0 で廃止。自然言語で依頼すれば自動発火する
- 中核フローは
brainstorming → using-git-worktrees → writing-plans → SDD/executing-plans → TDD → code-review → finishing-a-development-branch - Iron Law（交渉不可能な原則）と合理化テーブル（言い訳への先回り反論）が規律を支えている
- v6.2.0 で SDD ワークスペースが plan スコープ化され、修正ループが「実装者 resume + 5ラウンドのサーキットブレーカー」に
- 最も費用対効果が高い人間の介入点は 設計セクションの承認と実装計画の通読
まずは公式マーケットプレイスから入れて、小さめの機能で1周させてみてください。「1問ずつ質問してくる」あの体験だけで、なぜこれが26万 Star なのか納得できるはずです。
参考リンク
- 公式リポジトリ: https://github.com/obra/superpowers
- リリースノート: https://github.com/obra/superpowers/blob/main/RELEASE-NOTES.md
- Superpowers マーケットプレイス: https://github.com/obra/superpowers-marketplace
- Anthropic 公式プラグインページ: https://claude.com/plugins/superpowers
- 関連プラグイン:
elements-of-style（文章作法）、superpowers-developing-for-claude-code（プラグイン開発用、公式ドキュメント42本以上を同梱）、private-journal-mcp、episodic-memory、superpowers-chrome
本記事の内容は Superpowers v6.2.0 時点の情報に基づいています。活発に開発されているプロジェクトのため、最新の仕様は公式リポジトリの RELEASE-NOTES.md をご確認ください。