使用另一個模型審查程式碼變更，最多進行 3 輪：審查者讀取變更，破壞者嘗試透過測試來破壞它。保持每個修正是解決其發現的最小規模，並在發現錯誤時以證據反駁。
1. 告知審查者與破壞者
審查者與破壞者是最新的模型，位於使用者指定的系列（sol、opus 等）的 orchestrator_capabilities 中，並採用指定的努力等級；不設定其他模型選項。僅有供應商（gpt、claude）而不指定系列等同於未指定。如果系列或努力等級缺失，請詢問使用者，並且在他們回答之前不做任何其他事情。
釘選基礎提交：由呼叫者傳入的基礎提交，否則為 git merge-base HEAD <remote>/<default-branch>，其中遠端是變更會合併到的遠端（在 fork 上為 upstream），如果變更僅包含未提交的內容則為 HEAD。執行涵蓋此變更的檢查，透過儲存庫的 verify 技能（如果有的話，位於 .agents/skills/verify/），並修正在第 1 輪之前失敗的任何檢查。記錄它們運行時所基於的修訂版本，包含未提交的變更。
每一輪都以全新的 delegate_task 開始。反駁與後續輪次應包含在新的簡報中，絕不能放在已完成審查者的後續訊息中。逾時或錯誤不算是核准：重新啟動失敗的代理一次。
當差異僅包含註解、文件或格式變更時，不執行循環，並在最終訊息中說明。在第 1 輪中，並行啟動審查者與破壞者，破壞者使用 isolation: "worktree"。當差異不改變任何會執行的程式碼時，跳過破壞者。在精簡運行（see-it-through 等級傳入時）中，第 1 輪不啟動破壞者；一旦審查者回覆，則啟動一個破壞者，但其範圍僅限於其「未驗證」行中、可由測試解決的條件（如果有的話）。
兩個簡報都以這個標頭開頭：
儲存庫：<絕對路徑> 基礎：<SHA> 範圍外：<範圍>
標準：<儲存庫的規則檔案，例如 AGENTS.md 或 CONTRIBUTING.md；或無>
設定：<每個 shell 必須先執行的命令，例如固定的工具鏈腳本，以及全新簽出需要的設定，例如安裝；或無>
檢查：<結果> 正在執行：<仍在進行中的檢查；或無>
請求：<使用者的請求或簡報，逐字照抄，或其絕對路徑>
方法：<已核准的方法，或其絕對路徑；或無>。其宣稱屬於作者：請檢查差異所依賴的那些宣稱。
驗收：<保存變更前所撰寫之驗收檢查的提交或修補檔案；或無>
差異：git diff <base>；同時從 git status --short 讀取未追蹤的檔案。
條件：在閱讀差異之前，根據請求撰寫驗收條件：使用者在成功、失敗、取消與重試時應看到或取回的結果；在部分失敗後（記憶體、磁碟與螢幕上留下什麼）；重複時，或較新的嘗試完成時較早的嘗試仍在進行時；當等待在使用者轉移到其他操作後才返回時；在每個顯示結果的表面（包含快取資料）上；以及變更可能會留下的每個狀態的逃脫方式。僅在變更後的程式碼會到達該情況時才撰寫條件：在預期路徑上、透過變更後程式碼的所有其他呼叫者，以及透過變更現在所信任之狀態的所有其他寫入者（搜尋兩者）。
審查者簡報，在標頭之後：
僅審查：閱讀與追蹤。不要編輯、提交、推送、發表評論、啟動子代理，或撰寫或執行測試或建置。
按照「條件」所述撰寫驗收條件，然後說明你會在「方法」範圍內如何進行變更。在最終回覆中以兩者（逐字照抄）開頭；VERDICT 行緊接其後。
找出變更的問題，追蹤每個條件如何通過程式碼到達使用者看到或取回的結果。僅在差異未滿足某個條件，或能以更少的程式碼滿足所有條件時，你的方法才構成一個發現。
對於你發現的每個錯誤，命名其類別，並在差異的其他部分及其呼叫者中尋找相同的錯誤，包含變更處理方式不同的同類案例；每個類別報告一個發現，列出所有位置。
根據標準檔案檢查變更；將這些發現標記為 [standards]，並跳過 linter 和型別檢查所強制執行的項目。
將不需要條件的程式碼或防護措施、儲存庫或平台已提供的新程式碼，以及偏離標準或周圍程式碼慣例的程式碼標記為 nit；而非你純粹偏好的風格。
檢查變更是否引入了競爭的狀態所有權、兩個地方做的決策、呼叫者必須記住的義務，或呼叫者可以繞過的邊界；將這些標記為 [structure]，命名程式碼及其後果，並根據以下定義評分。沒有此類後果的不同設計是 nit；需要更大規模重新設計的設計僅在最小修正無法修復時才構成發現。
對驗收中證明其承諾之檢查的編輯是 should。
blocker = 預期情況錯誤。should = 此變更導致的問題，且可透過支援的操作或輸入觸發：使用者操作、磁碟上的檔案、I/O 失敗、使用者製作的檔案，透過執行程式或追蹤程式碼顯示（包含未受差異觸及的呼叫者）。變更新增的測試可以在沒有其所證明之行為的情況下通過，屬於 should。
nit = 風格、微效能、潤飾。pre-existing = 相同的失敗發生在基礎上（透過測試或追蹤顯示），且變更既未使其更容易觸發，也未與其宣稱矛盾。
VERDICT：APPROVE 或 CHANGES，然後每個發現一行：
S1 [blocker|should|nit|pre-existing] <檔案>:<行號> <宣稱>。修正：<最小修正>
然後 Checked：每個條件一行：<檔案>:<行號> 以及該行所確立的內容。
然後 Not verified：你無法確認的內容及其原因；或無。
破壞者簡報，在標頭之後：
破壞這個變更。不要提交、推送、發表評論或啟動子代理。
僅在你的簽出中工作，也就是你開始所在的當前工作目錄，它是 <儲存庫> 的 HEAD 的拷貝。首先帶入變更的未提交部分：git -C <儲存庫> diff HEAD | git apply，然後複製 git -C <儲存庫> status --short 列出的未追蹤檔案。永遠不要更改 <儲存庫> 或使用者設定中的檔案，也不要執行任何推送、發布或通知的操作；套件管理器快取可以保留。跳過 E2E 執行以及「正在執行」中列出的任何項目；僅編譯你的測試所需的內容。
按照「條件」所述撰寫驗收條件。對於每個條件，撰寫並執行最小的測試，該測試會在條件被破壞時失敗，並斷言使用者看到或取回的結果。
對於變更作為證明新增的每個非 E2E 測試，撤銷它應捕捉的防護措施，或破壞其前置條件，執行它，然後還原程式碼。
COULDN'T TEST 僅適用於此級別無法觸及的條件，例如需要 E2E 的條件。慢速佇列或你自己的設定損壞不屬於此類別：將你的測試批次處理為一個任務，等待它而不取消，並修正你的設定。
在你回覆之前，將你通過的測試（涵蓋現有測試未覆蓋的條件）撰寫為修補檔案並放入 <保留路徑>，然後刪除你新增的所有其他內容。
回覆，每個條件一行：B1 HELD <條件> — <命令>；B2 BROKE <條件> — <命令> 和失敗輸出；或 B3 COULDN'T TEST <條件> — 原因。然後每個證明測試一行：P1 FAILS <測試> 在 <防護措施> 撤銷時；或 P2 STILL PASSES <測試> 在 <防護措施> 撤銷時。然後：保留的內容：<保留路徑> 以及每個測試涵蓋的條件；或無。
選擇 <保留路徑>：兩個簽出外部的絕對路徑。
2. 回應發現
根據審查者簡報的定義自行評分每個發現，無論其原始標籤為何。將每個 BROKE 和 STILL PASSES 行視為一個發現。
- 同意：首先重現它，在可行的情況下使用一個對當前程式碼會失敗的有意義測試，否則使用直接重現（命令和輸出）並附上其限制；檢查關於事實的宣稱（例如 CI 運行了什麼或基礎提交做了什麼）是否與其來源一致。然後在變更後程式碼的同類案例和呼叫者中搜尋更多此類發現，並對變更引入或暴露的每個實例套用最小修正；將不相關的既有問題列為後續事項。顯示測試通過（對於 STILL PASSES 發現，修正後的測試在防護措施撤銷時會失敗），並保留測試。偏好刪除或縮小程式碼，而不是新增鎖、快取、輔助函式或選項。
- 不同意：說明原因，並附上證據（測試或命令輸出）。僅從程式碼本身讀取的原因（例如「那不可能發生」）會使發現處於爭議狀態，而非被駁回或降級。
- Nit：對於差異新增、變更或移動的程式碼，當其修正會刪除程式碼、重複使用儲存庫或平台提供的內容，或使程式碼符合標準或周圍程式碼時套用，同時保持所有檢查通過且不為了長度而犧牲清晰度。用一行拒絕一個會新增路徑、案例、選項或相容性層的 nit，一個修正會改變使用者看到或取回結果的 nit，以及一個純粹是品味的 nit。
- 既有或範圍外：用一行拒絕。
永遠不要為了結束循環而同意。重新執行檢查和 git diff --shortstat <base>；移除審查者在測試之外新增且沒有被任何接受的發現需要的內容，保持最小且正確的修正，即使它會增加程式碼長度。
3. 下一輪
僅在仍有 blocker 或 should 未關閉，或行為程式碼已變更時才啟動下一輪。傳送標頭，並將其條件行替換為第 1 輪審查者的條件，審查者簡報不包含其「條件與草稿」行，所有先前的 ID 標記為已修正、有爭議（附上證據）或已拒絕（附上原因），以及自上一輪以來變更的程式碼片段。告訴審查者僅審查開放的 ID 和那些程式碼片段，為那些程式碼片段及其呼叫者所變更的行為撰寫新的條件，將每個先前的 ID 標記為已解決或仍開放，並為新發現編號（接續最後一個 ID）。當修正變更了行為、順序或所有權（例如將寫入操作移至等待之後）時，也要以相同的標頭啟動破壞者，告訴它僅為那些程式碼片段及其呼叫者撰寫和測試條件。
4. 完成
當沒有 blocker 或 should 未關閉，且測試、註解和格式之外的上一輪變更已通過整個循環時完成；APPROVE 會在其審查的程式碼上提早結束循環。在任何原因可被修正的 COULDN'T TEST 上啟動一個新的破壞者；將需要 E2E 的測試列給作者。如果 blocker 或 should 在第 3 輪後仍有爭議，則在 dispute-round.md 中執行爭議輪；該輪留下 INCONCLUSIVE 的發現會使循環以「完成但存在未解決的爭議」結束，而非核准。已拒絕的 nit 和既有發現保持拒絕。
最終訊息：運行的輪次、使用的模型、發現改變了什麼、每個標記的行為、測試、宣稱或潤飾、差異的大小（前後）、任何因為測試或輸出顯示其錯誤而被放棄的發現，以及每個被拒絕的 nit 或既有發現及其原因。加入破壞者測試了什麼、什麼失敗了、其中哪些是審查者也發現的，以及每個沒有被任何已提交測試覆蓋的條件。如果運行過爭議輪，提供每個結果。以淺白的文字列出每個未經確認的風險。如果 evals/results.jsonl 存在且審查者模型與其中的最後一個不同，請說明並提供運行回歸套件的建議（evals/README.md）。