mcpField
I
interrogate

interrogate

github.com/mdsmithaustinテスト・品質8161 回インストール1 日前に更新
リポジトリ

interrogate について

interrogate は、対抗的なコードレビューを行うエージェントスキルです。設定されたモデルごとにレビュー担当を起動し、変更を自動適用せずに結果を統合します。

主な機能

  1. 01モデルごとの並列レビュー
  2. 02差分やファイルに基づく範囲設定
  3. 03レビュー前の意図確認
  4. 04分類別のレビュー結果統合
  5. 05コード変更の自動適用なし

活用シーン

  1. 01フィーチャーブランチの変更レビュー
  2. 02プルリクエストへの複数モデルの個別評価

インストール

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

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

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

同梱ファイル

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

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

詳細

問題を洗い出す

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

ステップ 1：対象範囲

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

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

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

ステップ 2：意図

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

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

Task ツールを使って、すべてのレビュー担当者を 1 つのメッセージで起動します。interrogate reviewers ロールのエントリごとに 1 人ずつ、エントリ数に合わせて Reviewer A、B、以降のラベルを付けます。既定値は以下の表です。起動には pstack-harness スキルを使用します。その Spawn a role セクションでロールを解決し、この CLI の起動呼び出しを作成します。

サブエージェント既定のモデル
Reviewer Afable
Reviewer Bopus
Reviewer Csonnet

各レビュー担当者について：

  • subagent_type：general-purpose
  • model と effort：Spawn a role に従って解決した、そのレビュー担当者の arm。
  • readonly：true

Task ツールが設定済みのエントリまたは表の既定値を受け付けない場合は、pstack-harness スキルを使って対処します。表の既定値が拒否された場合は、pstack リポジトリにこのステップの Default model 表と、リゾルバーが読み込むファイルである skills/setup-pstack/examples/pstack-models.md を更新するための別個の PR も作成します。スラッグの問題でレビューを止めてはいけません。エイリアスのエントリを拒否されたスラッグとして扱ってはいけません。

references/reviewer-prompt.md を読み、そこに記載された意図、差分またはファイルの内容、references/rubric.md の評価基準、および references/code-quality-review.md のコード品質の観点を使って、すべてのレビュー担当者向けに同じテンプレートを記入します。

ステップ 4：統合

結果が返ってきたら、統一された全体像を構築します。何かを統合する前に、レビュー担当者が実行したモデル名を示し、同じモデルを共有する arm は 1 人のレビュー担当者として数えます。各レビュー担当者の指摘をすべて確認します。同じ問題を異なる表現で説明した指摘をまとめ、どのモデルがそれぞれを指摘したか記録します。2 つ以上のモデルが独立して指摘したものは、最も有力なシグナルです。単独のモデルによる指摘も確認しますが、それに応じて重み付けします。意見の相違にも触れます。あるモデルが問題を指摘し、別のモデルが明確に反対のことを述べた場合、それは判定の文脈になります。

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

中立的な集約者ではなく、現実的なシニアエンジニアとして、レビューを主導します。詳しい枠組みについては references/lead-judgment.md を読みます。すべての指摘を、指摘したモデルと 1 行の根拠を添えて、次の 4 つの分類に振り分けます。

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

出力形式

意図

[ステップ 2 で示した意図の段落]

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

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

検討する

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

記録する

[簡潔な一覧。]

却下する

[各項目と簡単な根拠。]

合意マップ

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

コメント

Markdown 対応