review-panel

レビューパネル

パイプラインを実行します：スコープ → ブリーフ → パネル → マージ → トリアージ → 指摘事項レポート → 承認ゲート → 修正 → 検証 → 最終レポート。

実行開始時に承認モードを設定します。デフォルトはゲート付きです。/review-panel auto-fix は自動修正を設定し、修正の処置にトリアージされた指摘事項に対する継続的な承認を付与します。自動修正がエスカレーションの分岐を選ぶことはありません。エスカレーションには、必ず後からユーザーの判断が必要です。

1. スコープ

code-review に同梱されているリゾルバーを使って、パネル全体のレビュー対象スコープを1つ解決します。リポジトリ内から絶対パスで実行し、<code-review-dir> にはそのスキルのインストール先ディレクトリを指定します：python3 <code-review-dir>/scripts/resolve-scope.py [--scope <spec>]。ユーザーが指定したスコープは、隣接する変更を含めず、そのまま正確に使用します。--scope にはコミット、範囲、staged、または worktree（ステージされていない変更と未追跡ファイル）を渡します。ブランチは、ブランチ名だけではその先端コミットのみが対象になるため、<base>...<branch> として渡します。プルリクエストは、両方の参照をフェッチした後に <base>...<head> として渡します。指定された diff ファイルまたは名前付きファイルは、指定どおりのスコープです。--scope を指定しない場合、リゾルバーはステージされた変更、ステージされていない変更と未追跡ファイル、上流ブランチより先にあるコミット、デフォルトブランチとのマージベースを基準とした現在のブランチのうち、最初に見つかった空でないものを採用します。終了コード 1 はレビュー対象がないことを意味します。その場合は停止して、その旨を伝えます。終了コード 2 は、不正な参照、複数のマージベース、読み取れないファイル、または書き込み不可の出力ディレクトリを意味します。原因を修正するか、スコープを手動で解決します。すべての担当者に、出力された scope と diff のパスを伝え、出力された excluded ファイルをブリーフに記載して、編集中のコードを担当者が指摘しないようにします。

2. ブリーフ

会話、チケット、またはコミットメッセージから受け入れ基準を集めます。レビューブリーフをスクラッチパッドに書きます。意図、満たされる要件、意図的なトレードオフ、既知の制限、宣言された非目標を含めます。トレードオフと非目標は、その根拠を示した主張として記述します。1ページ以内に収めます。スコープから除外した内容はブリーフに記載しますが、判定は記載しません。担当者に、何を指摘しないかを伝えたり、重要度に上限を設けたりしてはいけません。判断はトリアージで行います。見知らぬ人がブリーフを根拠にスコープ外の指摘を却下できる状態になれば、ブリーフの完成です。

3. パネル

ユーザーが指定したプリセット（/review-panel max）、ユーザーが指定した正確な構成、またはデフォルトの standard から、レビュー担当の担当者を編成します。ユーザーが明示した構成は、すべてのプリセットより優先されます。新鮮な視点はモデルではなくコンテキストから得られます。親と同じモデルを使う新しいコンテキストも、新しいレビュー担当者です。

能力順に並べたメンバー一覧：

順位	メンバー	ハーネス	同系モデル
1	fable 5	claude	opus 5
2	codex 5.6 sol	codex	terra
3	opus 5	claude	fable 5
4	grok 4.6	cursor	kimi k3

順位 3～4 は予備です。同系モデルとして、フォールバックの競合モデルとして、または ultra の2人目の競合モデルとして参加します。

このセッションのハーネスとモデルを意味する親を基準に、3つの役割を決めます。

• 競合モデル：親とは異なるハーネス上のメンバーを順位順に選びます。standard と max では最初の競合モデルを使い、ultra では最初の2人を使います。別のハーネスがインストールされていない場合は、同系モデルが競合モデルの代わりを務めます。ハーネスにモデルが1つしかない場合は、ツインが代わりを務めます。
• 同系モデル：親自身のモデル以外で、親のハーネス上にある最も強力なモデルを選びます。各メンバーは一覧に記載されています。ハーネスにモデルが1つしかない場合は、ツインが代わりを務めます。
• ツイン：新しいコンテキストで実行する、親自身のモデルです。

親は常に、解決済みスコープに対して code-review をインラインで実行する（親担当者）ほか、プリセットで指定された新しい担当者も起動します。

プリセット	新たに起動する音声
standard（デフォルト）	code-review: rival · adversarial: rival
max	code-review: rival, sibling · adversarial: rival, sibling, twin
ultra	code-review: 両方の rival, sibling · adversarial: 両方の rival, sibling, twin

