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