mcpField
I
interrogate

interrogate

github.com/ericlitmanテスト・品質53846 回インストール1 週間前に更新
リポジトリ

interrogate について

interrogateは、設定済みの複数モデルによる独立したコードレビューを行うスキルです。結果を主レビュー担当者が判断としてまとめ、変更は自動適用しません。

主な機能

  1. 01複数モデルによる並列レビュー
  2. 02レビュー範囲と意図の定義
  3. 03指摘の統合と意見相違の記録
  4. 044段階の主レビュー判断
  5. 05変更の自動適用なし

活用シーン

  1. 01機能ブランチの変更レビュー
  2. 02目的に照らした差分の評価
  3. 03対応優先度に基づく指摘の整理

インストール

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

$npx skills add https://github.com/ericlitman/open-pstack --skill interrogate

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

同梱ファイル

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

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

詳細

精査

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

ディスパッチ契約。 レビュー担当者を起動する前に、provider-dispatch.md を読んでください。設定されたエントリーはプロバイダー修飾子付きの記述子です。親はネイティブと外部の読み取り専用レーンを直接開始します。Codex では、残りの Claude ツール名を codex-tools.md で解決してください。

ステップ 1、範囲

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

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

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

ステップ 2、意図

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

ステップ 3、レビュー担当者の起動

現在のハーネスの pstack モデルシートにある interrogate reviewers の行のエントリーごとに、レビュー担当者を 1 人ずつ、すべて同時に起動します。エントリー数に合わせて、Reviewer A、B などのラベルを付けます。シートまたは該当行がない場合は、その役割の既定値を使用します。ネイティブのレビュー担当者には親のサブエージェント機能を使用します。外部のレビュー担当者にはランチャーを直接使用し、モデルで検証済みの完全な受領記録を返させます。

各レビュー担当者の記述子には read-only アクセス権を割り当て、出力先と受領記録のパスはそれぞれ一意にします。auto または inherit-parent エントリーには、モデルの上書きを指定せずに親のサブエージェント機能を使用し、そのレビュー担当者を親と同じモデルで実行します。

プロバイダー、ログイン、またはモデルが利用できない場合は、ドロップアウトを記録し、完了したレビュー担当者の結果で続行します。最も近いモデルを選んだり、黙ってフォールバックしたりしてはいけません。そうすると、プロバイダーをまたいだ合意の意味が失われます。

references/reviewer-prompt.md を読み、意図、差分またはファイルの内容、references/rubric.md の評価基準、および references/code-quality-review.md のコード品質の観点を盛り込んだ同じテンプレートを、各レビュー担当者に記入します。poteto-mode スキルの「サブエージェント」セクションに従い、各サブエージェントの作業に適した労力を設定します。

ステップ 4、統合

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

ステップ 5、リードとしての判断

あなたはリードレビュアーであり、中立的な集約者ではなく、現実的な上級エンジニアです。詳細な判断の枠組みについては references/lead-judgment.md を読んでください。すべての指摘を、指摘したモデルと一緒に次の 4 つの分類に振り分け、理由を 1 行で述べます。

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

出力形式

意図

[ステップ 2 で述べた意図の段落]

レビュー担当者
  • Reviewer [ラベル]：[モデル名]、[指摘数] 件（レビュー担当者ごとに 1 項目）
対応する

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

検討事項

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

指摘事項

[簡潔なリスト。]

却下事項

[各項目と簡潔な理由。]

合意マップ

[モデル間で意見が一致した点と異なった点、そのパターンからわかること。]

コメント

Markdown 対応