dknchris/multimodel-review

多模型審查（Codex + Claude）

獨立的審查員同時讀取同一份提示與同一個提交。此對話為唯一的修正者。請在 Opus 5.5 的高 effort 階段執行。

選項： $ARGUMENTS

設定

• 回合上限：Code 20 至 50（預設 20；選擇器的 Standard、Long 及 Max 分別為 20、35 與 50），Docs 2，Final 2，以及 2 至 6 個備用回合供證據回合使用（預設 2）。硬性停止：總和預設為 26。每個階段在其第一個清潔回合結束，因此上限僅為天花板。較舊的執行保留其各自的上限與限制。
• 審查員：預設為 Terra（gpt-6.1-terra）與 Opus（Opus 5.5）。可選：Fable（Fable 5.2）、Astra（gpt-6-astra）、Sol（gpt-6.1-sol）、Sonnet（Sonnet 5.5）、Haiku（Haiku 5.5）及 Luna（gpt-6-luna）。在此變更前啟動的執行會將其 Opus 審查員稱為 claude。
• 每個審查員的 effort 等級可在每次執行中設定：low、medium、high、xhigh 或 max。預設值：Codex 為 max，Claude 模型為 xhigh。
• 預設面板：terra:max:fast opus:xhigh code:20 spare:2。
• 每個 Codex 審查員可依據每次執行設定 Codex fast mode（優先層級）。它永遠不適用於 Claude 模型。
• 每個 Codex 執行在靜默 10 分鐘或總計 60 分鐘後停止。崩潰與空答案會獲得 1 次重新執行。答案絕不會因其格式而被重新執行。

以下的 helper 會強制執行這些限制，並將所有狀態保存在 ~/.claude/multimodel-review/ 目錄中（位於每個儲存庫之外），因為長時間的執行可能會被壓縮，而報告無法從記憶體重建。每次請完整寫出其路徑，並在子命令前加上 --repo <path>，如果 shell 不在儲存庫內：

python3 ~/.claude/skills/multimodel-review/scripts/mmr.py status

以下，mmr <command> 即為上述完整呼叫的簡寫。

啟動或恢復

1. 執行 mmr status。如果存在未完成的執行，則依據其顯示的內容及其列出的審查員繼續執行。如果顯示「Old location」，請在所有審查員完成後執行 mmr migrate，然後僅使用新路徑。
2. 在進行任何其他步驟之前選擇選項，以便擁有者能立即看到：
   • 如果上方的 Options 行僅為 pick（或 picker）：顯示選擇器（接下來的兩個項目符號）。
   • 否則，無論其是否為空：執行 mmr options "<options>" 且不顯示選擇器。空值表示使用預設值 terra:max:fast opus:xhigh code:20 spare:2。如果失敗，向擁有者顯示其單行錯誤並停止。每個審查員為 name[:effort][:fast]：Effort 預設為 Codex 使用 max，Claude 模型使用 xhigh，且除非提供 :fast，否則 Codex 模型以標準速度執行。code:<20-50> 與 spare:<2-6> 為可選（預設 20 與 2）。
   • 選擇器（如果 show_widget 可用）：使用模組 ["interactive"] 呼叫 read_me 一次。然後執行 mmr picker 並將其 Widget code: 行之後的所有內容，不做任何修改地作為 widget_code 傳遞，標題設為 multimodel_review_options。結束此輪並等待。其按鈕會發送「Start the review with .」，格式與輸入相同，例如 "terra:max:fast opus:xhigh code:20 spare:2"。對其執行 mmr options "<options>"。如果擁有者表示選擇器未載入，則執行 mmr picker --offline 並改為顯示該結果。
   • 終端機中的選擇器（無 show_widget）：一次 AskUserQuestion 呼叫，包含四個問題：審查員（多選：Terra、Opus、Fable、Astra；Sol、Sonnet、Haiku、Luna 透過「其他」）、Codex 模型的 fast mode（多選：Terra、Astra、Sol、無；Luna 透過「其他」）、effort（Codex max 及 Claude xhigh、全部 high、全部 medium）以及審查長度（Standard code:20、Long code:35、Max code:50）。忽略未選中審查員的 fast 選擇。將答案以輸入格式寫入，並執行 mmr options "<options>"。
