Codeck 是做什麼的？
將 Codeck 作為執行橋樑，而當前的程式碼代理則擔任主持人與協調者。請將主產品的模型選擇器視為不相關的事項：切換活躍的聊天模型與透過 Codeck 諮詢外部模型並非同一回事。
選擇工作流程
- 使用單次
ask向指定執行器取得唯讀的第二意見。 - 使用
council向兩個或更多來自真正不同模型提供者的執行器取得獨立意見。 - 僅在使用者明確要求外部執行器實作變更時，才使用
delegate。 - 在路由不確定時，先使用
pick再使用auto。
切勿將一個模型扮演多個角色描述為多模型共識。請將其標示為 single-model-multi-role。
事前檢查
- 執行
command -v codeck。 - 如果無法取得，請停止並說明需要 Codeck CLI。未經使用者授權，請勿自行安裝。
- 在目標專案中執行
codeck doctor與codeck list。 - 僅使用健康且已設定完畢的執行器，其宣告的模式與權限需符合任務需求。
- 如果專案尚未初始化，請先詢問使用者後再執行
codeck init，因為它會建立.codeck/檔案。
在設定執行器、為區域網路選擇提供者，或解釋為何請求的模型不可用時，請參閱 references/providers.md。
準備交接
針對非瑣碎的工作，撰寫一份精簡的 Markdown 摘要。內容需包含目標、限制條件、問題、驗收標準，以及外部模型所需的檔案。建議優先使用檔案附件，而非將冗長的摘要嵌入指令中：
codeck ask <executor> "Read the attached task brief and return an evidence-backed review." -f task.md
請勿包含機密、憑證、不相關的原始碼檔案或使用者私人資料。告知使用者任務內容即將離開主產品並送往其他提供者。
關於輸入摘要與最終成品架構，請參閱 references/artifacts.md。
執行多模型委員會
- 保持當前程式碼代理作為主持人。
- 選擇至少兩個由不同提供者支援的健康執行器。優先考慮能力匹配度與可用性，而非品牌順序。
- 提供給每位第一輪專家相同的事實與核心問題，以及一個獨特的審查角色。
- 在將一位專家的答案透露給另一位之前，先獨立收集第一輪的答案。
- 提取主張、證據、假設、風險與分歧點。
- 僅針對實質分歧提出追問。將相關的先前輸出附加為 Markdown 檔案。
- 當滿足驗收標準、剩餘分歧已明確記錄，或達到設定的回合限制時，停止流程。
- 如果成品寫入在範圍內，則產出
report.md、summary.md與decisions.json；否則在回應中回傳相同的結構。
當所有專家應接收相同提示時，請使用 codeck compare <executor-a>,<executor-b> "<task>" -f task.md。當角色或追問問題不同時，請使用個別的 codeck ask 呼叫。除非觀察到的執行確實是並行執行，否則請勿聲稱並行執行。
關於角色提示、分歧處理與收斂規則，請參閱 references/moderation.md。
安全路由
- 預設使用
ask，其目的是唯讀諮詢。 - 除非使用者授權外部實作，否則請勿加上
-y或呼叫delegate。 - 除非底層 CLI 也強制執行沙箱，否則權限欄位僅視為宣告。
- 請勿默默替換提供者。請回報請求的執行器、實際的執行器/提供者以及回退原因。
- 請勿硬編碼當前模型 ID。應從本地設定中發現或讀取，因為提供者模型名稱會變更。
- 如果可用的不同提供者少於兩個，則僅能進行單一模型諮詢，並說明此限制。
- 保留原始的外部輸出或 Codeck 執行 ID，以便合成結果可被稽核。
回傳結果
以主持人的結論開頭。接著說明：
- 實際執行的執行器與底層提供者為何；
- 它們在哪裡達成共識、哪裡存在分歧；
- 支持決策的證據為何；
- 未解決的風險與建議的驗證方式；
- 任何回退、失敗、估計使用量或區域限制。
保持簡短摘要以決策為導向。將詳細的推理與來源歸因保留在完整報告中。