interrogate

詳細レビュー

Codex では、このスキルに従う前に、スキルごとの注記も含めてプラットフォーム対応表を読んでください。

GitHub Copilot では、このスキルに従う前に、スキルごとの注記も含めてプラットフォーム対応表を読んでください。

Muse では、このスキルに従う前に、スキルごとの注記も含めてプラットフォーム対応表を読んでください。

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

ステップ 1、範囲

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

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

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

ステップ 2、意図

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

ステップ 3、レビュアーの起動

pstack-models.md の interrogate reviewers 行にある各項目につき 1 人、Agent ツールを使ってすべてのレビュアーを 1 回のメッセージで起動し、項目数に合わせて Reviewer A、B というようにラベルを付けます。設定シートまたは該当行がない場合は、表のデフォルトを使用します。

サブエージェント	デフォルトモデル
Reviewer A	opus
Reviewer B	fable
Reviewer C	sonnet
Reviewer D	haiku

各レビュアーの subagent_type は "general-purpose"、readonly は true とし、model には設定された項目、または設定行がない場合は表のデフォルトを指定します。項目が auto または inherit-parent の場合は model を省略し、そのレビュアーは親モデルで実行します。

Agent ツールが設定項目を受け付けない場合、そのレビュアーは該当するファミリーの表のデフォルトで実行し、その旨を伝えてください。ファミリーは Opus、Fable、Sonnet などのモデル名で判定します。該当するファミリーがない場合は、Reviewer A のデフォルトを使用します。表のデフォルトが受け付けられない場合は、エラーメッセージに示された有効なスラッグの中から最も近いもの（同じファミリーと推論レベルを優先）で起動し、デフォルト表を更新するために別の PR を作成します。スラッグの問題でレビューを中断してはいけません。エイリアス項目を、拒否されたスラッグと見なしたり、どちらかのフォールバックを適用したりしてはいけません。

references/reviewer-prompt.md を読み、記載された意図、差分またはファイルの内容、references/rubric.md の評価基準、および references/code-quality-review.md のコード品質の観点を用いて、すべてのレビュアーに同じテンプレートを記入します。poteto-mode スキルの「サブエージェント」セクションに従い、各サブエージェントの推論レベルを選択してください。

ステップ 4、統合

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

ステップ 5：リード判断

あなたは中立的な集約者ではなく、現実的なシニアエンジニアとしてリードレビュアーを務めます。フレームワークの全容については references/lead-judgment.md を読んでください。すべての指摘を4つの区分に振り分け、指摘したモデルと1行の理由を添えてください。

• 対応する。実際の目標に照らして、正確性、セキュリティ、保守性に影響する本質的な問題です。実際のPRであればブロック要因になります。
• 検討する。正当な指摘ですが、今すぐ対処するコストに見合うか確信が持てません。ユーザーの注意を促す価値があります。
• 記録する。技術的には妥当ですが、対応可能な指摘ではありません。状況に依存するもの、時期尚早な最適化、または現段階で影響の小さいものです。
• 却下する。誤り、細かすぎる指摘、または背景情報の不足が原因のものです。簡潔な理由を添えてください。

出力形式

意図

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

レビュアー

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

対応する

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

検討する

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

記録する

[簡潔な一覧。]

却下する

[各項目に簡潔な理由を添えてください。]

合意マップ

[モデル間で合意した点と意見が分かれた点、そしてその傾向が示すこと。]

推論の労力

オーバーライドシートのロール値では、モデル名の後に opus @xhigh のように推論の労力レベルを指定できます。Claude Code で指定できるレベルは low、medium、high、xhigh、max です。使用できるレベルはモデルによって異なります。@ のない値では、シートの default effort 行で指定されたレベル、または session が使われます。その行がない場合は session が使われます。session は推論の労力を指定しないため、通常の方法でディスパッチされます。モデルを読み取る前にサフィックスを取り除いてください。inherit-parent または auto の場合はすべてのレベルで model を省略し、モデル名の場合は model として渡します。レベルはディスパッチの effort フィールドに渡し、通常使用する subagent_type を維持してください。Claude Code の Agent 呼び出しでは effort、Codex の spawn_agent では reasoning_effort に指定します。Muse では Workflow 子エージェントの effort に指定します。subagent_spawn ディスパッチでは、セッションの推論の労力が維持されます。