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 是否真的是瓶頸因素
- 務實主義者問：在不損害信任的前提下，現在可以發佈什麼？
- 批評者關注支援負擔、期望負債與推廣混亂
其價值不在於達成一致同意的結論。其價值在於讓分歧變得清晰可見，然後再做選擇。