interrogate

Interrogate

設定されている各モデルにつきレビュー担当者を1人起動し、コード変更を敵対的にレビューします。各モデルには同じプロンプトと評価基準を渡します。敵対的なシグナルは、割り当てたペルソナではなく、モデルの多様性から生まれます。モデルごとに見落としやすい点、事前知識、推論パターンが異なります。複数モデル間の一致は信頼度の高いシグナルです。単独モデルの指摘も確認する価値はありますが、信頼度は低くなります。

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

Step 1, レビュー対象を特定する

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

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

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

Step 2, 意図を明示する

レビュー担当者を起動する前に、意図を明確に述べます。このコードは何を実現しようとしているのでしょうか。次の情報から判断します。

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

明確な段落を1つ書きます。レビュー担当者が検証するのは、作業がその意図を適切に達成しているかどうかであり、意図自体が正しいかどうかではありません。意図が不明な場合は、先にユーザーに確認します。

Step 3, レビュー担当者を起動する

設定された interrogate リスト内の各モデルにつき1人のレビュー担当者を、すべて1つのメッセージで起動します（デフォルトは claude-opus-4-8-thinking-xhigh、gpt-5.5-high-fast、composer-2.5-fast）。

各レビュー担当者には、次の設定を指定します。

• subagent_type: generalPurpose
• model: 設定された interrogate リスト内のモデルを1つ指定
• readonly: true

サブエージェントの起動時に、設定されたモデルのスラッグが解決不能として拒否された場合は、Task ツールのエラーメッセージに記載された有効なスラッグを確認し、最も近いものを選んでください（同じモデル系列内で推論能力が最も高いものを優先します）。その有効なスラッグで起動し、設定済みのデフォルトを更新するための別個の PR を作成します。スラッグの問題でレビューを中断してはなりません。

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

1. 明示した意図
2. 差分またはファイルの内容
3. references/rubric.md のレビュー評価基準
4. references/code-quality-review.md のコード品質の観点

記入済みの同じテンプレートをすべてのレビュー担当者に渡し、各モデルにコード品質の観点を適用させます。

各レビュー担当者は、プロンプトテンプレートに記載された形式で、構造化された指摘を提示します。

Step 4, 統合する

結果が返ってきたら、全体像をまとめます。

1. すべての指摘を整理する。レビュー担当者からの指摘をすべて把握します
2. 合意点を特定する。独立した2つ以上のモデルが挙げた指摘は、最も信頼度が高いものです
3. 単独モデルの指摘を特定する。確認する価値はありますが、相応に重みを下げます
4. 重複を除く。複数のモデルが同じ問題を異なる表現で説明している場合があります。統合し、どのモデルが挙げたかを記録します
5. 意見の相違を記録する。あるモデルが問題を指摘し、別のモデルが明確に反対している場合は、判定に役立つ情報です

ステップ 5：リードによる判断

あなたはリードレビュアーであり、中立的な情報の集約者ではなく、実務的なシニアエンジニアです。

フレームワーク全体については references/lead-judgment.md を読んでください。レビュアーが確認できるのはコードベースの一部だけです。あなたは、目的、制約、スケジュール、すでに検討されたトレードオフなど、すべての背景を把握しています。その背景を積極的に活用してください。

すべての指摘を次の分類に分けてください。

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

指摘ごとに、次の内容を含めてください。

• 指摘を挙げたモデル
• 分類（対応する／検討する／記録する／却下する）
• その分類とした理由を一文で

出力形式

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

意図

[ステップ 2 で示された意図の段落]

レビュアー

各レビュアーを個別の行に、次のように記載します。- <モデル名>: [N 件の指摘]

対応する

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

検討する

[検討する価値のある指摘。各指摘について、内容とトレードオフを記載します。]

記録する

[妥当だが優先度の低い指摘を簡潔に列挙します。]

却下する

[却下した指摘と簡潔な理由を記載します。ユーザーが判断に異議を唱えられるよう、何を除外し、その理由を示してください。]

合意マップ

[モデル間で意見が一致した点と異なった点、その一致や相違の傾向からわかることを説明してください。]