3. 使用 Write 工具在暫存檔案中寫入 3-5 行的意圖：描述此變更應達成的目的及對象。從請求、此對話、PR 文字、提交或未提交的 diff 中取得。沒有它，審查員無法判斷「錯誤行為」。如果意圖不明確，向擁有者提出一個帶按鈕的問題。
4. 讀取 git status --short。所有未被忽略的內容都會被納入快照提交，因此請挑出與此變更無關的任何內容（例如雜亂的資料夾、筆記），並將其作為 --leave-out <path> 傳遞。如果你無法判斷，使用按鈕進行詢問。
5. 執行 mmr init --intent-file <file> --trailer "<attribution line>" --spec "<options>"，選項需與 mmr options 列印出的 Init: 行完全一致，並視需要加上 --base <base>（僅當擁有者指定基底時）及 --leave-out <path>。基底預設為遠端儲存庫的預設分支，審查會從 merge-base 開始。呼叫此技能即表示擁有者同意 init 的下列行為：
   • 在基底分支或分離 HEAD 上，它會先建立 multimodel-review/<time>，因此 WIP 提交永遠不會落入基底。
   • 未提交的工作會變成一個 WIP 快照提交，確保所有審查員讀取相同的提交。不會推送任何內容。
   • 退出碼 5 表示某些檔案看似機密、超過 20 MB 或為嵌入式儲存庫。尚未進行任何變更。使用按鈕詢問擁有者：排除它們（--leave-out）或包含它們（--allow-flagged）。
   • 「Nothing to review」表示沒有提交也沒有未提交的工作。詢問擁有者要審查哪些提交，然後傳遞 --base <commit>。
6. 如果 init 建立了分支或快照，請用一行告知擁有者。

一輪

1. 執行 mmr next --phase <code|docs|final|evidence>。它會建立提示檔案並列印其路徑、執行設定以及每個 Claude 審查員對應的一行 Claude Agent 資訊，包含其模型、effort 與答案檔案。退出碼 3 表示已達到上限：請前往 Done。
2. 在一則訊息中啟動 mmr status 列出的所有審查員：
   • 每個 Codex 審查員（terra、astra、sol、luna）：使用 run_in_background 執行 Bash：mmr codex --reviewer <name>。Helper 會以 -s read-only、關閉 apps、plugins 及 subagents、開啟 web 搜尋、使用自己的日誌以及時間限制來執行 Codex。絕對不要使用 workspace-write 或 --dangerously-bypass-approvals-and-sandbox、companion script 或 rescue subagent。
   • 每個 Codex 審查員對應一個 Monitor：mmr monitor --reviewer <name>，搭配 timeout_ms: 1800000。它每 60 秒檢查一次，並根據 PID 是否存在來判定「完成」，絕不依據輸出文字。
   • 每個 Claude 審查員（opus、fable、sonnet、haiku；較舊執行中的 claude）：一個全新的 Agent，搭配 subagent_type: "multimodel-reviewer"，model 與 effort 來自其 Claude Agent 行，以及提示「Review round file: 」。該 agent 擁有讀取與網頁工具，但沒有 shell 或編輯工具。如果該類型不可用，請使用 Plan，搭配相同 model 與 effort，並告訴它僅使用 Read、Grep 及網頁搜尋。
3. 處理 Monitor 事件：
   • FINISHED：無需任何動作。
   • FAILED：如同步驟 5 重新執行，並僅在重新執行也失敗時用一行告知擁有者。
   • QUIET：不算失敗，因為高 effort 可能會靜默思考數分鐘。無需採取動作；helper 會在審查員靜默 10 分鐘時停止它。
   • RE-ARM：重新啟動該 monitor。
4. 當 Claude Agent 返回時，將其最終訊息不經修改地寫入步驟 1 中的答案檔案，然後執行 mmr claude-result --reviewer <name> --seconds <duration_ms / 1000>。
5. 執行 mmr barrier。在通過之前不要編輯任何內容。如果結果為空或遺失，僅重新執行該審查員，使用相同的提交；此回合不重複計數。對於 Claude 審查員，產生一個全新的 Agent 並重複步驟 4。Helper 會拒絕第三次嘗試以及在停滯或逾時後的任何重新執行：此時執行 mmr stop --reason "<why>" 並前往 Done。例外：在格式規則被廢除前的執行可能顯示 malformed 但實際上有正確答案。請執行 mmr reread --reviewer <who>，它會重新讀取已儲存的答案，而不會啟動新的審查員執行。
6. 分類（請參閱 Fixer rules），並使用 Write 工具在回合資料夾中寫入 triage.tsv。
7. 修正已接受的發現，執行受影響的測試，並進行一次 WIP 提交。失敗的測試會阻止該回合，因此錯誤的修正無法進入下一個 delta。
8. 執行 mmr close --tests "<exact test command>"，或 --tests "none: docs only"。如果沒有任何發現被接受，則省略 --tests。遵循其列印的 Next: 行。

triage.tsv 是以 Tab 分隔的檔案，每個合併的發現佔用一行，僅在所有審查員都回答「NO BLOCKING ISSUES.」時才能省略：

reviewers	sev	loc	status	summary	note
terra,opus	P1	src/a.py:42	accepted	Retry drops the last item	src/a.py: Keep the last item on retry
terra	P1	src/b.py:9	rejected	Null token crashes	Token is non-null: src/auth.py:30 returns early

