Superpowersは、自分で管理するGitリポジトリの大きな変更について、設計の合意、タスク計画の承認、テストを伴う実装、各タスクのレビュー、完成ブランチの確認をClaude Code利用者に案内できます。本ガイドは2026年10月20日に確認したSuperpowers 7.0.0の公式マニュアルに基づきます。BIG CHANGEは文書を調べましたが、プラグインのインストールや実際のプロジェクト実行はしていません。

大きな変化

  • 変わったこと：承認された設計と実装計画により、コーディングエージェントはリポジトリを編集する前に具体的なタスクと制約を得ます。
  • 重要な理由：文書化されたタスクフローは、実際に確認したテストの失敗と成功を、1人のレビュアーによる仕様適合性と品質の個別判定と組み合わせ、その後にブランチ全体を広くレビューします。
  • 注意点：責任者は引き続き完全なdiffと最新の受け入れ結果を確認し、ブランチの処理を決めます。エージェントのフローが完了しても、開示済みの指摘が残る場合があります。

始める前に

自分が所有するか編集を許可されたリポジトリで、承認済みの複数段階の変更を1件選びます。レビュー可能なタスクに分割でき、振る舞いをテストできるものにします。求める動作、対象範囲、除外事項、元の受け入れコマンド、開始commitを記録してください。作業前にそのコマンドと関連する既存チェックを実行します。初期状態ですでに失敗する場合は今その原因を特定します。後の赤や緑の結果には既知の開始点が必要です。

Git、認証済みのClaude Code、プラグインのインストールとブランチまたはworktree作成の権限、Claude Codeとサブエージェントを動かす十分なプランまたはAPI容量が必要です。ソースコードへのアクセスとプラグイン利用に関する組織の規則を確認してください。有効化前にプラグイン内容、実際の権限、提供者のデータ条件、支出制御を調べます。Anthropicは、プラグインのhookやサーバープロセスがツール呼び出しのサンドボックス外でユーザー権限により実行される可能性を警告しています。通常のツール許可プロンプトは、そのコードすべてを対象にしません。秘密情報、依存関係、外部書き込み、push、リリースは実際の権限内に留めます。Claude Codeのプラグイン安全性文書がこの境界を説明しています。

以下の手順は、複数タスクの変更にSuperpowersの subagent-driven-development スキルを使います。マニュアルは直接実行する executing-plans 経路も説明し、小規模な作業では簡略な設計合意を認めています。すべてのプロジェクトに完全な順序が必須と決めつけず、実装前に責任者と経路を選んでください。

1. プラグインを導入して有効なバージョンを確認する

対話型のClaude Codeセッションで、公式マーケットプレイスのコマンドを入力します。

Text
/plugin install superpowers@claude-plugins-official

Claude Codeはインストール前にプラグインの詳細パネルを開きます。内容を調べ、許可された適用範囲を選びます。ローカル範囲はこのリポジトリで自分に対して有効化し、プロジェクト範囲は共同作業者のリポジトリ設定に影響します。インストール概要とErrorsタブを読みます。セッションの有効化指示に従うか再起動し、Installedタブを確認してシェルで claude plugin list を実行します。表示されるVersion、Scope、Statusを記録し、有効なセッションでSuperpowersのスキルを利用できることを確認してください。マーケットプレイスのコマンドは本ガイドの調査commitを固定しません。導入版やスキル本文が7.0.0と異なる場合、実際の版と手順を照合してから続けます。失敗または無効なインストールでは停止し、フローが読み込まれた証拠と扱いません。Claude Codeのインストールガイドがこれらの確認を説明しています。

2. 設計を承認し、その後で計画を承認する

実際の変更、受け入れ基準、初期結果、禁止する編集をClaude Codeに伝えます。Superpowersの brainstorming プロセスで意図、設計上の選択、制約を確定します。この複数段階の変更では、書面の設計とビルダーチェックの指摘を読み、責任者が決めるべき問題を解決して全体説明を承認します。承認は作る動作を示すものです。エージェントが話し続けることから承認を推測してはいけません。設計マニュアルは小さな作業に簡略な合意や明示的な除外を認めるため、ここでは大きめのタスクに完全な経路を意図して選びます。

