コード変更を別のモデルと最大3ラウンドでレビューします。レビューアが変更を読み、ブレイカーがテストで変更を破ろうとします。各修正は発見事項を解決する最小限のものに保ち、発見事項が誤っている場合は証拠をもって反論します。
1. レビューアとブレイカーの概要
レビューアとブレイカーは、ユーザーが指定したモデルファミリー（sol、opus、…）のorchestrator_capabilities内で最も新しいモデルであり、指定された労力で動作します。他のモデルオプションは設定しません。プロバイダー単体（gpt、claude）ではファミリーは指定されません。ファミリーまたは労力が欠落している場合は、それを尋ね、回答があるまでそれ以外のことは行いません。
ベースを固定します。呼び出し元が渡したものがあればそれを使用し、そうでなければgit merge-base HEAD <remote>/<default-branch>を使用します。ここでリモートは変更がマージされる先（フォークの場合はupstream）です。変更が未コミットのみの場合はHEADを使用します。リポジトリの検証スキル（.agents/skills/verify/）があればそれを通じて、変更をカバーするチェックを実行し、ラウンド1の前に失敗したものを修正します。実行したリビジョン（未コミットの変更を含む）を記録します。
すべてのラウンドを新しいdelegate_taskとして開始します。反論と以降のラウンドは新しい概要に入れ、完了したレビューアへのフォローアップメッセージには決して入れません。タイムアウトまたはエラーは承認ではありません。失敗したエージェントを1回再起動します。
差分がコメント、ドキュメント、またはフォーマットのみを変更する場合、ループを実行せず、最終メッセージでその旨を伝えます。ラウンド1では、レビューアとブレイカーを並行して開始し、ブレイカーはisolation: "worktree"とします。差分が実行されるコードを変更しない場合は、ブレイカーをスキップします。軽量実行（see-it-throughティアが渡された場合）では、ラウンド1でブレイカーを開始しません。レビューアが返信したら、テストで解決できる可能性のある、その「Not verified」行の条件にスコープされたブレイカーを開始します（該当する場合）。
両方の概要は、次のヘッダーで始まります。
Repo: <絶対パス> Base: <sha> Out of scope: <スコープ>
Standards: <リポジトリのルールファイル（例：AGENTS.md、CONTRIBUTING.md）、またはなし>
Setup: <すべてのシェルが最初に実行する必要があるもの（例：ピン留めされたツールチェーンスクリプト）、および新しいチェックアウトに必要なもの（例：インストール）、またはなし>
Checks: <結果> Running now: <実行中のチェック、またはなし>
Request: <ユーザーのリクエストまたは概要、一字一句、またはその絶対パス>
Approach: <承認されたアプローチ、またはその絶対パス、またはなし>。その主張は作成者のものです。差分が依存するものを確認してください。
Acceptance: <変更の前に書かれた受け入れチェックを保持するコミットまたはパッチ、またはなし>
Diff: git diff <base>。また、git status --short から追跡されていないファイルも読み取ってください。
Conditions: 差分を読む前に、リクエストから受け入れ条件を記述してください。成功時、失敗時、キャンセル時、再試行時にユーザーが表示または取得すべきもの。部分的な失敗後（メモリ、ディスク、画面に残っているもの）。繰り返し時、または以前の試行が新しいものより後に終了した場合。await がユーザーの操作後に返された場合。結果を示すすべての画面（キャッシュされたデータを含む）。そして、変更が残す可能性のあるすべての状態から抜け出す方法。変更されたコードがそのケースに到達する場合にのみ記述してください。意図されたパス上、変更されたコードの他のすべての呼び出し元を通して、そして変更が現在信頼する状態の他のすべての書き込み元を通して（両方を検索）。
レビューアの概要（ヘッダー後）：
Review only: 読み取り、トレースのみ。編集、コミット、プッシュ、コメント、サブエージェントの開始、テストの作成や実行、ビルドは行わないでください。
Conditions の指示に従って受け入れ条件を記述し、次にApproach内でどのように変更を行うかを記述してください。最終的な返信を両方で一字一句から始めてください。VERDICT行はそれに続きます。
変更に関する問題を見つけ、各条件をコードを通してユーザーが表示または取得するものまでトレースしてください。あなたのアプローチは、差分が失敗する条件を満たす場合、またはより少ないコードですべての条件を満たす場合にのみ、発見事項となります。
見つけたバグごとに、そのクラスに名前を付け、差分とその呼び出し元の残りの部分で同じ間違いを探し、差分が異なる方法で処理する兄弟ケースも含めてください。クラスごとに1つの発見事項を報告し、すべての場所をリストしてください。
変更をStandardsファイルと照らし合わせてチェックしてください。それらの発見事項に[standards]タグを付け、リンターと型チェッカーが強制するものはスキップしてください。
どの条件も必要としないコードやガード、リポジトリまたはプラットフォームがすでに提供している新しいコード、およびStandardsまたは周囲のコードの慣習から逸脱したコード（単に好みのスタイルではないもの）をニットとしてフラグしてください。
変更が状態の競合する所有権、2か所で行われた決定、呼び出し元が覚えておく必要のある義務、または呼び出し元がバイパスできる境界を導入するかどうかをチェックしてください。それらに[structure]タグを付け、コードとその結果に名前を付け、以下の定義でグレード付けしてください。そのような結果がない別の設計はニットです。より大規模な再設計は、最小の修正で修正できない理由がある場合にのみ発見事項となります。
Acceptance内のチェックへの編集で、約束されたことを証明できなくなった場合、それはshouldです。
blocker = 意図されたケースが間違っています。should = この変更が引き起こす問題で、サポートされているアクションまたは入力で到達可能なもの：ユーザーアクション、ディスク上のファイル、I/Oエラー、ユーザーが作成したファイル。実行して表示するか、コードを通してトレースすることで明らかにされ、差分が触れていない呼び出し元を通しても含みます。変更が追加したテストで、それが証明する動作なしでパスできるものはshouldです。
nit = スタイル、小さなパフォーマンス、洗練。pre-existing = ベースでも同じ障害が発生し、テストまたはトレースで示され、変更が到達しやすくしたり、主張と矛盾したりしないもの。
VERDICT: APPROVE または CHANGES。その後、発見事項ごとに1行：
S1 [blocker|should|nit|pre-existing] <file>:<line> <主張>. Fix: <最小限の修正>
次に Checked: 条件ごとに1行： <file>:<line> とその行が確立するもの。
次に Not verified: 確認できなかったものとその理由、またはなし。
ブレイカーの概要（ヘッダー後）：
この変更を破ってください。コミット、プッシュ、コメント、またはサブエージェントの開始はしないでください。
自分のチェックアウトでのみ作業してください。開始した作業ディレクトリは、<repo>のHEADのコピーです。最初に変更の未コミット部分を持ってきてください：git -C <repo> diff HEAD | git apply。次に、git -C <repo> status --short でリストされた追跡されていないファイルをコピーしてください。<repo>内のファイルやユーザーの設定を決して変更せず、プッシュ、投稿、通知するものを実行しないでください。パッケージマネージャーのキャッシュは問題ありません。E2E実行とRunning nowにリストされているものはスキップし、テストに必要なものだけをコンパイルしてください。
Conditions の指示に従って受け入れ条件を記述してください。各条件について、その条件が壊れた場合に失敗する最小のテストを作成して実行し、ユーザーが表示または取得するものに対してアサートしてください。
変更が証拠として追加したE2E未満の各テストについて、キャッチすべきガードを元に戻すか、前提条件を壊し、実行し、その後コードを復元してください。
COULDN'T TEST は、このレベルで到達できない条件（E2Eが必要な場合など）に対してのみ使用してください。遅いキューや自分の壊れたセットアップは該当しません。テストを1つのジョブにまとめ、キャンセルせずに待ち、セットアップを修正してください。
返信する前に、既存のテストではカバーされない条件をカバーする、パスするテストのパッチを<keep path>に書き、追加した他のすべてを削除してください。
返信は、条件ごとに1行：B1 HELD <条件> — <コマンド>；B2 BROKE <条件> — <コマンド> と失敗した出力；または B3 COULDN'T TEST <条件> — 理由。次に、プルーフテストごとに1行：P1 FAILS <test> with <guard> undone；または P2 STILL PASSES <test> with <guard> undone。次に：Kept: <keep path> と各テストがカバーする条件、またはなし。
<keep path>を選択してください：両方のチェックアウトの外部の絶対パス。
2. 発見事項への回答
レビューアの概要の定義に従って、各発見事項を自分でグレード付けしてください（元のラベルは無視します）。各 BROKE および STILL PASSES 行を発見事項として扱います。
- 同意する：まずそれを再現します。実用的な場合に意味のあるテストで現在のコードで失敗するものを使用し、そうでない場合は直接的な再現（コマンドと出力）とその制限を記述します。CIが実行するものやベースが行うことなど事実に関する主張は、そのソースに対して確認します。次に、変更されたコードの兄弟ケースと呼び出し元を検索して、発見事項のクラスがさらにないか探し、変更が導入または露出させたすべてのインスタンスに最小限の修正を適用します。関連のない既存のものはフォローアップとしてリストします。テストがパスすること（STILL PASSESの発見事項の場合、修正されたテストがガードを元に戻すと失敗すること）を示し、テストを保持します。新しいロック、キャッシュ、ヘルパー、またはオプションよりも、コードの削除または狭小化を優先します。
- 同意しない：証拠（テストまたはコマンド出力）とともに理由を述べます。コードだけから読み取れる理由（「それは起こり得ない」など）は、発見事項を論争中とし、却下またはグレードダウンしません。
- ニット：差分が追加、変更、または移動するコードに対して、修正がコードを削除する場合、リポジトリまたはプラットフォームが提供するものを再利用する場合、またはコードをStandardsまたは周囲のコードに準拠させる場合に適用します。その際、すべてのチェックをパスしたままにし、明確さを長さと交換しないようにします。パス、ケース、オプション、または互換性レイヤーを追加するニット、修正がユーザーの表示または取得するものを変更するニット、および単に好みに過ぎないニットは、1行で却下します。
- 既存または範囲外：1行で却下します。
ブレイカーのパッチ内の各テストをコミットするか、その条件をカバーする既存のテストに名前を付けます。
ループを終了するためだけに同意しないでください。チェックとgit diff --shortstat <base>を再実行し、レビューがテスト以外に追加したもので、受け入れられた発見事項に必要ないものは削除します。コードが大きくなる場合でも、最小限の正しい修正を保持します。
3. 次のラウンド
ブロッカーまたはshouldが未解決であるか、動作コードが変更された場合にのみ、次のラウンドを開始します。ヘッダーを送信します。そのConditions行はラウンド1のレビューアの条件に置き換えられ、レビューアの概要は条件とスケッチの行を除き、以前のすべてのidは修正済み、論争中（証拠付き）、または却下（理由付き）とマークされ、前回のラウンド以降に変更されたハンクが含まれます。レビューアに、未解決のidとそれらのハンクのみをレビューし、それらのハンクが変更する動作とその呼び出し元に対して新しい条件を記述し、以前の各idを解決済みまたはまだ未解決とマークし、新しい発見事項に最後のidの後に番号を付けるように指示します。修正が動作、順序付け、または所有権を変更した場合（例：書き込みをawaitの後に移動するなど）、同じヘッダーでブレイカーも開始し、それらのハンクとその呼び出し元に対してのみ条件を記述してテストするように指示します。
4. 終了
ブロッカーまたはshouldが未解決ではなく、テスト、コメント、フォーマット以外の最後の変更がラウンドを通過した場合に完了します。APPROVEはレビューされたコードに対してループを早期に終了します。原因を修正できるCOULDN'T TESTがある場合は、新しいブレイカーを送信します。E2Eを必要とするものは作成者向けにリストします。ラウンド3後もブロッカーまたはshouldが論争中の場合は、dispute-round.mdで論争ラウンドを実行します。INCONCLUSIVEのままの発見事項は、未解決の論争ありで終了したループとなり、承認されません。却下されたニットと既存の発見事項は却下されたままです。
最終メッセージ：実行されたラウンド数、モデル、発見事項が変更したもの、タグ付けされた各動作、テスト、主張、または洗練、変更前後の差分サイズ、テストまたは出力が間違いを示したために削除された発見事項、および却下された各ニットまたは既存の発見事項とその理由。ブレイカーがテストしたもの、壊れたもの、そのうちレビューアも見つけたもの、およびコミットされたテストでカバーされていない各条件を追加します。論争ラウンドが実行された場合は、各結果を提供します。確認されていないリスクを平易な言葉でリストします。evals/results.jsonlが存在し、レビューアモデルがそれに記録された最後のモデルと異なる場合は、その旨を述べ、回帰スイート（evals/README.md）の実行を提案します。