mcpField
I
interrogate

interrogate

github.com/cursorテスト・品質14.5k4.7k 回インストール今日更新
リポジトリ

interrogate について

interrogateは、複数モデルによるコード変更の対抗的レビューを調整し、結果を統合するスキルです。変更を自動適用せず、多様なモデルの意見を得たいコードレビュアー向けです。

主な機能

  1. 01差分や関連ファイルに基づくレビュー範囲の設定
  2. 02分析前のレビュー意図の明確化
  3. 03設定モデルごとのレビュアー実行
  4. 04重複する指摘や相反する指摘の統合
  5. 05対応の優先度に基づく指摘の分類

活用シーン

  1. 01機能ブランチの変更セットのレビュー
  2. 02最近の作業に関連するファイルの確認
  3. 03複数レビュアーが挙げた問題の優先付け

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/cursor/plugins --skill interrogate

インストール後、Claude Code で/interrogateを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
code-quality-review.md
lead-judgment.md
reviewer-prompt.md
rubric.md

詳細

Interrogate

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

Step 1, スコープ

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

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

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

Step 2, 意図

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

Step 3, レビュアーの起動

~/.cursor/rules/pstack-models.mdc の interrogate reviewers 行にあるエントリーごとに1人ずつ、Task ツールを使ってすべてのレビュアーを1つのメッセージで起動します。エントリー数に合わせて、Reviewer A、B、以降のラベルを付けます。ルールまたは該当行がない場合は、表のデフォルトを使用します。

サブエージェントデフォルトモデル
Reviewer Aclaude-opus-5-5-xhigh
Reviewer Bgrok-4.7-xhigh-fast

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

Task ツールが構成されたエントリーを受け付けない場合は、そのレビュアーを該当ファミリーの表のデフォルトで実行し、その旨を伝えます。ファミリーはプレフィックスで判断します。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つ以上のモデルが独立して挙げた指摘は、最も信頼性の高いシグナルです。単独モデルの指摘も確認しますが、重みは相応に調整します。意見の相違にも注目します。あるモデルが指摘し、別のモデルが明示的に反対の見解を示している場合は、判定の参考情報とします。

Step 5, 主担当としての判断

中立的な集約者ではなく、現実的なシニアエンジニアとして最終判断を下します。詳細な枠組みについては references/lead-judgment.md を読みます。すべての指摘を、モデル名と1行の根拠を添えて、次の4つのカテゴリに分類します。

  • 対応する。実際の目標に照らして、正確性、セキュリティ、または保守性に影響する真の問題です。実際のPRならブロック要因になります。
  • 検討する。妥当な指摘ですが、今すぐ対応するコストに見合うか確信が持てません。ユーザーが検討する価値があります。
  • 記録する。技術的には正しいものの、対応可能な指摘ではありません。状況に依存するもの、時期尚早なもの、または影響が小さいものです。
  • 却下する。誤り、些末な指摘、またはコンテキストを考慮していない指摘です。簡潔な理由を添えます。

出力形式

意図

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

レビュアー
  • Reviewer [ラベル]：[モデル名]、[指摘数]件（レビュアーごとに1つの箇条書き）
対応する

[それぞれについて：説明、指摘したモデル、重要である理由。]

検討する

[それぞれについて：説明、指摘したモデル、トレードオフ。]

注記

[簡潔な一覧。]

却下

[それぞれについて、簡潔な理由。]

合意のマップ

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

コメント

Markdown 対応