Council 是做什麼的？
針對模糊決策召集四位顧問：
- 當前會話中的 Claude 聲音
- 一位懷疑論者子代理
- 一位務實主義者子代理
- 一位評論者子代理
這適用於不確定性下的決策制定，非程式碼審查、實作規劃或架構設計。
何時使用
在以下情況使用 Council：
- 一個決策存在多條合理路徑且沒有明顯贏家
- 你需要明確揭露權衡取捨
- 使用者要求第二意見、異議或多種觀點
- 對話錨定確實存在風險
- 「執行/不執行」的決定能受益於對抗性質詢
範例：
- 單一儲存庫 vs. 多儲存庫
- 現在發布 vs. 等待打磨
- 功能開關 vs. 全面發布
- 縮小範圍 vs. 保持策略廣度
何時不該使用
| 不要使用 Council 的情況 | 改用 |
|---|---|
| 驗證輸出是否正確 | santa-method |
| 將功能拆解為實作步驟 | planner |
| 設計系統架構 | architect |
| 審查程式碼中的錯誤或安全問題 | code-reviewer 或 santa-method |
| 直接的事實性問題 | 直接回答 |
| 明確的執行任務 | 直接執行任務 |
角色
| 聲音 | 視角 |
|---|---|
| 架構師 | 正確性、可維護性、長期影響 |
| 懷疑論者 | 挑戰前提、簡化、打破假設 |
| 務實主義者 | 發布速度、使用者影響、營運現實 |
| 評論者 | 邊界情況、下行風險、失敗模式 |
三個外部聲音應作為新的子代理啟動，且僅提供問題和相關上下文，而非完整的持續對話。這是反錨定機制。
工作流程
1. 提煉真正的問題
將決策縮減為一個明確的提示：
- 我們在決定什麼？
- 哪些限制條件重要？
- 什麼算成功？
如果問題模糊，在召集 Council 前先提出一個釐清問題。
2. 僅收集必要的上下文
如果決策與程式碼庫相關：
- 收集相關檔案、程式碼片段、議題文字或指標
- 保持精簡
- 僅包含做出決策所需的上下文
如果決策是策略性/一般性的：
- 除非它們會實質改變答案，否則跳過儲存庫片段
3. 先建立架構師的立場
在閱讀其他聲音之前，寫下：
- 你的初始立場
- 支持它的三個最強理由
- 你偏好的路徑中的主要風險
先執行此步驟，以便最終綜合結論不會單純鏡像外部聲音。
4. 並行啟動三個獨立聲音
每個子代理獲得：
- 決策問題
- 精簡的上下文（如有需要）
- 嚴格的角色定義
- 無不必要的對話歷史
提示範本：
你是四位聲音決策委員會中的 [角色]。
問題：
[決策問題]
上下文：
[僅相關的片段或限制條件]
請回應：
1. 立場 — 1-2 句話
2. 推理 — 3 個精簡要點
3. 風險 — 你建議中最大的風險
4. 意外 — 其他聲音可能忽略的一件事
直接明瞭。不模棱兩可。保持在 300 字以內。
角色重點：
- 懷疑論者：挑戰框架、質疑假設、提出最簡單的可信替代方案
- 務實主義者：以速度、簡潔性和實際執行為最佳化目標
- 評論者：揭露下行風險、邊界情況以及計劃可能失敗的原因
5. 在偏見護欄下進行綜合
你既是參與者也是綜合者，因此請遵循以下規則：
- 不要未經解釋就否定外部觀點
- 如果某個外部聲音改變了你的建議，請明確說明
- 始終包含最強烈的異議，即使你最終拒絕它
- 如果有兩個聲音與你的初始立場一致，將此視為一個真實信號
- 在給出最終裁決之前，保持原始立場的可見性
6. 呈現一個精簡的裁決
使用此輸出格式：
## Council：[簡短的決策標題]
**架構師：**[1-2 句立場]
[1 行說明原因]
**懷疑論者：**[1-2 句立場]
[1 行說明原因]
**務實主義者：**[1-2 句立場]
[1 行說明原因]
**評論者：**[1-2 句立場]
[1 行說明原因]
### 裁決
- **共識：**[他們在哪裡達成一致]
- **最強烈的異議：**[最重要的分歧]
- **前提檢查：**[懷疑論者是否挑戰了問題本身？]
- **建議：**[綜合後的路徑]
保持內容在手機螢幕上易於掃讀。
持續性規則
請勿將臨時筆記寫入 ~/.claude/notes 或此技能的其他陰影路徑。
如果 Council 實質改變了建議：
- 使用
knowledge-ops將教訓儲存在正確的持久化位置 - 如果結果屬於會話記憶，則使用
/save-session - 如果決策改變了正在進行的執行真相，則直接更新相關的 GitHub 或 Linear 議題
僅在決策改變了真實事物時才持久化它。
多輪跟進
預設為一輪。
如果使用者希望進行另一輪：
- 保持新問題的專注性
- 僅在必要時包含上一輪的裁決
- 盡可能保持懷疑論者的純淨，以保留反錨定價值
反模式
- 用 Council 進行程式碼審查
- 當任務只是實作工作時使用 Council
- 將整個對話記錄餵給子代理
- 在最終裁決中隱藏分歧
- 無論重要性如何，都將每個決策持久化為筆記
相關技能
santa-method— 對抗性驗證knowledge-ops— 正確持久化重要的決策增量search-first— 如有需要，在 Council 之前收集外部參考資料architecture-decision-records— 當決策成為長期系統政策時，將結果正式化
範例
問題：
我們應該現在就將 ECC 2.0 作為 alpha 版本發布，還是等到控制平面 UI 更加完整？
可能的 Council 輪廓：
- 架構師主張結構完整性，避免混亂的使用者體驗
- 懷疑論者質疑 UI 是否真的是關鍵阻礙因素
- 務實主義者詢問在不妨礙信任的前提下，現在可以發布什麼
- 評論者關注支援負擔、期望債務和發布混亂
價值不在於全體一致。價值在於在做出選擇之前，讓歧見變得清晰可見。