ステップ 7 の検証は、常に最初の rival が担当します。フル環境で親が fable の場合、rival は sol、次に grok で、sibling は opus です。standard では両方の役割で sol がレビューし、max では両方の役割に opus を追加し、さらに adversarial fable を加えます。ultra では両方の役割に grok を追加します。

ルール：

• すべてのパネルには、フレッシュなコンテキストで実行する adversarial-review の音声が少なくとも 1 つ含まれます。adversarial-review は親コンテキストでは実行されません。同じメンバーが 2 回指定されている場合、別々のフレッシュなコンテキストとして実行されます。
• 推論の労力。 standard では、新たに起動する音声は高い推論労力で実行されます。max と ultra では、デフォルトで xhigh になります。ただし fable と kimi k3 は高い推論労力のままです。Terra は常に max で実行されます。親の音声には、セッション自体の推論労力が適用されます。ユーザーは各音声の推論労力を変更できます。
• メンバーが見つからない場合。 プリセットまたはユーザー指定のメンバーが利用できない場合は停止し、利用可能なメンバーで構成したパネルを提案します。続行するのは、ユーザーが選択した後だけです。指定された rival のフォールバックチェーンには確認は不要です。
• モデルが親自身のハーネス上で動作する音声は、そのハーネスに組み込みのサブエージェントツールがあれば、それを通じて実行します。それ以外の音声はすべて spawn-agent で実行します。いずれの場合も、レビュー用スキルの SKILL.md のパスを、その音声の行動規範としてプロンプトに含めます。レビューは自身で行い、エージェントの起動や review-panel の呼び出しは行わないよう伝えます。
• ユーザーは、登録されているメンバー以外も指定できます。環境で実行可能なハーネスまたはモデルであれば指定できます。spawn-agent が参照できないハーネスの場合は、そのハーネス固有の規約に従ってヘッドレス CLI セッションを実行します（そのハーネスの --help を信頼できる情報源とします）。実行できない場合は、見つからないメンバーとして扱います。
• 起動前に、解決したスコープ、ブリーフから読み取った意図、パネル構成をユーザーに報告します。報告後は続行し、承認を待ちません。
• すべての音声に、同じスコープとブリーフを一字一句変えずに渡します。新たに起動する音声は並列で実行し、その間に親によるレビューも行います。各レポートは編集せずにすべて収集し、指摘を弱めたり、事前に評価したりしません。同じスコープを再レビューする場合は、前回の最終レポートを以前の指摘としてすべての音声に渡します。

4. マージ

レポートを 1 つの指摘リストにまとめます。同じ根本原因と修正方法を持つ指摘は、該当箇所をすべて列挙して 1 つにまとめます。独立して対処できる不具合は別々に保ちます。最も高い重大度、最も具体的な失敗シナリオ、および一致度タグ（3 つの音声のうち 2 つが指摘）を維持します。指摘の出所は重視しません。親の音声による指摘も他の指摘と同等に数えます。一致度は信頼性を示し、トリアージの確信度に反映されます。根本原因と修正方法が重複する指摘がなくなった時点で、マージは完了です。

5. トリアージ

このセッション内で、マージ済みの指摘に対して review-triage を実行します。ここでトリアージを行うことで、会話、レビュー概要、レビュー中に確認できた作成者のコンテキストを保持できます。

すべての判定、修正案、エスカレーションの分岐を含む、トリアージレポート全体を提示します。

ゲートモードでは、レポートに続けて、ユーザーの判断が必要な指摘、つまりすべての fix と escalate の指摘について、判断ラウンドを行います。deferred と rejected の判定はレポートに記載されたとおりとし、ユーザーは同じラウンドでそれらを覆すことができます。ハーネスの複数選択式質問ツールを使って、指摘ごとに質問を1つ作成し、ツールの上限までまとめて提示します。そのようなツールがない場合は、文章で質問します。各質問には指摘の内容を独立して記載し、ユーザーがレポートまでスクロールしなくても判断できるようにします。

• 問題点を1～2行で説明
• 提案する修正
• 修正にかかる推定コスト：変更するファイルと関数、おおよその変更行数、修正自体がもたらすリスク

fix の指摘では、修正を承認（推奨として表示）、保留、却下を選択できます。escalate の指摘では、トリアージの推奨を示したうえで、A/B/C の選択肢を提示します。却下する場合はユーザーの理由が必要です。自由記述の選択肢から理由を受け取るか、質問してください。その理由は指摘とともに最終レポートに記載します。

