Claudex Loop 是做什麼的？
當前對話負責需求、規劃與協調。另一個提供者審查計畫。任一個提供者均可負責建置；未建置的提供者會在新的會話中檢查最終程式碼。
一次性確認角色
從您的執行環境中識別實際主機，而非從 PATH、已安裝的技能、模型名稱猜測或儲存庫判斷。兩個 CLI 可能都已安裝。在 Claude Code 中請使用 host=claude，在 Codex 中請使用 host=codex。如果無法取得執行環境的身份，請向使用者詢問一次他們使用的是哪個主機。
| 主機 | 需求與計畫 | 計畫審查者 | 預設建置者 | 最終檢查者 |
|---|---|---|---|---|
| Claude Code | 當前 Claude 會話 | Codex | Claude | 新的 Codex 會話 |
| Codex | 當前 Codex 會話 | Claude | Codex | 新的 Claude 會話 |
請遵循 builder=claude|codex。檢查者始終是另一個提供者。即使另一個提供者負責建置，主機仍保持協調者的角色。若要更換規劃者，請在另一個主機中開始對話；不要假設 CLI 審查者就是使用者的規劃對話。
模型選擇與提供者角色無關。請保留主機目前選定的模型。審查/建置 CLI 的呼叫會繼承其自身的配置，除非提供了 reviewer_model、builder_model 或 inspector_model；將這些參數對應到該次呼叫的執行器 --model 參數。同樣地，也請套用明確的 *_effort 參數。Fable 5.1 和 GPT-6 Astra 是適合的明確選擇，但非強制性固定選擇。主機 UI 中的模型並不能證明單獨的 CLI 將使用哪個模型。請分別回報要求的與實際觀察到的模型資訊；如 CLI 的預設值不明確，請誠實回報。絕不要在發生失敗時，默默地回退到另一個模型/提供者。
在啟動 CLI 之前，請先閱讀執行環境參考文件。請相對於此已安裝的 SKILL.md 來解析其執行器，而不要相對於正在被審查的專案。在啟動時請使用絕對路徑。
如果使用者提供了 codex_cli 或 claude_cli，請將所選提供者的可執行檔路徑對應到 --cli 參數。主機應用程式可能擁有比 PATH 上的 CLI 更新的可運作二進位檔；請驗證路徑和版本，但不要默默地變更全域安裝或配置。
可調參數
| 參數 | 預設值 | 說明 |
|---|---|---|
PLAN_FILE / plan | PLAN.md | 全程使用的計畫路徑，包含建置交接 |
LOG_FILE / log | PLAN-REVIEW-LOG.md | 僅能附加的記錄檔 |
rounds / MAX_ROUNDS | 5 | 最大完成計畫-審查輪數 |
builder | 主機 | 執行計畫的提供者 |
research | 與任務成比例 | none、web 或明確選擇加入的 deep |
mode | full | full 包含探索/訪談；review 從現有計畫開始 |
inspect | on | 僅在使用者明確選擇退出時設為 off；並記錄此決定 |
MAX_FIX_ROUNDS | 2 | 在回報或接手前，有限度的建置-修正嘗試次數 |
MAX_INSPECTION_ROUNDS | 2 | 初始檢查加上修正後一次 |
在開始前，請回報角色、路徑、輪數限制、要求的模型以及檢查的選擇退出狀態。請保留現有的授權：請求規劃並不等於授權建置；請求規劃並實作才表示授權。在尋求任何剩餘的簽核之前，請先完成已獲授權的準備工作。
階段 0 — 探索
對於現有專案，請檢查相關的程式碼、相依性、共享狀態的呼叫者與撰寫者。閱讀現有的 CONTEXT.md / CONTEXT-MAP.md 以及相關的 ADR。對於全新專案，請在研究時探究既有技術、合理的技術堆疊以及具體的失敗模式。請尊重明確的研究深度設定。深度多重代理研究需要明確選擇加入並且要有可用的工具；否則請使用支援的定向研究，並回報此限制。不需要依賴專有的 Workflow 工具或硬編碼一個研究代理模型。
透過主機的可用目錄以及另一個提供者記錄的技能位置（如果可以存取）來探索相關技能。僅記錄相關的、提議的相依性。不要假設主機的 MCP、瀏覽器、憑證或技能可以轉移到另一個 CLI。在依賴之前，請先驗證所需的建置能力。
提供一份包含來源路徑或研究連結的假設清單。將重大的不確定性問題批次提出，請使用者更正。當使用者已授權工作時，請自行解決例行的、可逆的選擇；沉默不代表同意需要批准的行動。
階段 1 — 確定需求
維護一份簡短的可見決策地圖。僅詢問那些未解決的、會改變結果的決策。對於每個重要的問題，請給出建議、說明其重要性，以及猜錯的代價。將獨立的問題批次提出；依賴性問題則依序提出。如果程式碼可以回答，請檢查程式碼而非提問。當決策清單過長可能會拖慢使用者速度時，提供「接受所有剩餘建議」的選項。
尊重現有的詞彙表定義；解決模糊的領域語言。使用 CONTEXT-FORMAT.md 以惰性方式僅維護詞彙表相關的上下文。只有對於難以逆轉、不明顯的權衡取捨，才使用 ADR-FORMAT.md 記錄一個 ADR。
撰寫已決定的 PLAN_FILE，內容包含：
- 目標與可觀察的驗收標準。
- 具體方法、關鍵決策、權衡取捨與非目標。
- 已確認的假設（附帶來源）與剩餘風險。
- 每個提供者相關的工具鏈需求（如果有的話）。
- 驗證方式：確切的證明命令、預期結果，以及必要時的手動/視覺檢查。
盡可能從儲存庫推導出證明命令。僅在成功標準仍不明確時提問。以角色、模型請求、範圍、授權和輪數限制開始建立僅能附加的 LOG_FILE。將執行診斷資訊保留在工作目錄之外。
在 mode=review 模式下，載入提供的計畫，僅在使用者需要時填補重要的空白，然後直接進入審查階段；不要重新開始需求訪談。
階段 2 — 獨立計畫審查
使用共享的執行器以 review 模式執行，並帶入實際的 --host、已解析的 --plan 以及可選的模型／努力程度。第一輪創建一個會話。後續輪次則使用 --resume <previous-successful-result.json>，搭配相同的提供者／模型／努力程度，以及一個由主機撰寫的、包含處理意見的 --feedback 檔案。絕對不要使用猜測的會話 ID、--last，或將建置會話當作審查者。
每個成功的回應都包含一個裁決、有證據支持的發現、實際的覆蓋範圍以及限制。請將整個回應和執行器結果路徑保留在 LOG_FILE 中。
- 已核准 (APPROVED)： 沒有未解決的重大缺陷。核准與確切的計畫路徑和 SHA256 相關聯。請提出剩餘的低優先級建議和限制；零發現是有效的，但這並不能證明完全正確。
- 需修改 (REVISE)： 主機應對每個發現進行仲裁。實施有正當理由的計畫變更；對於不支持的建議，請附上理由予以駁回。記錄處置意見，並將修改後的計畫發送給同一位審查者。避免在沒有新證據的情況下，重新討論已經解決的觀點。
- 被阻擋 (BLOCKED) / 程序失敗 / 結果異常： 絕對不要將此計為核准。請說明實際缺失的證據或操作上的失敗。不要將剩餘的輪次浪費在盲目重試上，也不要默默切換提供者。
在達到 MAX_ROUNDS 時停止。應呈現未解決的發現以及主機的立場，而非製造出達成共識的假象。變更過的計畫需要再次進行審查。在進行建置前，請對最終計畫執行一次核准檢查。如果使用者明確選擇在未經獨立核准的情況下繼續，請記錄該覆寫，並使用獨立的未經審查規格路徑；絕對不要將其標記為已核准。
階段 3 — 建置與檢查
呈現已審查的計畫、改進之處以及剩餘的限制。如果實作尚未獲得授權，請就此最終決定進行詢問。使用選定的建置者，預設為主機。請閱讀建置參考文件。
主機可以使用其正常工具直接實作。對於不同的建置者，請使用共享執行器的 build 模式。兩種路徑都必須捕捉建置前的提交、保留使用者無關的工作成果，並攜帶相同的已決議計畫與驗證合約。
執行雙方同意的證明檢查，檢查所有已變更的檔案，並透過另一個提供者在一個全新的 inspect 會話中審查結果。請提供建置前的提交以及建置者的身份。在接受修正後的重新檢查也應使用全新的會話。記錄發現與處置意見；在修正後，重新執行受影響的證明檢查。
如果協調者接手撰寫程式碼，它就成為了建置者。需要對其變更進行一次全新的其他提供者檢查；絕對不要將先前的檢查描述為涵蓋了後續的編輯。如果兩個提供者都貢獻了程式碼，請記錄作者身份，並讓每個提供者檢查對方的變更；不要聲稱任何模型獨立審查了它自己撰寫的程式碼。如果檢查預算已用盡，請明確呈現剩餘的發現和未經審查的編輯，以供使用者決定。
呈現最終的差異 (diff)、證明結果、檢查覆蓋率、未解決的發現、偏差以及使用的輪數。尊重現有的提交/推送授權；否則請將具體的差異準備好以供簽核。僅執行循環並不意味著可以對外發布。