council

council 技能概覽

council 是一個 decision-support 技能，適合在有多種合理答案、而你在拍板前需要先有結構化分歧的時刻使用。它特別適合產品決策、範疇取捨、上線策略，以及那種「要發還是先按住？」的問題；在這類情境下，單一回覆式提示詞很容易只偏向某一種觀點。若你希望 council 幫你做選擇，而不只是發想，它會是很合適的工具。

council 技能是做什麼的

Decision Support 模式下的 council 會圍繞同一個問題，建立四個聲音：一個核心 Claude 觀點，再加上 Skeptic、Pragmatist 和 Critic 的視角。這種組合能快速找出隱含前提、失敗模式，以及營運上的取捨。它的價值不在於產出更多內容，而是在於讓討論出現更有品質的摩擦。

誰應該安裝 council 技能

如果你經常在產品、工程、營運或策略上做模糊決策，而且需要一套可重複的方式來壓測選項，建議安裝 council。當利害關係人意見不一致、判斷錯誤的代價不低，或你想要比一般「優缺點清單」更站得住腳的建議時，它尤其有用。

什麼情況下 council 技能特別適合

當問題至少有兩條可信路線、決策高度依賴情境，或你需要帶著異議一起做出 go/no-go 判斷時，使用 council 最有價值。相較之下，它較不適合用在單純執行、除錯、架構規劃，或答案其實已經很明確、你只需要行動的任務。

如何使用 council 技能

安裝 council 技能

依照 repository 的安裝流程，把 council 加進你的 Claude Code skills 集合中，之後在需要結構化決策支援，而不是一般完成式回覆時再呼叫它。就這個 repo 來說，實際安裝參考位置是 affaan-m/everything-claude-code 裡的 skills/council 路徑。安裝完成後，這個 skill 應該會在你處理 prompts 和任務的同一個環境中，以 council 的名稱可用。

把 prompt 寫成技能能辯論的決策題

council 最好的使用方式，是先給它一個決策陳述，而不是一個模糊主題。你要提供選項、利害關係，以及最重要的限制條件。好的輸入像是：「我們應該現在就上 feature flags，還是等更完整的 rollout plan？重點是在維持上市時程的同時，把營運風險降到最低。」不夠好的輸入則像是：「對 feature flags 有什麼看法？」前者能讓 council 評估取捨，後者通常只會得到泛泛而談的建議。

先讀對的檔案

先從 SKILL.md 看起，理解這個決策邊界；接著再看定義何時該用 council、何時不該用、角色結構，以及工作流程的段落。這些內容最能影響 council 是否真的是合適工具。如果你要把它改成自己的 repository 版本，也要一起閱讀周邊的 skill 慣例，讓輸出風格能符合你的環境。

用流程，不要只問一次

一個好的 council 流程是：先定義決策、列出 2 到 4 個候選方案、說明限制條件、跑 council，再要求帶理由與風險的建議。務必把真實的營運條件也帶進來，例如截止時間、使用者影響、可逆性，以及什麼情況會讓這個決策失敗。這樣 Pragmatist 和 Critic 才有足夠的上下文提出真正有價值的觀點。

council 技能常見問題

council 技能是拿來發想還是做決策？

它是拿來做決策的。council 的設計目標，是把分歧明確化來解決模糊性，而不是無限產生點子。如果你只需要原始發想，通常一個更簡單的 prompt 就夠了。當你需要先把選項壓測過，再得到建議時，council 才最有用。

council 跟一般 prompt 有什麼不同？

一般 prompt 常常會把多個觀點收斂成一個答案。council 則強迫不同視角分開說話，這在風險是過早共識時特別有幫助。實務上，這代表它能更好地處理取捨、減少隱藏前提，並更清楚指出可能出錯的地方。

council 技能適合初學者嗎？

可以，只要使用者能清楚說出決策題目。初學者在提供明確選擇、簡短背景，以及最在意的限制條件時，通常能得到最大的價值。如果 prompt 很模糊，這個 skill 仍然能運作，但討論的決斷力會比較弱。

什麼時候不該用 council？

不要把 council 用在簡單事實問題、顯而易見的任務、code review、security review，或逐步實作規劃上。repository 也明確把這些情境導向其他 skills 或直接執行。Decision Support 模式下的 council，只有在判斷比機械性操作更難時才最強。

如何改進 council 技能

提供更好的決策輸入

最有影響力的改進，是把上下文寫得更精準。請明確說出選項、決策期限、主要風險，以及成功標準。例如：「在 A 和 B 之間二選一；A 比較快，B 比較安全；期限是週五；成功的定義是不用回滾，且客服負擔最低。」這比用抽象方式描述問題強很多。

針對真正的限制條件要求異議

如果你在意成本、可逆性、使用者體驗，或營運負載，就要一開始講清楚。council 最擅長的是知道要攻擊哪個點；如果沒有這些資訊，Skeptic 和 Critic 可能會挑錯前提，最後建議也會比較難落地。

第一次跑完後再迭代

如果第一次的 council 回覆太籠統，就用更窄的問題或不同的限制條件再跑一次，例如「以速度最佳化」、「以安全性最佳化」，或「以長期維護性最佳化」。這通常比重複問同一題更有用。對 council 技能來說，更好的迭代代表更好的 framing，而不只是更多字。