自動修正モードでは、レポートを提示した後、fix の判定をすべて進めます。レポートに escalate の判定が含まれている場合は、修正作業に着手せず、同じ判断ラウンドの形式で選択肢をユーザーに提示します。auto-fix を指定せずに /review-panel を実行した場合に許可されるのは、レビュー、トリアージ、判断ラウンドです。修正を許可するのは、ラウンドへの回答があった場合のみです。

恒久的な判断は、それぞれの種類に適した成果物に記録します。 ローカルで自明でない理由による却下の場合、指摘箇所にコードの根拠を説明するコメントを追加します（指摘につながった誤解自体が欠陥であり、コメントがその修正となります）。保留の場合は、トリアージで計画したコメントまたはチケットに従います。証拠待ちの保留はレポートのみに記載します。決定済みのエスカレーションについては、リポジトリで ADR ログを管理している場合、ADR を作成します。スコープに関する却下は最終レポートのみに記載します。各コメントはレビュー履歴ではなく、コード自体の語り口で記述します（例：「パース境界で検証済み」）。記録のために提案する編集内容を報告し、そのまま進めます。それらの編集がユーザーの許可範囲に含まれる場合にのみ適用します。無関係な修正の承認は、記録用編集の許可にはなりません。許可がない場合は、レポート内の提案として残します。これらについてステップ7で判断を求める必要はありません。

fix または escalate の判定が一つもない場合、トリアージレポートと、ユーザーが承認した記録用編集をもってパイプラインは完了です。

6. 修正

ゲートモードでは、判断ラウンドへの回答によって承認済みの項目が決まります。自動修正モードでは、fix の判定はすべてすでに承認済みです。トリアージで指定された範囲を守り、承認済みの修正をまとめて適用します。承認された指摘とエスカレーションの選択肢の範囲を超えてはなりません。承認されていない指摘は保留のままにします。

修正担当を並行して作業させる場合は、ファイルの重複状況に応じて分離方法を決めます。作業開始前に、ファイルの所有範囲が重複しないリストにバッチを分割します。作業ツリーを共有できるのは、競合のない分割の場合のみです。各担当者は、自分の担当ファイルだけを編集します。ファイルが重複する場合、または担当者が破壊的な git 操作（ファイルを元に戻す変更チェックなど）を必要とする場合は、順次実行するか、担当者ごとにワークツリーを用意します。作業ツリーを共有する場合、作業途中の全テスト結果は無視します。隣接する担当者が編集中のファイルによって、本来失敗していないテストが失敗することがあるためです。判定に用いるのは、すべての担当者の作業が揃った後に、完成したツリーで一度実行する全テストのみです。

7. 修正を検証する

検証はクローズドな確認であり、再レビューではありません。新しい最初のライバルコンテキストを1つだけ使い、パネル全体には依頼しないでください。また、親には依頼しないでください。この段階では親が修正バッチを作成しており、作成者自身による resolved 判定は必ず通る唯一の確認だからです。

検証担当者が証拠を読み、改めて導き出す必要がないよう、親側で証拠をまとめます。

• 承認済みの指摘事項。それぞれについて、修正したとする差分ハンクを対応付けます
• 修正差分
• 組み立てたツリー全体での全テストスイートの結果。親が引き渡し前に実行します

各指摘事項について、具体的な証拠を添えて resolved または unresolved を必ず提示させ、修正によって生じたブロッキング問題も提示させます。未解決の指摘事項と、修正によって生じたブロッキング指摘事項は review-triage に送り、その報告を提示したうえで、ステップ5の承認ゲートに戻ります。ゲートモードでは、もう一度判断ラウンドを実施します。自動修正モードでは、さらに1回の修正バッチを自動で実行できます。**修正後の検証は最大2回までです。**上限に達した時点で未解決の指摘事項は、修正せずに報告します。

8. 報告する

次の内容を報告します。

• 最終判定と適用した修正
• パネルの構成と、代替があればその内容
• 未承認のまま残った指摘事項
• 保留および却下された指摘事項と、それぞれの証拠
• エスカレーションと、その判断方法
• サイクル上限に達した時点で未解決のまま残った事項

承認済みのすべての指摘事項が解決済みと検証されるか、未解決として明示的に報告された時点で、パイプラインは完了です。修正バッチで重大または最重要の指摘事項が複数解決された場合、あるいは対象範囲の大部分を作り直した場合に限り、新しい状態で /review-panel を再実行することを推奨します。再実行するかどうかは、ユーザーが再度呼び出すという外側のループで決まります。