次に writing-plans プロセスへ、設計をタスクに分割するよう依頼します。計画のファイル境界、インターフェース、全体制約、テストコマンド、Review Focusを確認します。各タスクは調査できる小ささとし、テストは合意した動作を測るものにします。コード変更前に計画とサブエージェント実行方法を承認してください。計画マニュアルが引き継ぎを定義します。もっともらしい計画を、依存関係追加や無関係なファイル変更の許可と扱わないでください。

実行時には using-git-worktrees が適切な既存作業領域を確認するか、必要な同意を得て隔離領域を用意します。実際のブランチ、基準commit、クリーンな初期状態を記録してください。利用可能ならClaude Codeのネイティブworktree機能を使います。作業領域に無関係な編集があれば、続ける前に所有関係を解決します。worktreeマニュアルが確認と作成の流れを説明します。

3. 各テストとタスクレビューを観察する

承認済みの計画で subagent-driven-development を使い、独立してレビューできるタスクを実行します。現行マニュアルはタスクに実装担当を割り当て、実装とdiffを1人のタスクレビュアーへ渡します。その人は仕様に一致するか、実装品質を受け入れられるかという2つの判断を返します。これは1回のレビューの2判定で、2体のレビュアーエージェントが順番に動くわけではありません。同種の小タスクはマニュアルの規則に従いまとめられます。タスクフローとレビュアー用プロンプトがこの順序を定めます。

テスト先行に適した動作ごとに、観察可能なレッド・グリーン循環を求めます。動作テストを追加し、実行して期待した失敗を確認します。最小の実装を行い、再実行して成功を確認します。その後、チェックを通したままリファクタリングします。インポートエラーや壊れたテスト基盤は期待した赤ではありません。各タスクのコマンド、出力、関連commitまたはdiffを保管してください。テスト駆動開発マニュアルには人間の合意が必要な例外があります。本ガイドは通常のテスト先行経路に適したタスクを想定しています。

両方のレビュー判定と実際のdiffを読みます。「diffから検証不能」の項目は、タスク受け入れ前に計画とリポジトリで解決してください。修正と限定範囲の再レビューを確認します。新たな成功の主張は新しいテスト結果ではありません。7.0.0のフローは修正ループに上限を設け、書面の裁定とともに指摘を保留できます。その指摘は後のレビュー用に残します。タスクの完了表示が必ずしも問題なしのレビューを意味するわけではありません。

タスク終了後は、独立したブランチ全体のレビューを確認します。タスク間の相互作用を見つけ、1つのdiffから判断できなかった保留事項を再検討できます。未解決事項ごとに根拠と裁定を求めてください。プラグインの一時作業領域を片付ける前に、設計、計画、テスト出力、レビュー報告、完全なdiffを保管します。期待するスキルが起動しなければ、有効なプラグインの状態、版、文書化された診断経路を確認します。導入しただけでフローが強制されたと考えてはいけません。

4. ブランチを確認して処理を決める

最終コードで元の受け入れコマンドとプロジェクトの全テストを再実行します。新しい出力、ブランチ全体のdiff、すべての未解決指摘を確認します。Superpowersの検証マニュアルは、完了主張の前に現在の状態から得た証拠を要求します。テスト群が失敗したら具体的な原因を特定して修正するか、レビュー用にブランチを残します。テスト群が失敗している場合、文書のブランチ終了メニューには進みません。

名前付きブランチでは finishing-a-development-branch がローカルマージ、pushとpull request作成、またはブランチをそのまま保持する選択肢を提示します。分離したHEADではpull requestと保持を選べます。破棄は責任者の明示的な要求と文字入力による確認の後に別途処理し、通常の4番目の選択肢ではありません。ブランチ終了マニュアルがこれらを説明します。責任者の決定前にチェック、diff、残る指摘を示してください。マージ、push、削除、リリースには各操作にふさわしい権限が必要です。

有用な成果は、元の要件に結びついたレビュー可能なブランチです。承認済み設計と計画、観察したテスト結果、タスクレビューの両判定、ブランチ全体のレビュー、完全なdiff、最新の受け入れ結果が揃います。導入、アクセス、予算、チェックで停止したら検証済み成果物を保管し、最後に完了した段階を示します。文書はプロセスを説明するもので、本ガイドの未実行変更が速い、安い、欠陥が少ないとは証明しません。

出典と参考資料

1つの受け入れチェックの修正なら、BIG CHANGEの失敗するリポジトリチェックの検証ガイドを参照してください。ここでのプロセスは、複数タスクの変更について設計と計画を立てる、より早い段階から始まります。