interrogate

Interrogate

設定されたモデルごとにレビュー担当者を 1 人ずつ起動し、コード変更を敵対的にレビューします。すべてのモデルに同じプロンプトと評価基準を与えます。敵対的な視点は、割り当てられたペルソナではなく、モデルの多様性から生まれます。

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

Step 1, レビュー範囲の決定

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

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

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

Step 2, 意図の提示

レビュー担当者を起動する前に、意図を明確に提示します。次の情報から意図を導きます。

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

明確な段落を 1 つ書きます。意図が不確かな場合は、先にユーザーへ確認します。

Step 3, レビュー担当者の起動

Task ツールを使って、すべてのレビュー担当者を 1 つのメッセージで起動します。~/.cursor/rules/pstack-models.mdc の interrogate reviewers 行を使用し、以下の Reviewer A/B/C ラベルを、設定されたエントリー数に合わせて増減します。ルールまたはその行が見つからない場合は、表のデフォルトを使用します。

サブエージェント	デフォルトモデル
Reviewer A	claude-opus-5-5-max
Reviewer B	gpt-5.6-sol-max
Reviewer C	grok-4.7-xhigh-fast

各レビュー担当者について、次のように設定します。

• subagent_type: generalPurpose
• model: 設定された interrogate reviewers のエントリー。設定行がない場合は表のデフォルト。エントリーが auto または inherit-parent の場合は、model を省略し、親モデルで実行します。
• readonly: true

Task ツールが設定済みのエントリーを受け付けない場合、そのレビュー担当者には同じファミリーの表のデフォルトを使用し、その旨を伝えます。ファミリーはプレフィックスで判定します。claude-*、gpt-*、grok-* のいずれにも該当しない場合は、Reviewer A のデフォルトを使用します。表のデフォルトが拒否された場合は、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 に記載された意図の段落]

レビュアー

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

対応する

[対処すべき指摘。各項目に、説明、指摘したモデル、重要な理由を記載してください。]

検討する

[検討する価値のある指摘。各項目に、トレードオフを記載してください。]

記録する

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

却下する

[却下した指摘と、その理由を簡潔に記載します。]

合意マップ

[モデル間で合意した点と意見が分かれた点は何ですか。また、合意や意見の相違の傾向から何が分かりますか。]