RIJUDEVx/interrogate

Interrogate（インターゲート）

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

所見は、実行によって証明された場合のみ有効となります。

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

ステップ1：スコープの決定

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

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

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

ステップ2：意図の表明

レビュアーを起動する前に、意図を明示的に述べます。これを以下の情報から導き出します：

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

明確な段落を1つ書きます。意図が不明な場合は、先に進む前にユーザーに確認してください。

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

すべてのレビュアーを1つのメッセージで起動します。スロットごとに1人ずつ、ハーネスのサブエージェントツールまたは delegate_task を使用します。

モデルの多様性を目指します。異なるモデルファミリーは異なるバグを発見します。T3 Codeでは、ユーザーのお気に入りから異なるファミリーの強力なモデルを3～4つ選択し、それぞれを delegate_task で起動します（t3-tools スキルに手順があります）。その他の環境では、ハーネスが公開している3～4つの異なる高能力モデルを選択します。サブエージェントごとにモデルを選択できない場合は、モデルオーバーライドなしでレビュアーを起動し、独立したコンテキストから多様性を得ます。

サブエージェント	役割
レビュアーA	推論重視のレビュアー
レビュアーB	2番目の独立したモデルファミリー
レビュアーC	3番目の高速/異なるファミリー
レビュアーD	敵対的/厳格なコード品質レビュアー

各レビュアーに対して、汎用サブエージェントを起動します：

• OpenCode / Codex： subagent_type: general（task ツールを使用）
• Claude Code： subagent_type: general-purpose
• その他のハーネス：リポジトリを読み取れる最も近い汎用サブエージェント

レビュアーは精神的には読み取り専用とします。ファイルを編集してはいけません。再現が必要なレビュアーは、自分のスクラッチコピーまたはワークツリーで実行し、決して元の場所で実行しないでください。

すべてのレビュアーに、以下のブリーフと記入済みテンプレートを渡します：

この変更を壊してみてください。各所見を実際のコードに対する実行で証明してください。例：失敗するテスト、再現スクリプト、または誤った動作を示すコマンド出力。設計や計画の場合は、プロトタイプを実行するか、現在のツリーを調査してください。再現は自分のワークツリー内で行ってください。各所見を、タイトル、正確なコマンド、そのコマンドが出力した内容、意図が要求する出力とともに報告してください。実行しなかったものは含めないでください。これはスタイル、命名、構造、および将来の変更が必要なリスクをカバーします。所見なしも有効な結果です。

モデルスラッグが解決できないとして拒否された場合は、Taskツールのエラーメッセージにある有効なスラッグを確認し、最も近い同等のもの（同じファミリーの最も推論能力の高いティアを優先）を選択し、有効なスラッグで起動します。スラッグの問題でレビューをブロックしないでください。

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

1. 表明された意図
2. diffまたはファイルの内容
3. references/rubric.md のレビュー評価基準
4. references/code-quality-review.md のコード品質レンズ

記入済みテンプレートはすべてのレビュアーに同じものが渡されるため、すべてのモデルがコード品質レンズを適用します。

ステップ4：統合

結果が戻ってきたら、統一された全体像を構築します：

1. 各所見を検証する：そのコマンドを再実行します。出力が失敗を示し、その失敗が意図を破る場合、所見を保持します。それ以外は破棄します。根本原因が同じ所見は統合します。
2. すべての所見を解析する：レビュアーからのすべての所見を解析します。
3. コンセンサスを特定する：2つ以上のモデルが独立して提起した所見は、最もシグナルが強いです。
4. 単一モデルの所見を特定する：それでも読む価値はありますが、それに応じて重み付けします。
5. 重複を排除する：異なるモデルが同じ問題を異なる方法で説明する場合があります。これらを統合し、どのモデルが提起したかを記録します。
6. 不一致を記録する：あるモデルが何かを指摘し、別のモデルが明示的に反対のことを言っている場合、それは評決にとって有用なコンテキストです。

ステップ5：リードジャッジメント

あなたはリードレビュアーであり、実用的なシニアエンジニアです。中立的な集約者ではありません。

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

すべての所見を以下のバケットに分類します：

• Act on（行動すべき）：実際の目標を考慮して、正確性、セキュリティ、または保守性に影響を与える実際の問題。これらは実際のPRをブロックするものです。
• Consider（検討すべき）：正当な指摘だが、現時点で対処するコストがメリットを上回るかどうか確信が持てないもの。ユーザーの注意を引く価値があります。
• Noted（記録）：技術的には有効だが、実行可能ではないもの。コンテキスト依存、時期尚早な最適化、または現在の段階では影響が低いもの。
• Dismissed（却下）：間違っている、細かすぎる、またはコンテキストが欠けているもの。簡単な説明を添えます。

各所見について、以下を含めます：

