interrogate

Interrogate

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

Step 1, 範囲

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

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

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

Step 2, 意図

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

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

Cursor の設定ファイル（~/.cursor/rules/pstack-models.mdc）、Claude Code の設定ファイル（~/.claude/rules/pstack-models.md）、またはその他のハーネスの設定ファイル（~/.agents/pstack-models.md）にある interrogate reviewers の行の各項目につき1人ずつ、Task ツールを使って、すべてのレビュー担当者を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-*、および grok-*（cursor-grok-* と composer-* を含む）です。拒否された composer-* 項目には Reviewer B の既定値を使います。該当するファミリーがない場合は、Reviewer A の既定値を使います。表の既定値が拒否された場合は、エラーメッセージまたはハーネスのモデル一覧にある有効なスラッグから最も近いものを選びます（同じファミリーと推論レベルを優先）。既定値の表を更新するための別の PR を作成します。スラッグの問題でレビューを止めてはいけません。エイリアス項目を拒否されたスラッグとして扱ったり、いずれかのフォールバックを適用したりしてはいけません。

references/reviewer-prompt.md を読み、意図、差分またはファイルの内容、references/rubric.md の評価基準、references/code-quality-review.md のコード品質の観点を含めて、すべてのレビュー担当者に同じテンプレートを記入します。サブエージェントの推論レベルと速度（高速または標準）は、poteto-mode スキルの「Subagents」セクションに従って選択します。

Step 4, 統合

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

ステップ 5：リード判断

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

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

出力形式

意図

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

レビュアー

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

対応する

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

検討する

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

記録する

[簡潔な一覧。]

却下する

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

合意マップ

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