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