• status 可為 accepted、rejected 或 open。open 僅用於最後一個允許的回合，其中修正將無法得到審查。
• note 記錄了變更內容（accepted）、基於程式碼引用的拒絕原因（rejected）、或保留的原因（open）。Accepted 與 rejected 的備註會提供給下一個提示的修正清單與記錄。
• 將不符合階段的發現拒絕為「Out of phase」。
• 審查員可以任何格式回答，因此請自行閱讀每個答案。發現計數僅為最佳猜測。沒有 P0/P1/P2 標籤的答案視為一個發現：根據其提出的內容新增一行，或如果未提出任何內容則新增一行 rejected。

WIP 提交：訊息為 WIP multimodel-review round <N>，寫入檔案並透過 git commit -F 傳遞，加上此對話的歸屬行。絕不推送。

階段

1. Code： 第 1-2 輪審查相對於基礎的完整 diff。從第 3 輪起，僅審查 delta 加上修正清單。審查員可以開啟任何檔案作為上下文。在 delta 之外，他們僅回報 P0，除非 delta 導致失敗：此時發現以其真實嚴重性錨定到 delta 行。
2. Cleanup（僅修復者）： 在 Docs 之前執行，以便此處寫入的任何文字都能獲得 P2 審查。
   • Docs：僅更新因本次變更而過期的文件。進行修剪，而非擴充。
   • 測試：僅刪除除錯或階架測試，以及已移除程式碼的測試。保留回歸測試。
   • 執行完整的測試套件。如果失敗，請修正；如果無法透過小型修正解決，請停止並回報。
   • 提交，然後在執行資料夾中寫入 cleanup.md：每個刪除項目及其原因，以及確切的測試指令與結果。next --phase docs 若無此檔案則會拒絕。
3. Docs： 一輪 P2 的完整 diff 審查，修正，然後一輪 delta 審查。然後該階段結束；任何剩餘內容記錄為 open。
4. Final： 所有審查員參與的一輪完整 diff 審查，僅關注 P0/P1。如果接受了一個發現，請修正並執行一輪 delta 審查。如果仍然失敗，將其標記為 open；helper 會停止執行。

收斂

• 當修復者在該階段的嚴重性範圍內不接受任何發現時，該回合即為清潔回合。附帶程式碼引用原因而被拒絕的發現不會造成阻礙。
• 一個階段在其第一個清潔回合收斂。
• Code 收斂後的新證據（裝置或模擬器執行）：更新受影響的程式碼或文字一次，提交，然後執行 mmr next --phase evidence --note "<what the run showed and what changed>"，進行一輪 P0/P1/P2 的 delta 審查。僅當 P0/P1 被接受時 Code 才會重新開啟，而 close 會指出此情況。
• 遇到階段上限或硬性停止時：停止並回報剩餘內容。

修復者規則

• 合併並去重，保留每個提出發現的審查員，以便統計資料保持真實。根據程式碼驗證每個發現；拒絕無法驗證的發現並附帶一行原因。
• 僅根據程式碼本身判斷發現，無論是由誰提出。你本身也是 Claude 模型，因此請將 Claude 審查員的發現置於相同的標準。拒絕由 2 個以上審查員提出的發現或任何 P0 發現，需要特定的程式碼引用；報告會將這些列為有爭議項目供擁有者處理。
• 最小修正。不進行重構，不添加新功能。僅為真實的 P0/P1 錯誤添加回歸測試。
• 減少散文：優先刪除或縮小錯誤的句子，而非添加新的句子。新的註解最多一行。審查期間不添加新的文件章節。
• 如果 hook 拒絕某個路徑，停止並向擁有者回報。絕不透過 shell 複製或任何其他方式繞過它。
• 保持 shell 指令 dcg-safe：使用 Write 工具寫入檔案，指令中不要包含變數、glob 或指向變數路徑的重新導向。

完成

在收斂任何停止時執行此步驟。

1. 執行 mmr archive 以封存每個 Codex 對話，包含重新執行的部分。
2. 執行 mmr report。它會列印每個階段的回合數、審查員表格、開放項目、有爭議的發現、測試指令以及 squash 指令，並儲存 report.md。
3. 向擁有者回報，簡短且先給答案：每個階段的回合數、開放項目、確切的驗證指令與結果。
4. 針對每個審查員顯示簡單的內嵌視覺化：提出的發現數、接受數、拒絕數、獨有發現數、P0-P1 與 P2 的區分、清潔回合數、平均每回合分鐘數。用一行說出你選出的贏家。預設規則為最多被接受的獨有 P0/P1 發現，如果你推翻此規則應予說明，因為你也在評判你自己的模型。
5. 保留 WIP 提交，因為證據回合需要 delta 範圍。使用按鈕詢問是否立即 squash，並僅在獲得肯定答覆時從報告執行 squash。

修改此技能

此資料夾為公開儲存庫 github.com/dknchris/multimodel-review。每次變更都需提交，且僅在擁有者要求時才推送。選擇器的程式碼為 assets/picker.js：mmr picker 會在其最新提交被推送後才從 CDN 載入，在此之前會以內嵌方式發送（速度較慢）。每次變更後執行 python3 tests/test_mmr.py。