超级审查会 是做什麼的？
當用戶明確要求此 super-review-council 工作流程時，執行一個繁重的結構化多代理審查與修復循環。這主要是程式碼審查，但也支援明確凍結的非程式碼捆綁目標；它不是 Guardian 的 auto_review 核准路由，也不是內建的 codex review 命令。
對於頂層的明確執行，每個實質階段的預設形狀是一個四代理工作流程。四個代理檢查相同的凍結變更捆綁，四個代理協助分類發現，四個代理參與修復規劃/實作（可在此階段分離寫入所有權），四個代理在循環重複前驗證結果。主代理負責協調、分配所有權、整合結果，並對接受的修復做出最終決定。
在以下情況使用：
- 用戶明確說
super-review-council - 用戶明確說
Super Review Council - 用戶明確說
超级审查会 - 用戶明確要求這個繁重的多代理審查工作流程
- 一個載入的頂層協調器工作流程明確調用
super-review-council作為一個有界唯讀子傳遞
若僅有「review」、內建 codex review、Guardian auto_review、一般的編輯後自我審查、最終回應、提交、部署、CI 檢查、舊技能名稱提及，或對此技能檔案的一般維護，除非用戶要求為該工作執行此 super-review-council 工作流程，否則不要觸發此技能。
當被觸發時，在開始審查工作前，先聲明 super-review-council 技能已啟用並識別審查目標。
歸屬
此技能衍生自 MIT 授權的 openclaw/agent-skills 中的 skills/autoreview 技能。此處保留舊名稱 autoreview 僅用於 MIT 歸屬、輔助路徑/輸出/環境相容性以及巢狀工作流程禁止上下文。
四代理工作流程
當用戶說 super-review-council 或 超级审查会，且環境支援子代理時，每個階段使用四個並行代理。對於唯讀階段，偏好使用 explorer 風格的代理；對於實作階段，偏好使用 worker 風格的代理。唯讀審查、分類和修復規劃代理預設使用最小的階段範圍上下文：凍結目標身份、角色、允許的工具、禁止事項以及相關發現/證據。驗證代理也預設使用最小的階段範圍上下文，加上該階段任何明確核准的驗證命令、輸出路徑、寫入邊界和漂移稽核要求。舊的核准和執行指令僅可作為證據/來源傳遞，必須明確標記為僅限歷史上下文和非授權，且不能授予權限、核准降級或風險執行、授權寫入、測試、修復或巢狀工作流程，或覆蓋當前階段合約、允許的工具或禁止事項。只有當接受的修復需要時，工作者代理才能接收更豐富的上下文，且該更豐富的上下文受到相同的證據/來源僅限限制。
階段 0：目標預檢
在凍結捆綁或生成代理之前，識別審查目標：
- 如果用戶或協調器工作流程提供了明確的檔案、目錄或凍結的審查捆綁目標，則該明確目標優先於當前工作目錄的 git 偵測；將目標規範化，即使當前 shell 在 git 儲存庫內，也使用內容清單/雜湊身份
- 如果在 git 儲存庫內，記錄儲存庫根目錄、當前分支、骯髒/暫存/未追蹤狀態、上游/基礎或 PR 基礎（若可用），以及目標應為本地、分支或提交模式
- 如果不在 git 儲存庫內，僅當用戶提供了明確的檔案、目錄或可審查的捆綁目標時才繼續；規範化絕對路徑，拒絕缺失的目標，確定性地列舉目錄內容，若未提供則停止並要求提供儲存庫或明確目標
- 在階段 1 之前記錄不變的目標身份：提交模式為提交 SHA；分支模式為基礎/頭部參考加上差異雜湊；本地模式為本地差異/未追蹤清單雜湊；或非 git 檔案、目錄和捆綁的內容清單雜湊
- 在階段 1 之前凍結選定的捆綁/來源，並在首次面向用戶的更新中報告目標身份/雜湊
- 在分類、修復規劃和實作之前，重新計算選定的目標身份/雜湊，並與當前凍結的審查循環基準進行比較；初始時此基準是階段 0 的值；此重新計算僅為相等性檢查，不授權替換基準、重新生成清單、重新凍結或重新開始
- 在接受的階段 4 修復應用後，根據階段 4 前的基準、接受的寫入範圍、核准的輸出路徑和禁止路徑審計結果目標/工作區身份，然後將結果目標身份/雜湊記錄為階段 5 驗證基準和下一次審查循環的起始身份；未預期、超出範圍或禁止的漂移必須被隔離並揭露，且除非獲得明確核准，否則會阻止基準採用
- 如果任何目標身份比較因未經核准的外部變更而不同，則停止該階段，揭露預期和觀察到的身份/雜湊以及已知的變更路徑，並在重新凍結、重新開始或採用新基準之前要求用戶或協調器明確核准；在唯讀子模式中，將其作為阻塞物返回給協調器
原生子代理註冊表
協調器端的管理是主要控制，而非檔案系統鎖定。在每個原生子代理啟動前，協調器記錄階段和角色、聲明的工具、明確允許和禁止的操作、允許的讀/寫路徑、禁止路徑、沙盒和權限設定檔（若可用）、基準目標身份/雜湊，以及儲存庫/工作區狀態和清單，或足以發現目標外寫入的等效整個工作區變更基準。子代理返回後，將目標身份、允許/禁止路徑清單、儲存庫/工作區狀態以及工具/沙盒/權限元數據與該快照進行比較。隔離、不依賴並揭露任何目標不匹配、目標內或外的意外寫入、允許路徑漂移、禁止路徑觸及、工具漂移、權限或沙盒擴展、未說明的變更、未經授權的漂移或意外寫入，然後再繼續。檔案系統唯讀模式、不可變目錄和沙盒限制在有可用時是有用的補充防護或證據，但它們永遠不會取代協調器的提示合約、註冊表、快照/漂移稽核、隔離決策、整合審查和最終決策。
階段失敗處理
如果任何必需的代理、輔助引擎或工作者出錯、超時、違反階段合約、返回缺少的必填欄位或產生不可用的輸出，則該階段不完整。隔離或忽略可疑輸出，揭露失敗，並僅在同一階段合約和引擎/模型約束內重試或替換參與者，或停止以獲得明確的降級模式核准或阻塞物。絕不將缺失、陳舊或不可用的輸出計為完整的四代理覆蓋。
階段 1：四代理審查
給予每個審查者相同的凍結差異/捆綁和一個主要關注點：
- 正確性和回歸
- 安全性和信任邊界
- 測試、邊緣案例和失敗模式
- 可維護性、整合合約和用戶可見行為
審查約束：
- 每個審查引擎必須由協調器約束為唯讀審查者：啟動簡報必須命名允許的唯讀工具/操作，禁止寫入和變更命令，禁止巢狀審查/編排/代理創建，並將審查者綁定到凍結目標；僅在可用時使用沙盒、工具策略、輔助標誌、檔案系統唯讀控制或不變的捆綁作為可選的額外證據，但絕不要求它們；當協調器無法合理地禁止、觀察和稽核寫入或工具漂移時，不要使用引擎作為審查者
- 審查者不得編輯檔案、執行格式化工具、安裝套件、變更 git 狀態、推送、提交或執行寫入檔案的命令
- 審查者可在需要時檢查檔案、類型、文件、依賴合約和當前公開文件
- 對於差異、分支、提交或補丁審查，審查者必須僅報告由審查變更引入或暴露的可操作缺陷
- 當凍結目標是完整檔案、非程式碼捆綁、計劃、規格、文件或成品捆綁時，審查者報告該成品中相對於其既定目的和約束而非僅程式碼或差異來源問題的可操作缺陷
- 審查者不得提出大規模重寫、風格偏好或不相關的清理
階段 2：四代理分類
首先通過階段 0 的過時目標防護，然後要求四個代理獨立地將合併的發現分類為接受、拒絕、重複或需要更多證據。分類代理必須由協調器約束，使用與唯讀審查階段相同的無寫入、無變更命令、無 git 變更、無安裝、無格式化工具、無寫入輸出的測試、無巢狀審查/編排/代理創建合約；他們只能檢查凍結目標、合併發現、提供的證據和明確範圍內的相鄰上下文。主代理去重、拒絕推測性或低價值的發現、透過閱讀審查的程式碼路徑或成品加上範圍內的相鄰上下文來解決分歧，並記錄接受的修復集。
階段 3：四代理修復規劃
首先通過階段 0 的過時目標防護，然後要求四個唯讀規劃代理提出最小的修復計劃和所有權邊界。修復規劃代理必須由協調器約束，使用與唯讀審查階段相同的無寫入、無變更命令、無 git 變更、無安裝、無格式化工具、無巢狀審查/編排/代理創建合約；他們不得編輯檔案、寫入成品、應用補丁、執行寫入輸出的測試，不得調用 super-review-council，不得調用舊版 autoreview，不得調用 goal-orchestrator，不得調用內建 codex review、開啟審查面板或創建額外代理。他們只能檢查凍結目標和接受的發現以提出計劃。對於非程式碼目標，計劃應命名確切的成品章節或行級編輯，而非程式碼所有權邊界。偏好於正確的所有權邊界進行小修復。不要規劃大規模重構，除非它能明確修復錯誤類別。
階段 4：四代理實作
首先通過階段 0 的過時目標防護，然後僅在接受的修復可以分割成不相交的寫入範圍時使用四個工作者代理。為每個工作者分配檔案/模組的明確所有權。告訴每個工作者他們在程式碼庫中並不孤單，不得還原其他工作者所做的編輯，並且必須適應並行變更。工作者只能編輯分配的儲存庫本地檔案/模組，必須避免重疊寫入，不得格式化不相關的檔案，不得安裝套件或依賴項，不得推送、提交、重置、檢出/切換/恢復、還原、清理、暫存、變基、合併、刪除分支/標籤、移除未追蹤的檔案，或執行廣泛的破壞性檔案系統命令，如 rm -rf 或 find -delete。工作者不得調用 super-review-council、舊版 autoreview、goal-orchestrator、內建 codex review、審查面板、規劃面板或額外代理。工作者必須報告衝突，而不是透過還原用戶或同儕變更來解決衝突。主代理在接受工作者補丁之前進行審查。如果存在少於四個獨立的寫入範圍，則使用剩餘的代理進行唯讀驗證、測試規劃或實作審查，而不是強制進行重疊編輯。
階段 5：四代理驗證
首先針對當前驗證基準通過過時目標防護，然後在可能的情況下並行執行四個驗證代理：
- 焦點測試和命令輸出
- 差異稽核以檢查非預期變更
- 對接受的發現進行回歸/安全重檢
- 生成的成品、文件、快照或用戶可見輸出的一致性
驗證代理必須以明確的角色、基準身份/雜湊、允許的命令和工具、允許的讀/寫/輸出路徑、禁止的路徑和操作、有限的超時以及禁止安裝、格式化工具、git 變更、破壞性檔案系統命令、巢狀審查/編排和額外代理來啟動。測試或驗證命令只能寫入協調器核准的路徑（位於受保護的目標根目錄之外），除非接受的修復明確擁有這些輸出。可能變更審查目標的驗證必須序列化，或者針對較舊基準收集的任何並行驗證器結果必須失效並針對稽核後的寫入後基準重新執行。在每個驗證器或測試命令之後，協調器將目標身份/雜湊、允許和禁止路徑清單、儲存庫/工作區狀態以及命令成品與階段 5 基準進行比較。未預期的漂移、禁止寫入或未聲明的輸出必須在繼續之前被隔離並揭露。如果核准的驗證寫入合法地變更了審查目標，則在階段 6 重新執行審查之前，將稽核後的驗證後目標身份/雜湊記錄為下一次審查循環的起始身份。唯讀子模式不執行階段 5 命令。
階段 6：重複
在任何接受的修復變更了審查目標（包括程式碼、文件、技能文字、生成的輸出或其他捆綁內容）之後，針對更新的差異或成品重新執行四代理審查階段。持續進行，直到四代理審查/分類過程沒有留下任何已接受/可操作的發現，並且必需的測試或成品特定的證明通過。不要無限循環：預設情況下，在三個完整的審查/修復循環後停止，除非用戶明確要求繼續，並且在每個完整循環後使用過時目標防護快照，以防止在長時間運行的審查會話中發生未偵測到的目標漂移。
使用方法
向用戶的提示添加以下內容以啟用工作流程：
<super-review-council-trigger>審查目前工作目錄</super-review-council-trigger>
或在協調器工作流程內使用明確的 Bundle target.json 路徑：
<super-review-council-trigger target=""/><super-review-council-trigger target="*">
<super-review-council-pass>bundles/current-pass.json</super-review-council-pass>