Superpowers Claude Code版ガイド：導入手順と15のスキル

Superpowers Claude Code版とは？

Superpowersは、Jesse Vincentが作成した開発スキル集と、コーディングエージェントにそのスキルを使わせるための指示をまとめたものです。 リポジトリを操作するAnthropicのコーディングアシスタントClaude Codeに、依頼の理解、変更計画、テスト、デバッグ、作業の委任、ブランチでの開発を完了するためのワークフローを提供します。工房の作業マニュアルに例えると分かりやすいでしょう。道具はすでにそろっており、マニュアルが作業の順序と引き渡し前の確認事項を定める、という関係です。SuperpowersのREADME

2026年10月18日に確認した内容： ソースのマニフェストに記載されたバージョンは7.0.0で、リポジトリにはSKILL.mdを含む最上位のスキルフォルダーが15あります。これは本記事で確認したソースの状態です。利用するマーケットプレイスがどのリビジョンをインストールするかは、別途確認してください。プラグインのマニフェスト、スキルディレクトリ

実用上の魅力は、判断の流れを目で追えることです。Claudeは機能を変更する前に、期待する動作を明確にできます。完了を宣言する前には、改めて実行したテストの結果を求めることもできます。こうした指示によって、利用者が具体的に確認できるものが残ります。ただし、要件やテストそのものが正しいことまで保証されるわけではありません。

Claude CodeにSuperpowersをインストールするには？

プロジェクトのREADMEに記載された方法のいずれかを、Claude Code内で実行します。 以下はREADMEのClaude Code向けセクションから、そのまま抜き出したコマンドです。対話画面で使うスラッシュコマンドであり、通常のシェルに貼り付けるものではありません。READMEのインストール手順

公式マーケットプレイスからSuperpowersを導入するコマンド

/plugin install superpowers@claude-plugins-official

開発元独自のマーケットプレイスを使う方法も案内されています。こちらを選ぶ場合は、マーケットプレイスを登録してからインストールします。

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

管理しやすい配布元を選んでください。同じプラグインの導入手順として、両方を実行する利点はありません。

インストール後はClaude Codeの新しいセッションを開始し、起動フックを動かします。「既存のタスク一覧にフィルターを追加する」など、範囲を限定した機能を依頼してみてください。確認すべきなのは、適切なスキルの使用を宣言し、そのスキルで定められた動作に従うかどうかです。インストールコマンドが完了したことと、ワークフローが期待どおりに動くことは、それぞれ別に確認する必要があります。

インストール後、セッションはどう変わる？

最初に変わるのはコンテキストです。起動フックがSuperpowersの使い方に関する指示を会話に追加します。 設定されたSessionStartのマッチャーは、startup、clear、compactを対象にしています。スクリプトはusing-superpowersを読み込んでそのテキストを挿入し、ほかのスキルをSkillツールで読み込むようClaudeに指示します。起動時のメッセージに、すべてのスキルの全文を貼り付けるわけではありません。フック設定、起動スクリプト

Superpowersはどのようにスキルを選ぶ？

Claudeが作業内容と各スキルの説明を照合し、関連する指示を読み込みます。 プラグインのスキル作成ガイドでは、説明文に「どのような場面で使うか」を記すよう求めています。初期指示は、応答や操作の前にスキルを確認し、使うスキルを宣言し、実装用のスキルより先に手順を定めるスキルを適用するようエージェントに指示します。スキルを見つけるための説明文の書き方

そのため、何かを作る依頼ならbrainstorming、テストの失敗ならsystematic-debuggingが候補になります。その後、分野別のスキルで実装を進められます。スキル名を指定して依頼することも可能です。たとえば「修正案を出す前に、superpowers:systematic-debuggingを使ってこの失敗を調べてください」と伝えられます。利用時の指示

自動選択はモデルへの指示であり、キーワードに応じて必ず同じ処理に切り替わる仕組みではありません。 フックが初期指示を渡しても、状況を判断し、選んだ指示に従うのはエージェントです。適切でないワークフローを選んだ場合は、作業範囲を伝え直すか、必要なスキルを直接指定してください。

Superpowersのスキル一覧と使われる場面

