執行一個模型多元的子代理委員會，從多個角度調查同一個問題，比較發現，並產出最終建議。每當使用者要求委員會、第二意見、多個代理/模型評估同一問題、平行調查、紅隊/藍隊比較，或協助在競爭的技術方案之間做決定時，請使用此技能。
Council
使用此技能協調多個子代理調查同一問題，首先使用不同模型，其次分配不同觀點，然後將他們的報告整合成一個建議。
此技能最適合判斷密集型任務：架構取捨、有風險的錯誤修正、程式碼審查紅隊演練、上線決策、事件分析，以及「這個替代方案值得追求嗎？」這類問題。
工作流程
1. 定義委員會問題
用一句話說明委員會應回答的決策。識別：
- 正在審查的競爭選項或假設；
- 要檢查的程式碼庫、分支、PR、議題、設計或成品；
- 代理應為唯讀還是可以修改程式碼；
- 最終決策標準，例如正確性、風險、實作成本、可測試性、上線安全性或產品行為。
如果使用者的請求不明確，只詢問最低限度的釐清。否則選擇合理的預設值並繼續。
2. 選擇委員會成員
優先考慮模型多樣性。委員會不應預設使用同一模型的三個代理搭配不同角度；僅在可用的啟動配置無法提供多個有用模型，或使用者明確要求單一模型時才這麼做。如果無法實現模型多樣性，簡短說明後再退而求其次僅使用角度多樣性。
三個成員委員會的建議預設名單：
- Opus 4.7 或最強的可用 Claude/Opus 推理模型：架構、正確性與邊界案例分析。
- GPT 5.5 或最強的可用 GPT/Codex 模型：以實作為基礎的審查、可行性與測試策略。
- 開源模型如 Kimi 2.6、GLM 5.1 或最強的可用 OSS/本地模型：反向批判、隱藏假設與替代框架。
如果這些確切模型在當前 harness 中不可用，則使用該系列中最接近的可用模型並註明替代。如果沒有可用的開源模型，則盡可能使用第三個不同的前沿模型；否則使用最強的剩餘模型，並刻意賦予其對抗性或專業角度。
為每個成員分配模型和角度。避免角度與模型重複；例如，不要要求所有成員進行一般的架構審查。有用的角度組合包括：
- 架構師/正確性審查者；
- 實作/可測試性審查者；
- 紅隊、安全性、效能或產品風險審查者；
- 反向「反對顯而易見的解決方案」審查者。
當不同子代理需要不同模型時，請在單獨的 run_agents 呼叫中啟動它們，因為模型選擇是 run 層級的。如果請求的模型解析結果與預期不同，請將解析後的啟動設定視為權威，除非它們使任務不可行。
使用非預設 harness 時，請選擇該 harness 的有效模型 ID。例如，Claude Code 可能提供 claude-opus-4-7，Codex 可能提供 gpt-5.5，而開源模型則取決於當前配置的本地或遠端提供者。不要發明不支援的模型 ID；如果所需模型不可用，請選擇最接近的支援替代品，並保留預期的角度多樣性。
對於唯讀調查，將所有子代理保留在同一個 checkout 中，並明確告訴他們不要編輯檔案。對於實作或原型委員會，為每個本地子代理提供自己的 git worktree 和分支，以避免衝突。
3. 啟動前簡報
對於明確編排的請求，簡短告知使用者你計劃啟動哪些委員會成員以及每個成員將調查什麼，然後在呼叫 run_agents 之前等待批准。
共享簡報應包含：
- 儲存庫路徑或成品位置；
- 當前分支或基礎上下文；
- 要回答的確切問題；
- 相關背景和已知問題；
- 需要檢查的檔案/符號（如果已知）；
- 限制條件，特別是唯讀/不提交/不開 PR；
- 預期的報告格式。
保持啟動提示簡短，使任務標題保持緊湊。如果長簡報導致啟動驗證問題，請使用最小提示啟動，然後立即將完整簡報發送給子代理。
4. 要求結構化報告
要求每個委員會成員回傳：
- 檢查的確切檔案路徑、符號、文件或證據；
- 當前行為或當前實作；
- 正在評估的替代方案；
- 正確性風險和邊界情況；
- 實作和測試成本；
- 建議：保留當前方法、追求替代方案或使用混合方案；
- 信心水準和未知事項。
鼓勵獨立性。除非你刻意進行第二輪批判，否則不要將一個子代理的發現分享給其他子代理。
5. 收集報告
在完成訊息到達時閱讀它們。不要僅依賴生命週期成功；有用的輸出在子代理的報告中。
如果報告缺少關鍵證據或做出未經證實的主張，請向同一個子代理發送有針對性的後續問題，而不是啟動替代代理。重複使用現有子代理進行後續問題，因為它們保留上下文。
6. 綜合建議
根據證據品質比較報告，而不是按票數。在最終答案中：
- 以建議開頭；
- 指出共識和分歧；
- 解釋為什麼推薦的選項在決策標準上勝出；
- 明確回應使用者提出的問題；
- 包含相關檔案路徑/符號，但不要讓答案過於冗長；
- 區分「立即執行」和可選的未來強化；
- 提及信心水準和重大未知事項。
偏好簡潔的決策備忘錄而非逐字稿摘要。使用者需要提煉後的建議，而不是每個中間細節。
最終答案範本
除非任務要求不同格式，否則使用此結構：
## 建議
[一兩句說明決策。]
## 原因
- [關鍵原因 1]
- [關鍵原因 2]
- [關鍵原因 3]
## 取捨與風險
- [風險或注意事項]
- [測試/上線影響]
## 最終決定
[具體下一步：合併當前變更、追求替代方案、混合方案、執行測試等。]
實用備註
- 如果委員會是唯讀的，告訴子代理不要修改檔案、提交、建立分支或開 PR。
- 如果委員會涉及 PR 或分支工作，請遵循儲存庫的正常版本控制規則，並對平行本地編輯使用隔離的 worktree。
- 如果委員會是關於程式碼審查意見，僅在底層問題實際解決後才將審查意見標記為已解決。
- 除非使用者明確要求，否則不要在面向使用者的摘要中暴露內部子代理 ID。
