AIDive

動画パック

Claude Code 用 Superpowers: 判定表、ソース、チェックリスト、さらに読むためのガイド

9 分で読めます

TL;DR

  • Superpowers はツールボックスではなくプロセスです。14 個の markdown スキルが、すべての機能をブレインストーミング、書面の計画、レビュー付きの新しいサブエージェントの連鎖という関門の向こうに置きます。
  • 数時間かかる機能を Claude Code で作るなら入れる価値があります。使い捨てスクリプトや 2 行の修正が中心なら見送ってください。入口のチェックはすべてのタスクで走り、オフになりません。
  • トークン節約の主張は本物ですが、根拠は 1 つのスキルの 1 つのセクション、Model Selection だけです。オーケストレーターは役割をこなせる最も安いモデルを割り当てるので、高価なモデルが触れるのは設計と最後のブランチレビューだけです。
  • リポジトリは健全です。スター 280,597、フォーク 25,138、main のコミット 681、2026-08-12 のリリース v6.3.0、作成日は 2025-10-09 です。
  • 動画のきっかけになった不満、使用統計が 1 から 3 パーセントという点はバグではありません。スキルがあなたの作業で一度も発動していないという意味で、関門のコストだけ払って見返りがない状態です。
  • 中間案はプロンプトに一文入れることです。小さな修正ではプロセスを飛ばすようエージェントに伝え、残りを採用する前に数日間ブレインストーミングだけを動かします。

ソースが語ること

リポジトリの数値は 2026-09-02 に確認しました。スター 280,597、フォーク 25,138、main ブランチのコミット 681 で、main の最終コミットは 2026-08-12 (v6.3.0)、その後 2026-08-31 に main 以外のブランチへ push があります s1。その日の Issues タブには未解決の issue が 125 件ありました。API の 350 という数字には未解決の pull request 225 件が含まれるため、他のプラグインと比べるときは API ではなくタブの数字を引用してください s6。プロジェクトは 2025-10-09 に作られ、14 個のスキルを備えています s2。作者のローンチ記事は賭けを一言で説明しています。コーディングエージェントに足りないのは能力ではなく規律で、その規律は誰でも読めて fork して編集できる素の markdown ファイルとして配れる、というものです s5。プラグインは公式マーケットプレイスに載っているので、インストールはコマンド 1 つで、更新もマーケットプレイスに従います s4。

入口になるのは、セッション開始フックが何よりも先に読み込むスキルです。スキルが当てはまるか少しでも迷うなら、回答やコード作成の前にそれを読み込んで確認しなければならない、とエージェントに伝えます。このルールが、利点と固定コストの両方の源です s14。

ブレインストーミングは HARD-GATE から始まります。意図を明示的に確認するまで、コードも足場作りも実装スキルもありません。そのうえで依頼を 3 つの道に振り分けます。出力がコードではなく答えである spike、リポジトリに既にある流れの中の小さな変更である bounded、プロジェクトの構造を変えるものすべてを指す architectural です。エージェントは分類を宣言するので、あなたは異議を唱えられます。ラチェットは一方向で、作業中に隠れた複雑さが見つかれば道は上がり、下がることはありません s9。

計画作成スキルは、あなたのコードベースの文脈を持たない有能な開発者、しかもファイルの言葉を借りれば「趣味が怪しい」開発者に向けて計画を書くよう求めます。作業は、各ステップが 2 分から 5 分で終わるタスクに切られます。失敗するテストを書く、失敗を確認する、最小のコードを書く、テストを再実行する、コミットする、という流れです。各タスクは作成または変更するファイルを行番号まで正確に挙げ、計画は必須のヘッダーで始まります s10。

実行を担うのは subagent-driven development スキルです。タスクごとに新しいサブエージェントを 1 つ使い、タスクごとにレビューし、最後にブランチ全体をレビューします。メインセッションはコードを書くのをやめ、ディスパッチに専念します。各サブエージェントが受け取るのは自分のタスクの文脈だけで、あなたのセッション履歴は渡されないため、あなたのウィンドウは調整のために空いたままです。サブエージェントが実装、テスト、コミット、自己レビューを終えると、オーケストレーターは 2 段階のレビューを行います。先に仕様への適合、次にコード品質で、レビュアーの席はタスクごとに確保されます。ファイルはループをタスクあたり最大 5 ラウンドに制限しています s11。作業の隔離は worktree スキルに委ねられているので、計画が今のチェックアウト上で走ることはありません s13。

Model Selection セクションは 1 つのルールで始まります。役割をこなせる中で最も能力の低いモデルを使う、というものです。仕様が明確で 1、2 ファイルに触れる機械的なタスクは小さなモデルへ回します。書くべきコードが計画に既に含まれているなら、実装は書き写しとテストなので最安の層で足ります。複数ファイルにまたがる調整とデバッグは標準モデルへ。設計と最後のブランチレビューには、使える中で最も高性能なモデルを求めます。実務で効く細部は 2 つあります。ディスパッチ時に必ずモデルを明示すること、そして選ぶ前にオーケストレーターに各タスクの難易度を評価させることです s12。月 20 ドルの Pro プランで高価なモデルを使い続けられるのはこの仕組みのおかげで、高価なモデルは、それに値する判断だけを担当します。