スキル集は開発サイクル全体をカバーしていますが、各セッションで読み込むべきなのは、その作業に合うスキルです。 以下のスキル名は、確認したファイルの表記をそのまま記載しています。適用場面の列は、各スキルの説明や指示を要約したものです。特定の文を入力すれば必ず特定のスキルが呼び出される、という意味ではありません。現在のスキルディレクトリ

一覧を暗記する必要はありません。通常の機能開発では、依頼内容の理解、必要に応じた具体的な計画、テスト済みの実装、変更のレビュー、統合方法の決定へと進む流れを確認してください。バグに対しては、新機能の設計について話し合うより、まず調査から入るのが適切です。

標準のプランモードや自作スキルとはどう使い分ける？

Superpowersは計画を立てる前後の手順を定めます。そのwriting-plansスキルは、Claude Code標準のプランモードとは別のものです。 現在の初期指示では、まだブレインストーミングを行っていない場合、プランモードに入る前にbrainstormingを呼び出すよう明記されています。標準モードと独自の計画作成スキルを同じものとして扱うのではなく、適用する順序を定めています。現在の計画に関する指示

writing-plansは、実装上の判断と確認事項をまとめた文書をリポジトリ内に作成します。通常の保存先はdocs/superpowers/plans/です。計画を引き渡す際には、実行方法がすでに指定されている場合を除き、ユーザーに計画のレビューと実行方法の選択を求めます。モードを選ぶだけでは、この文書やタスクの指示は用意されません。Claude Code側の操作や動作については、別記事のClaude Codeのプランモード解説を参照してください。

自作のスキルも引き続き利用できます。 プラグインのwriting-skillsファイルは、Claude Codeの個人用スキルのディレクトリを~/.claude/skills/としています。また、初期指示では、CLAUDE.mdや直接の依頼を含むユーザーの指示を、スキルの指示より明確に優先しています。したがって、プロジェクト固有のスキルにチームの規約を持たせ、Superpowersで開発手順を定めることができます。両方でテストやレビューの進め方を指定する場合は、役割分担を明確にしてください。スキル作成の指示、指示の優先順位

指示ファイルの基本的な仕組みについては、エージェントスキルの解説を参照してください。Superpowersは、この仕組みの上に特定の開発方針を組み込んだスキル集です。

Superpowersの使い方：機能のアイデアからマージまで

「完了したタスクを非表示にする」トグルがあれば、ワークフロー全体を説明できます。 以下はスキルのファイルを基に構成した使用例であり、実際のテストセッションの記録ではありません。ファイル名、受け入れ条件、結果はいずれも仮定です。

既存のタスク一覧アプリに、すでにテストがあるとします。ユーザーの依頼は、完了した項目を削除せずに非表示にするトグルの追加です。この例では、ユーザーが計画の文書化と、サブエージェントによるタスクのレビューを明示的に求めています。この指定がなければ、この程度の小さな変更は、チャット内で話をまとめる短い手順の候補になります。

動作を明確にする：brainstorming

重要なのは、「非表示」が現在の表示だけを変えるのか、保存されたタスクにも影響するのかという点です。この例で合意するのは、表示だけを変えるフィルターです。トグルは初期状態でオフにし、オフに戻せば完了した項目を再表示します。フィルター適用後に表示対象がなくなった場合は、未完了のタスクがないことを示します。

Claudeはこの範囲を説明し直し、承認を得ます。ユーザーが文書化する方法を選んだため、設計はdocs/superpowers/specs/配下の文書にまとめ、引き渡す前に実装担当者の観点から確認します。このスキルで通常の小さな変更を扱う場合は、説明と合意をチャット内にとどめられます。ブレインストーミングのルール

確認すべき成果物は、動作についての合意内容です。そこに設定の保存がいつの間にか加わっていたり、タスクの保存方法が変わっていたりすれば、実装が始まる前に機能の範囲が広がっています。

確認できる作業単位に分ける：writing-plans

計画では、機能を個別に検証できる成果物に分けます。一方のタスクでは、例としてsrc/tasks/filterTasks.tsにフィルター関数を実装し、完了・未完了が混在する一覧、空の一覧、すべて完了済みの一覧をテストします。もう一方では、合意した関数インターフェースを使い、アクセシビリティに配慮したトグルをsrc/tasks/TaskList.tsxに接続して、画面上の結果をテストします。

