hyfdev-adversarial-review

敵対的レビュー

成果物が完成し、ユーザーに渡る前にこれを実行します。目的は、成果物を確認することではなく、証拠をもとに反証し、作業セッションで見落とされたものが残っていないかを見つけることです。

用語

• 成果物：ユーザーが実行、マージ、公開、または信頼する完全な単位です。たとえば、PR に出せる状態の変更、調査レポート、推奨事項、記録の編集一式などです。タスク内のステップ、質問への回答、情報の検索、機械的な編集は成果物ではありません。
• 方向性：レビュー担当者に何を探すよう指示するかです。方向性には「オープン」「過剰なエンジニアリング」「残留物」の3種類があり、以下の文面をそのまま使用します。
• 残留物：作業セッションの参加者だけが解決できる成果物内の記述です。残留物の方向性にはその形式が列挙されています。HEAD の状態を確認する読者が、セッションにアクセスできなくても、あらゆる参照を解決し、あらゆる主張を検証できるかが判断基準です。
• ブリーフ：レビュー担当者が受け取るものです。作業箇所を特定するために必要な事実と、1つまたは2つの方向性だけを含み、それ以外は含めません。

実施時期

• 成果物ごとに1回、メインエージェントが完成と判断して報告する前に実施します。また、ユーザーがこのスキルを呼び出した場合にも実施します。
• このスキルの呼び出しは、レビュー担当者の起動を依頼するものです。別途確認を求めないでください。レビュー結果は成果物の報告に記載します。実施しないことを選ぶ場合に限り、ユーザーに確認してください。
• サブエージェントを起動できない場合は、3つの方向性の文面に沿って範囲を限定したセルフレビューを行い、独立したレビューを利用できなかったことを報告に記載します。

レベル

ユーザーが呼び出し時またはメッセージ内でレベルを指定します。指定がない場合はデフォルトを実行します。

• デフォルト：1ラウンド。新規のサブエージェント2つを並行して起動します。レビュー担当者A：オープン。レビュー担当者B：過剰なエンジニアリングと残留物をまとめて確認。修正後に報告します。
• ストロング（强力）：2ラウンド。第1ラウンドは上記のとおり実施して修正し、第2ラウンドでは新規のサブエージェントに同じブリーフを渡します。レビュー担当者は修正後の成果物をレビューし、第1ラウンドについては何も知りません。再度修正した後、両ラウンドをまとめて報告します。
• マックス（极致）：ストロングと同様に2ラウンド実施します。各ラウンドでは、方向性ごとに新規のレビュー担当者を2つずつ起動します。合計で8つです。同じ方向性を担当するレビュー担当者には同じブリーフを渡し、互いの存在は知らせません。

レビュー担当者

新規のサブエージェントは、継承したコンテキストを持たない新しいエージェントであり、メインエージェントのフォークではありません。作業セッションにはアクセスできません。レビュー対象を自分で見つけ、git diff <base>...<head> を実行し、周辺のコードやレポート全体を読み、必要に応じてチェックを実行します。差分、要約、確認箇所の一覧を渡してはいけません。

ブリーフ

テンプレートを埋め、テンプレート外には何も追加しないでください。メインエージェントの計画、推論、実施内容の要約、自己評価、修正履歴、弱点に関するヒント、他のレビュー担当者の出力は、ブリーフに含めてはいけません。

Direction: <open | over-engineering + residue>
Deliverable: <code change | report | record edits>
Location: <worktree path with base and head refs | PR number | file paths>
Request: <the user's request, verbatim | issue #N | path to the file that states the task>
Return: pass, or at most five findings per direction, ranked by how much each would change the result. For each: location, evidence, why it matters.

<direction text, verbatim from this skill>

Request は、ユーザー自身の言葉、またはユーザーが指定した永続的な情報源です。メインエージェントによる言い換えではありません。ユーザーがエージェント作成の候補を参照して採用した場合、採用時のメッセージと採用された候補の両方を、そのままリクエストとして扱います。それ以前に合意された内容の要約はリクエストではありません。リクエストがすでに永続的な場所（イシューやタスクファイルなど）にある場合は、引用するのではなく、その場所を示してください。

方向性の文面

オープン

この成果物を反証してください。そのまま受け入れると問題になる点をすべて見つけます。事実や論理の誤り、裏付けのない主張、証拠の不足、要件と異なる動作、未テストまたは壊れた経路、判断を変えうる見落とされた代替案などが対象です。見つかった問題は、結果への影響が大きい順に並べてください。純粋に見た目だけの好みは無視します。意図する読者が理解または判断するために必要な内容を、より簡潔な表現でも伝えられる場合は、避けられる重複や複雑さを指摘してください。リポジトリが対処を約束していない脅威への防御がないことは、指摘事項に含めません。

過剰な設計

成果物に含まれているものの、依頼では求められていないものを探してください。依頼の範囲を超える内容、利用者が1つしかない抽象化・オプション・パラメーター、誰も求めていない状況への設定やフォールバック、このリポジトリが対処すると約束していない脅威への防御コード、この変更で導入していない動作に関するテストやドキュメント、リポジトリに既存のヘルパーや依存関係があるのに独自に実装したコードなどです。文章の場合、正確で関連性があるからといって必要とは限りません。説明や例の繰り返し、読者が理解または判断するうえで影響しない詳細がないか確認してください。項目ごとに、何がコストになるのか、より簡潔な形は何かを示してください。文章については、削除または簡略化する箇所を引用し、正確性、範囲、トレードオフについて必要な説明を残したうえで、削除または置き換えの内容を示してください。

残存物

成果物内のあらゆるテキスト（コード、コメント、テスト、ドキュメント、コミットメッセージ、PR のタイトルと本文、報告文）を、作業時のやり取りを知らず、HEAD の状態を読む読者の立場で確認してください。その読者には解決できない内容や、その場にいない人に語りかける内容を指摘してください。削除されたものや試したものへの言及、状態ではなく変更の経緯を語る記述、レビュアーに向けた正当化、何もないことを確認するテストやコメント、ためらいを示す表現や計画の名残などです。項目ごとに文を引用して、現在形で言い換えるか、「削除」と示してください。決定やその経緯を主題とする記録（意思決定記録、意思決定台帳、事後検証など）では、何を決定し、何を試し、その理由が何かを記載します。こうした内容は残存物ではありません。

統合

• 原則として修正してください。各指摘を自分で根拠に照らして検証し、妥当なものは確認を求めずに適用してください。例外は2つあります。どちらもユーザーに質問するものではありません。ユーザーのルールにより承認が必要な編集は、適用せずに提示してください。このタスクでユーザーが示した指示に反する指摘は適用せず、その旨を報告してください。
• 理論上の脅威、敵対的な環境、または多層防御に関する指摘は、タスクにその脅威モデルが含まれている場合、またはリポジトリがすでにその耐性を約束している場合を除き、実装せずに記録してください。
• 票数を数えないでください。複数のレビュアーが同じ指摘を報告しても、根拠が強まるわけではなく、1つの指摘です。内容ごとにまとめてください。
• 残存物は現在形で言い換えるか、削除して修正してください。確認や削除を行ったことを伝える注記を追加してはいけません。
• 修正後にユーザーへ報告してください。何が見つかり、何を変更し、何を適用しなかったかとその理由を伝えてください。strong と max の場合は、すべてのラウンドをまとめて1つの報告にしてください。