code-review-panel

コードレビュー・パネル

並行処理、キャンセル、再生、セキュリティ、または公開インターフェースに関わるリスクの高い変更には、2 人のレビュアーを使います。小規模な変更はリード担当者がレビューします。独立したレビューが必要な定型的な変更には、別のファミリーからレビュアーを 1 人選びます。選択したモデルごとにレビュアーを 1 人起動し、コード変更を敵対的にレビューさせます。すべてのモデルに同じプロンプトと評価基準を渡します。敵対的なシグナルを生み出すのはモデルの多様性であり、割り当てられたペルソナではありません。

成果物は統合された判定です。変更を自動適用してはいけません。

ステップ 1、対象範囲の決定

コンテキストからレビュー対象を特定します。

• ユーザーが特定のファイルまたは差分を指定している場合は、それを使用します
• フィーチャーブランチ上にいる場合は、変更一式全体について git diff main...HEAD（または適切なベースブランチ）を実行します
• ユーザーのメッセージが最近の作業に言及している場合は、関連ファイルを収集します

差分（またはファイルの内容）と、レビュアーがコードを理解するために必要な周辺コンテキストファイルをまとめます。

ステップ 2、意図の明示

レビュアーを起動する前に、意図を明示します。次の情報から導き出してください。

• ユーザーのメッセージ
• コミットメッセージ
• 存在する場合は PR の説明
• コード自体

明確な段落を 1 つ書きます。意図が不明な場合は、作業を進める前にユーザーに確認します。

ステップ 3、レビュアーの起動

t3-orchestrator スキルの route.mjs select --task review を使ってレビュアーモデルを選びます。2 人目は --exclude-model <first reviewer's model=> を指定して選び、同一モデルを 2 つのハーネスで使うのではなく、異なる 2 つのモデルをパネルに含めます。同じ記入済みテンプレートをすべてのレビュアーに渡すため、各モデルが同じコード品質の観点を適用します。

レビュアーは、デフォルトでコードと既存の生のエビデンスを読みます。負荷の高いチェックの依頼は、最終検証を担当する 1 人に回します。レビュアーが重複してビルドを開始することはありません。各レビュアーは読み取り専用のサブエージェントとして起動します。コマンドを実行しない作業では、t3-code MCP の delegate_task またはハーネス独自の読み取り専用サブエージェント機能を使います。

モデルが利用できない場合、または実行に失敗した場合は、t3-orchestrator の再ルーティングルールに従います。ここで独自のフォールバック手順を作ってはいけません。

references/reviewer-prompt.md を読み、テンプレートに次の内容を記入します。

1. 明示した意図
2. 差分またはファイルの内容
3. references/rubric.md のレビュー評価基準
4. references/code-quality-review.md のコード品質の観点
5. 生のエビデンスのパスとソースの状態、最終検証の担当者、過去の指摘・回答・未解決の異議と変更範囲（または初回ラウンドであること）

要件を満たすパネルは、そのラウンドの最終ローカルレビューです。同じ差分について別のレビュアーを追加してはいけません。フォローアップのラウンドでは、修正された指摘、変更範囲、関連するリグレッションをレビューし、新たなリスクに限って範囲を広げます。元の意図、過去の指摘、回答、未解決の異議をすべて引き継ぎます。T3 では、各ラウンドで新しい delegate_task を作成し、ラウンドごとに異なる clientRequestId を使います（再試行時は同じ ID を維持します）。その taskId を保持し、非同期完了イベントを使用します。

ステップ 4、統合

結果が届いたら、次の手順で全体像をまとめます。

1. すべての指摘を解析する
2. 合意点を特定する。2 つ以上のモデルが独立して挙げた指摘は、最も有力なシグナルです。
3. 単独モデルの指摘を特定する。引き続き確認する価値はありますが、重要度は相応に判断します。
4. 重複を整理する。異なるモデルが同じ問題を別の形で説明していることがあります。これらを統合し、どのモデルが指摘したかを記録します。
5. 意見の相違を記録する。あるモデルが問題を指摘し、別のモデルが明確に反対の見解を示している場合、その情報は判定の参考になります。

Step 5, リードによる判断

あなたは中立的な意見の集約者ではなく、現実的な判断を下すシニアエンジニアとして、レビューを主導します。

フレームワークの全容については、references/lead-judgment.md を読んでください。

すべての指摘を、以下のカテゴリに分類してください。

• 対応する。実際の目標に照らして、正確性、セキュリティ、保守性に影響する現実的な問題です。実際の PR であれば、これらの問題によりマージが止まります。
• 検討する。妥当な指摘ですが、今すぐ対応するコストに見合うかどうか判断できません。ユーザーに注意を促す価値があります。
• 記録する。技術的には正しいものの、今すぐ対応する必要はありません。状況に依存するもの、時期尚早な最適化、または現段階では影響が小さいものです。
• 却下する。誤り、細かすぎる指摘、または背景情報が不足している指摘です。却下する理由を簡潔に説明してください。

各指摘には、以下を含めてください。

• 指摘したモデル
• カテゴリ（対応する／検討する／記録する／却下する）
• その分類にした理由を1行で記述

pr-review-loop との作業分担

このスキルはプッシュ前、変更がまだローカルにある段階で実行します。PR が作成された後は、ユーザーが依頼した場合、または変更によってリスクが大幅に増加した場合に限り、ローカルパネルを再度実行します。PR にクラウドボット（Codex、Code Bot など）が残したレビューコメントには、pr-review-loop の収束ルールに従って対応します。

出力形式

次の構成で判定を提示してください。

意図

[Step 2 に記載された意図の段落]

レビュアー

• Reviewer [ラベル]：[モデル名]、[指摘件数]件（レビュアーごとに1項目）

対応する

[対応すべき指摘。各指摘について、内容、指摘したモデル、重要な理由を記載してください。]

検討する

[検討する価値のある指摘。各指摘について、内容、指摘したモデル、トレードオフを記載してください。]

記録する

[妥当ではあるものの、優先度が低い指摘。簡潔な一覧を記載してください。]

却下する

[却下した指摘と、その簡潔な理由。]

合意マップ

[モデル間で意見が一致した点と異なった点を示し、合意や不一致の傾向から何が分かるかを説明してください。]