計画には、ファイル、インターフェース、テストで検証する内容、プロジェクトのテストコマンド、期待する結果を記載します。フィルター処理で元のタスクコレクションを変更してはならないことも明記します。ユーザーは計画をレビューし、サブエージェントを使う方法を選ぶことを確認します。ここで、曖昧だった依頼が、実装担当者とレビュアーが具体的な論点として議論できる内容になります。計画作成の指示

作業環境を整える：using-git-worktrees

実行の準備として、Claudeは作業環境がすでに分離されているかを確認します。Git worktreeは、同じリポジトリに対する別の作業ディレクトリで、通常は専用のブランチを使います。このスキルは実行環境に備わる標準のworktree機能を優先し、ユーザーがすでに示した希望に従います。それ以外の場合は、作成前にユーザーに確認します。

この例では、ユーザーが機能開発用のworktreeを作ることに同意したとします。Claudeはアプリケーションを変更する前に、その環境で既存のプロジェクトテストを実行します。変更前からテストが失敗している場合は、それを先に確認する必要があります。そうしなければ、後で起きた失敗が新しいトグルによるものか判断できません。作業環境に関する指示

タスクを実装する：subagent-driven-developmentとtest-driven-development

制御役のエージェントは、フィルター処理のタスクに新しい実装担当を割り当て、そのタスクのレビューを手配します。その確認を終えてから、UIのタスクに進みます。現在のサブエージェント用スキルでは、タスクのレビューで仕様への適合とコード品質を確認し、完成したブランチに対して、より広い範囲のレビューを行うことも求めています。進捗と判断は、計画ごとの作業記録にも残します。サブエージェントのワークフロー

実装中は、test-driven-developmentがレッド・グリーン・リファクタリングのサイクルを定めます。この例では、フィルターを適用した表示を要求しても完了済みタスクが返ってくることを、まずテストで示します。その失敗を確認してからフィルター処理を追加し、テストを再実行します。その後、テストが通る状態を保ちながらコードを整理します。TDDの指示

UI側で有効な検証は、トグルを操作した後にユーザーに何が見えるかを確かめるものです。関数が呼ばれたかどうかだけを確認しても、画面上で機能が正しく動くことは確かめられません。

別の進め方がexecuting-plansです。Claude自身が現在のセッションで計画を実装し、サブエージェントが利用できる場合は、最後に新しいレビュアーがブランチ全体を確認します。タスクごとの引き渡しを伴うレビュー体制が不要なら、こちらを選べます。現在のセッションで計画を実行するための指示

指摘に対応する：レビュースキルとsystematic-debugging

最後のブランチレビューでは、requesting-code-reviewがレビュアーへの引き渡し方法を定めます。ここで、トグルをオフにしても完了済みタスクが再表示されないと指摘されたとします。receiving-code-reviewは、変更を加える前に、その指摘をコードと想定動作に照らして確認するよう求めます。レビュー依頼の指示、フィードバックへの対応

問題を再現できたら、systematic-debuggingに沿って調査します。根本原因の調査、パターン分析、仮説の検証、実装という段階で進みます。この例なら、「元のコレクションをフィルター後のコレクションで置き換えてしまったのではないか」という仮説が考えられます。データの流れを調べ、項目が失われることを再現し、回帰テストを用意して原因を修正します。トグルの見た目だけを無理に正しい状態にして済ませてはいけません。デバッグの指示

完了の根拠を示し、マージ方法を決める

verification-before-completionは、成功を宣言する前に、改めて実行したコマンドの出力を求めます。この機能では、フィルターの動作、トグルの操作、関連するプロジェクトのチェックについて証拠を示し、未解決の失敗があれば明確に伝える必要があります。検証の指示

次に、finishing-a-development-branchがテストスイート全体を検証し、統合方法の選択肢を提示します。通常の名前付きブランチでは、現在のファイルはローカルでのマージ、プッシュとプルリクエストの作成、ブランチの保持を選択肢として挙げています。ユーザーの判断を待つため、レビューに通っただけでマージまで承認されたことにはなりません。

この例を最後まで進めるため、ユーザーが、確認済みのベースブランチへのローカルマージを選んだとします。Claudeはマージ後の状態をテストし、通ったことを確認してから、機能開発用のworktreeとブランチを削除します。一方、プルリクエストを作る場合は、そのリポジトリのマージ手順に沿った対応を待つ状態になります。ブランチでの開発を完了するための指示

