interrogate

Interrogate

コード変更を敵対的にレビューするため、panel モデルごとにレビュー担当者を 1 人ずつ起動します。敵対的なシグナルは、割り当てたペルソナではなく、モデルの多様性から得られます。成果物は、統合された判定です。変更を自動適用してはいけません。

Step 1, 対象範囲

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

• ユーザーが特定のファイルや差分を指定している場合は、それを使用します。
• フィーチャーブランチ上にいる場合は、デフォルトブランチ（git diff $(git merge-base HEAD origin/HEAD)、それがなければ main または master）とのマージベースに対する差分を使い、未コミットの変更も含めて変更一式を確認します。
• ユーザーのメッセージが最近の作業に言及している場合は、関連ファイルを収集します。

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

Step 2, 意図

レビュー担当者を起動する前に、ユーザーのメッセージ、コミットメッセージ、存在する場合は PR の説明、そしてコードから、意図を明確な段落 1 つで述べます。意図が不明瞭な場合は、最善の解釈を述べて進めます。ユーザーは指示を変更できます。

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

~/.config/ox/models.md の panel 行にある各エントリーに対し、エントリーのモデルとエフォートをサブエージェントツールに渡して、すべてのレビュー担当者を同時に起動します。エントリー数に合わせて、Reviewer A、B などのラベルを付けます。ファイルまたは行がない場合、あるいはファイルの # harness 行に別のハーネスが記載されている場合は、自分と同じモデルでレビュー担当者を 3 人起動し、その旨を伝え、ユーザーに /setup-ox models の実行を提案します。この場合、モデルの多様性を活かしたレビューにはなりません。ツールがエントリーを受け付けない場合は、リスト内の最も近いモデルでそのレビュー担当者を起動し、その旨を伝えます。レビューを止めてはいけません。

各ブリーフには読み取り専用であることを明記します。確認のみを行い、書き込みも Git コマンドの実行もしないよう指示します。REVIEWER-PROMPT.md はすべてのレビュー担当者で同じ内容にします。記載する内容は、示した意図、差分またはファイルの内容、RUBRIC.md の評価基準、CODE-QUALITY.md のコード品質の観点です。

Step 4, 統合

結果が返ってきたら、全体像をまとめます。各レビュー担当者の指摘を解析し、同じ問題を別の表現で指摘しているものを統合し、それぞれを挙げたモデルを記録します。2 つ以上のモデルが独立して挙げた指摘は、最も信頼性の高いシグナルです。1 つのモデルだけの指摘も確認しますが、それに応じて重み付けします。意見の相違にも触れます。あるモデルが問題を指摘し、別のモデルが明確に反対の見解を示している場合は、判定の参考情報とします。

Step 5, リードレビュー担当者の判断

あなたはリードレビュー担当者であり、中立的な集約役ではなく、現実的な判断を下すシニアエンジニアです。判断の枠組み全体については LEAD-JUDGMENT.md を読んでください。すべての指摘を、指摘したモデルと 1 行の理由を添えて、次の 4 つの区分に分類します。

• 対応する。実際の目標に照らして、正しさ、セキュリティ、保守性に影響する実質的な問題です。実際の PR ならブロック要因になります。
• 検討する。妥当な指摘ですが、今すぐ対処するコストに見合うかは不確かです。ユーザーが検討すべき内容です。
• 記録する。技術的には妥当ですが、対処する必要はありません。コンテキストに依存するもの、時期尚早なもの、影響が小さいものです。
• 却下する。誤り、細かすぎる指摘、またはコンテキストの見落としがあるものです。簡潔な理由を添えます。

出力形式

意図

[Step 2 で述べた意図の段落]

レビュー担当者

• Reviewer [ラベル]：[モデル名]、[指摘数] 件（レビュー担当者ごとに箇条書き 1 つ）

対応する

[各指摘：説明、挙げたモデル、重要な理由。]

検討する

[各指摘：説明、挙げたモデル、トレードオフ。]

記録する

[簡潔なリスト。]

却下する

[各指摘と簡潔な理由。]

一致点マップ

[モデル間で一致した点と見解が分かれた点、およびそこから読み取れる傾向。]