interrogate

問題を調査する

太字またはバッククォートで示されたスキル名、あるいは /<name> として実行されるスキルは、このスキルのディレクトリの隣にある ../<name>/SKILL.md ファイルです。プレフィックスなしで示された原則名は、../principle-<name>/SKILL.md ファイルです。そのファイルを読み、従ってください。pstack のスキルのほとんどはユーザー専用のため、スキルツールでは読み込めません。すべての delegate_task 呼び出しには、../poteto-mode/SKILL.md の「Subagents」セクションにあるデフォルト設定が適用されます。

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

Step 1, 範囲

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

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

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

Step 2, 意図

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

Step 3, レビュアーの起動

~/.config/pstack/pstack-models.md の interrogate reviewers 行にある各エントリーにつき、delegate_task の子タスクを 1 つずつ割り当て、すべてのレビュアーを 1 回のメッセージで起動します。エントリー数に合わせて、Reviewer A、B などのラベルを付けます。ファイルまたは該当行がない場合は、親スレッドのモデルで Reviewer A を実行し、さらに orchestrator_capabilities が canRunChildTask を報告する他の各プロバイダーの最強モデルで、最大 3 人まで追加のレビュアーを実行します。その旨を伝え、/setup-pstack を提案してください。

各レビュアーのタイトルは interrogate reviewer <label> とし、書き込み禁止、調査のみ、git コマンド禁止を明記した簡潔な指示を含めます。また、「Subagents」セクションの指定に基づいて target を設定します。auto または inherit-parent のエントリーでは target を省略し、そのレビュアーを親モデルで実行します。

設定されたエントリーが delegate_task に拒否された場合、そのレビュアーには orchestrator_capabilities に記載された同じプロバイダーの最も近いモデルを使い、その旨を伝えます。そのレビュアーを理由にレビューを中断してはいけません。エイリアスのエントリーを拒否されたエントリーとみなしたり、フォールバックを適用したりしてはいけません。

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 で述べた意図の段落]

レビュアー

• レビュアー [label]：[model name]、[N findings]（レビュアーごとに1つの箇条書き）

対応する項目

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

検討する項目

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

記録済み

[簡潔な一覧。]

却下した項目

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

合意マップ

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