小さな作業では、どこまで手順を省ける？

依頼ですでに決まっていることを何度も確認するようになると、手順そのものが負担になります。 置換後の文言まで指定された画面ラベルの変更に、タスクの状態の保存方法を変えるのと同じ準備は必要ありません。これはワークフローが増やす作業量についての判断であり、所要時間を測定した結果ではありません。

現在のbrainstormingファイルでは、作業を次の3つの規模に分けています。

• すぐにできる明確な作業： 依頼そのものに必要な説明がそろっているため、そのまま実行します。
• 小さな変更： チャットで変更内容に合意してから、通常のワークフローで実装します。
• プロジェクト： 文書化した設計の承認を得てから、ソフトウェアの詳細な実装計画を作ります。

同じファイルでは、ユーザーが質問を不要だと明示し、ブレインストーミングの確認段階を終えられることも定めています。ただし、それによって以降のテストや検証の指示まで自動的に無効になるわけではありません。作業規模の判断と質問の省略に関するルール

たとえば、「これは小さな変更です。説明はチャット内にとどめ、既存のテスト環境を使い、機能の範囲を広げないでください」と伝えるとよいでしょう。すでに内容が決まっている文言修正なら、正確な文字列と変更範囲を指定します。これは隠れた回避コマンドではなく、プラグインの指示の優先順位で認められている作業上の制約です。

ここでの限界は、手順に伴う負担です。会話、計画書、エージェントへの割り当て、レビューが増えると、残っている不確かな点に比べて負担が大きくなりすぎることがあります。ソースにはそうした手順が記載されていますが、個々の変更に何分かかるかまでは分かりません。セッションが作業範囲を繰り返し無視するなら、リポジトリに含まれるdiagnosing-superpowersで、会話ログを証拠に何が起きたかを調べられます。セッションを診断するスキル

Superpowersに期待しすぎてはいけない点は？

手順が定められていることは、ソフトウェアの正しさや開発速度の向上を証明しません。 失敗するテストが間違った要件を表していることもあれば、計画が統合時の制約を見落としたり、エージェントのレビュアーが不具合を見逃したりすることもあります。完了メッセージの自信に満ちた口調ではなく、テストの検証内容と差分を評価してください。

また、サブエージェントを使うからといって、すべての実装タスクが同時に動くわけではありません。現在のスキルでは、競合を避けるため、このワークフロー内で実装担当のサブエージェントを並列に動かすことを明示的に禁じています。dispatching-parallel-agentsは、独立した問題を扱うための別のスキルです。実装担当への割り当てに関するルール

インストールしても、作業範囲や統合に対する利用者の責任がなくなるわけではありません。プラグイン自身の完了手順でも、マージの判断はユーザーに委ねています。最も確実に提供するのは手順です。何を確認し、どの証拠を示すべきかをClaudeに伝えます。それが役立つかどうかは、作業の内容と、エージェントが指示を守るかどうかによります。

どんな人に向いている？まず何を試す？

開発に必要な判断が繰り返し省かれてしまうなら、導入を検討する価値があります。 個人開発でエージェントが要件の確認を飛ばしがちな場合は、失敗条件を明確にできる、範囲の限られた機能から試してください。実装前に動作を定め、実装後に根拠を示しているかを確認します。

開発体制が確立しているチームでは、まず既存の計画、テスト、レビューの規約と、プラグインの指示をすり合わせてください。既存のスキルですでに望む手順を定めているなら、汎用的なワークフローを追加すると重複する可能性があります。作業の大半が、内容の決まったごく小さな編集である場合も、それだけのために手法全体を導入する必要性は高くありません。

月曜日に、範囲を限定した変更を選び、受け入れ条件を書き出してみてください。Superpowersを使い、選ばれたスキルと最終的な差分を確認し、追加された成果物がそれぞれ判断に役立ったかを評価します。長い計画書ができたからではなく、確認手順が役に立ったからこそ、使い続けるかを決めましょう。

別の課題を解決する関連ツールについては、おすすめのClaude Codeプラグインを参照してください。

Claude Superpowersについてよくある質問

AIを使った開発の実践的な情報は、ニュースレターに登録してお読みください。