ドキュメントが残るのは、プロセスの副産物です。仕様と計画は消えるチャットメッセージではなく、リポジトリに保存されて作業と一緒にコミットされる markdown ファイルです。後からレビューする人は、何が変わったかだけでなく、なぜ変えたのかも読めます s3。

コストは、リポジトリが宣伝しない部分です。動画のきっかけになったスレッドは、使用統計が 1 から 3 パーセントだと報告し、使わないこと以外の欠点は何かと尋ねています s7。ファイルから読み取れる答えは、ブレインストーミングは儀式の大きさをタスクに合わせて調整するが、人間による確認は決して省かない、ということです s9。2 行の修正でも、枠組みの質問に答え、2 文の設計を承認し、サイクル全体を待つことになります。ディスパッチ用のブリーフ、タスクごとの 2 回のレビュー、追跡台帳は毎回払うトークンで、最も小さなタスクで目立ちます。使用統計が低いのは、スキルがあなたの作業と一致していないということで、読み取るべき本当のシグナルはそこです。

使い方別の判定

Claude Code の使い方 入れる? 理由
数時間かかる機能、複数ファイル、ブランチ単位の作業 はい 枠組みづくりで作るものを間違えずに済み、短いタスクでエージェントがコンテキスト飽和から遠ざかり、モデル選択でクォータが伸び、ドキュメントはプロセスから自然に残る
混在: 機能の日もあれば、大半は修正の日 はい、スキップルール付き 機能には関門を残し、小さな修正ではプロセスを飛ばすようプロンプトでエージェントに伝える
使い捨てスクリプト、設定のタイプミス、2 行の修正 いいえ 不要なタスクにも関門の固定コストがかかる
気になるが、手法全体を採用する準備はない ブレインストーミングだけ 利点の大半はこれにあり、他のスキルはあとから自然に足せる

月曜にやること

  • 公式マーケットプレイスからインストールし、プラグインのキャッシュを開く。14 個の SKILL.md を一度読む。短く、それが製品のすべてです。
  • 実際の機能を 1 つ、関門を通して最後まで走らせる。ブレインストーミング、計画、サブエージェントのディスパッチ、ブランチレビュー。プロセスは修正ではなく、これで判断します。
  • 1 週間後に使用統計を確認する。数パーセントを下回るなら、スキルがあなたの作業と合っていません。タスクが小さすぎるか、依頼を機能として書く必要があります。
  • プロジェクトの指示にスキップルールを足す。数行未満の 1 ファイル修正では、ブレインストーミングなしで直接変更に入る。
  • プラグインをやめる場合でも、Model Selection の段階表を自分のサブエージェント用プロンプトに写す。ディスパッチのたびにモデルを明示する。
  • プラグインが書いた仕様と計画は消さずにコミットする。それがあなたの設計記録になります。
  • 他のプラグインと比べる前に、API の数字ではなく Issues タブの未解決 issue 数を数える。

さらに読む

  • スキルファイルの前に、まずローンチ記事で設計意図を読む。規律がコードではなく markdown として配られる理由が書かれています s5。
  • README の philosophy セクションは手法の短縮版で、自分の今のやり方に合うか確かめる場所です s3。
  • skills library セクションは 14 個のスキルを 1 行ずつの目的付きで並べています。ディレクトリを見て回るより早いです s16。
  • サブエージェントスキルの「タスクあたり最大 5 ラウンド」は明確な停止条件で、手で書くオーケストレーションにも写す価値があります s11。
  • この種のプラグインはより強いモデルの時代にも生き残るのか、と問うスレッドがあります。残るのは枠組みの関門とコミットされた計画で、モデルに吸収されるのは仕組みの部分です s19。
  • オーケストレーションの儀式で週の使用上限が焼かれたという報告は、小さな作業に導入する前に読むべき反例です s20。
  • 競合する指示セットとの比較がトレードオフを示します。少数で厳格なスキルと、大量のルールカタログの対比です s18。
  • 未解決 issue の一覧は、今日ほかのユーザーで何が壊れているかを知る最速の手段です s6。

ソース

FAQ

Superpowers はトークンを節約しますか、それとも燃やしますか?

両方です。機能開発では、モデル選択が機械的なタスクを小さなモデルに回し、高価なモデルを設計とブランチレビューに残すので、クォータが伸びます。小さな修正では、ブリーフ、タスクごとの 2 回のレビュー、台帳は純粋なオーバーヘッドです。

使用統計が 1 から 3 パーセントとは何を意味しますか?

スキルは状況が一致したときだけ発動します。数字が低いのは、あなたのタスクがプラグインの言う意味での機能ではないということで、入口のチェックだけ払い、見返りのある部分には届いていません。

一部だけ使えますか?

はい。ブレインストーミングだけで利点の大半が得られ、Model Selection の段階表は手書きのサブエージェント用プロンプトでも使えます。小さな修正ではプロセスを飛ばすようエージェントに伝えれば、主導権はあなたに残ります。