• どのモデルが提起したか
• カテゴリ（act on / consider / noted / dismissed）
• 分類の根拠を1行で

出力形式

評決を以下の構造で提示します：

意図

[ステップ2で表明した意図の段落]

レビュアー

• レビュアー [ラベル]：[モデル名]、[N件の所見]（レビュアーごとに1行の箇条書き）

Act On（行動すべき）

[対処すべき所見。それぞれに：説明、どのモデルが提起したか、なぜ重要なのか]

Consider（検討すべき）

[検討に値する所見。それぞれに：説明、どのモデルが提起したか、トレードオフ]

Noted（記録）

[有効だが優先度が低いもの。簡潔なリスト]

Dismissed（却下）

[却下された所見とその簡単な根拠。実行で証明されなかった所見も含む]

一致マップ

[どの部分でモデルが一致し、どの部分で分岐したか、そして一致/不一致のパターンは何を物語っているか？]

爆発半径（Blast radius）

このモードは、変更が小さいがまだ信頼できず、diffを超えて何を壊すかが問題となる場合に使用します。呼び出し元をリストアップするのが仕事ではありません。grepでそれらはすぐに見つかります。仕事は、grepではわからない破損を見つけることです。

自分の書き込みを信用しない

変更が何を壊すかについての書き込みは、正しく聞こえても無価値です。それが真実であるかどうかにかかわらず、説得力を持って読めてしまいます。だから書き込みを渡してはいけません。全体が依存する1つか2つの事実を見つけ、コードを実行して証明してください。

どの程度確かか

変更の安全性が依存する各事実について、コストが安いうちにこのリストをできるだけ下の方まで進め、どこで止まったかを述べてください。

1. あなたがそう言った。それだけでは無価値。
2. あなたが行を指した。実際の file:line、またはライブラリ自身のソース。
3. 悪いケースが発生し得ないことを示した。失敗をステップバイステップで辿り、到達しないことを確認した。
4. 実際に実行した。実際のコードを呼び出し、間違っていれば大きなエラーを出すスクリプトまたはテスト。
5. 実行中のアプリで再現した。

ステップ4に到達できない安全性の事実は、そう述べてください。確定したものとして書かないでください。ステップ4は通常、アプリが出荷するものと同じライブラリをインポートし、問題にしている正確な関数を呼び出す、1つの小さなスクリプトです。

手順

1. 変更を読む。diff、追加・変更・削除されたシンボル、そして現在何が異なる動作をするか（diffに明示されていない部分も含む）。PRとコミットメッセージを取得して、その背後にある理由を理解する。
2. 安全である根拠となる1つの事実を見つける。リスクに見える変更のほとんどは、例えば「この呼び出しは既に死んでいるキャッシュエントリのみを削除し、他には何もしない」といった単一の事実によって安全になっています。その事実を見つけてください。それが成り立てば、リスクのあるケースのほとんどは一度にクリアされます。ここに時間を費やし、長い可能性のリストには費やさないでください。
3. grepが止まるところを探す。呼び出すライブラリのソースを読み、その固定バージョンとローカルパッチを確認する。実行のタイミングを調査する：マイクロタスク、アンマウントとティアダウン、Solid対React。シンボル検索が見逃すものを追跡する：APIが返すJSON、データベースカラム、ワイヤーフォーマット、同じバイトを読む別の言語、フィーチャーフラグ、3ホップ下流のコード。
4. 各リスクについて正直になる。発生する現実的な可能性と、発生した場合の現実的なコストを示す。確認できたリスクだけを残す。確認してクリアしたものは別にリストする。実際の file:line を引用し、何も見つからない検索も答えになります。決して呼び出し元やAPIを捏造しない。
5. その1つの事実を証明する。実際のコードを実行するスクリプトまたはテストを書き、実行し、何が起こったかを貼り付ける。安価に証明できない場合は、未証明とマークする。誇張してはいけない。
6. 大規模または広範囲な変更の場合は、上記のレビューを複数のモデルで実行する。異なるモデルは異なる実際のバグを発見する。

何を返すか

• 変更の内容。何が変わったか、明白でない部分も含む。
• 安全である根拠となる1つの事実。それを述べ、どのステップまで到達したかを示し、証拠を示す。証明できなかった場合は「未証明」と書く。
• リスク。実際のもののみ。それぞれがどのように壊れるか、file:line、可能性と深刻度、確認方法を示す。重要なものについては証拠を貼り付ける。
• クリアしたもの。確認して問題ないと判断したもの。
• マージ前にやること。実際のバグを捉える最も安価なテストまたは再現（書いたスクリプトを含む）。

unslop を通して書き、実際のコードを引用し、公開される前にプライベートなものをすべて削除してください。

返答： 上記の書き込み。安全性の事実が証明されているか、未証明とマークされていること。