interrogate

Interrogate

設定されたモデルごとにレビュアーを1人起動し、コード変更を敵対的にレビューします。敵対的な視点は、割り当てられたペルソナではなく、モデルの多様性によって得られます。成果物は統合された判定です。変更を自動適用してはいけません。

Step 1, 範囲

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

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

差分またはファイルの内容に、レビュアーがコードを理解するために必要な周辺コンテキストのファイルを添えてください。

Step 2, 意図

レビュアーを起動する前に、ユーザーのメッセージ、コミットメッセージ、存在する場合は PR の説明、コードから、意図を明確な1段落で示します。意図が不明な場合は、先にユーザーへ確認してください。

Step 3, レビュアーの起動

Task ツールを使って、~/.cursor/rules/pstack-models.mdc（Cursor の場合）または ~/.agents/pstack-models.md（その他のハーネスの場合）の interrogate reviewers 行にある各エントリにつき1人、すべてのレビュアーを1つのメッセージで起動します。エントリ数に合わせて Reviewer A、B のようにラベルを付けてください。ファイルまたは該当する行がない場合は、表のデフォルトを使用します。

その他のハーネス。 このスキルの起動には Cursor の Task ツールを使用します。別のハーネスでは、そのサブエージェントツールを使用してください。Claude Code では Agent（subagent_type: general-purpose）、OpenCode では task（subagent_type: general）、Codex では spawn_agent を使います。ツールに存在しないパラメーターは省略してください。Pi のように拡張機能がなく、ハーネスにサブエージェントツールがない場合は、各レビュアーの役割を順番に自分で実行してください。

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

各レビュアーには subagent_type: generalPurpose、readonly: true を指定し、設定されたエントリ、または設定行がない場合は表のデフォルトに従って model を設定します。エントリが auto または inherit-parent の場合は model を省略し、そのレビュアーを親モデルで実行します。

サブエージェントツールが設定されたエントリを受け付けない場合は、そのファミリーの表のデフォルトで実行し、その旨を伝えてください。ファミリーはプレフィックスで判定します。claude-*、および cursor-grok-* と composer-* を含む grok-* が対象です。拒否された composer-* エントリには Reviewer B のデフォルトを使用します。該当するファミリーがない場合は、Reviewer A のデフォルトを使用してください。表のデフォルトも拒否された場合は、エラーメッセージまたはハーネスのモデル一覧にある有効なスラッグから最も近いものを選び（同じファミリーと推論レベルを優先）、デフォルト表を更新する別の PR を作成してください。スラッグの問題でレビューを止めてはいけません。エイリアスのエントリを拒否されたスラッグとして扱ったり、いずれかのフォールバックを適用したりしてはいけません。

references/reviewer-prompt.md を読み、すべてのレビュアーについて、指定された意図、差分またはファイルの内容、references/rubric.md の評価基準、references/code-quality-review.md のコード品質の観点を含む同じテンプレートを作成してください。poteto-mode スキルの Subagents セクションに従い、各サブエージェントの推論レベルと高速または標準の実行速度を選択してください。

Step 4, 統合

結果が返ってきたら、統一した全体像を構築します。すべてのレビュアーの指摘を解析し、同じ問題を異なる形で述べている指摘は統合して、どのモデルがそれぞれを挙げたかを記録してください。2つ以上のモデルが独立して挙げた指摘は、最も信頼性の高いシグナルです。単独モデルの指摘も確認しますが、重み付けは相応にしてください。見解の相違も記録します。あるモデルが問題を指摘し、別のモデルが明示的に反対の見解を示した場合は、判定の文脈として扱ってください。

ステップ 5：リード判断

あなたは中立的な意見集約者ではなく、現実的なシニアエンジニアであるリードレビュアーです。全体のフレームワークについては references/lead-judgment.md を読んでください。すべての指摘を、指摘したモデルと1行の根拠を添えて、次の4つの分類のいずれかに振り分けてください。

• 対応する。実際の目標に照らして、正確性、セキュリティ、保守性に影響する実際の問題です。実際の PR であれば、マージを阻止する問題です。
• 検討する。妥当な指摘ですが、今すぐ対応するコストに見合うか判断できません。ユーザーが検討する価値があります。
• 記録する。技術的には妥当ですが、対応可能なアクションではありません。状況次第のもの、時期尚早な最適化、または現段階で影響が小さいものです。
• 却下する。誤り、細かすぎる指摘、または文脈を欠いている指摘です。簡潔な理由を添えてください。

出力形式

意図

[ステップ 2 に記載された意図の段落]

レビュアー

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

対応する

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

検討する

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

記録する

[簡潔な一覧。]

却下する

[各指摘と簡潔な根拠。]

合意マップ

[モデル間で一致した点と意見が分かれた点、その傾向から分かること。]