council

用途

Council 用于在模糊决策、权衡取舍和 go/no-go 判断场景下召集一个“四声部议事会”。它面向的是决策本身，而不是代码审查、实现规划或架构设计。

主要能力

议事会由四个声音组成：

• 上下文中的 Claude 主声（Architect）
• 一个 Skeptic 子代理
• 一个 Pragmatist 子代理
• 一个 Critic 子代理

各角色的视角：

• Architect：正确性、可维护性、长期影响
• Skeptic：挑战前提、简化、打破假设
• Pragmatist：交付速度、用户影响、运营现实
• Critic：边界情况、下行风险、失败模式

三个外部声音应作为全新子代理启动，只接收问题与相关上下文，而非完整的进行中对话。这就是反锚定机制。

何时使用

在以下情况使用 council：

• 一个决策有多条可信路径且没有明显赢家
• 需要显式呈现权衡
• 用户要求第二意见、异议或多重视角
• 对话锚定是真实风险
• go / no-go 判断能从对抗性挑战中获益

示例：

• monorepo vs polyrepo
• 现在发布 vs 为打磨而推迟
• 功能开关 vs 全量发布
• 简化范围 vs 保持战略广度

何时不使用

• 验证输出是否正确：改用 santa-method
• 将功能拆解为实现步骤：改用 planner
• 设计系统架构：改用 architect
• 审查代码中的 bug 或安全问题：改用 code-reviewer 或 santa-method
• 直接的事实性问题：直接回答
• 显而易见的执行任务：直接执行任务

使用方式

工作流

1. 提取真正的问题

将决策简化为一个明确的提示：

• 我们在决定什么？
• 哪些约束重要？
• 什么算作成功？

如果问题模糊，在召集议事会前先问一个澄清问题。

1. 只收集必要的上下文

如果决策与代码库相关：

• 收集相关文件、片段、issue 文本或指标
• 保持紧凑
• 只包含做出决策所需的上下文

如果决策是战略/通用性的：

• 除非仓库片段会实质性改变答案，否则跳过

1. 先形成 Architect 立场

在阅读其他声音之前，先写下：

• 你的初始立场
• 支持它的三个最强理由
• 你偏好路径中的主要风险

先做这一步，这样综合时不会只是镜像外部声音。

1. 并行启动三个独立声音

每个子代理获得：

• 决策问题
• 紧凑上下文（如需要）
• 严格角色
• 不必要的对话历史

提示形态：

You are the [ROLE] on a four-voice decision council.

Question: [decision question]

Context: [only the relevant snippets or constraints]

Respond with:

1. Position — 1-2 sentences
2. Reasoning — 3 concise bullets
3. Risk — biggest risk in your recommendation
4. Surprise — one thing the other voices may miss

Be direct. No hedging. Keep it under 300 words.

角色侧重：

• Skeptic：挑战框架、质疑假设、提出最简单的可信替代方案
• Pragmatist：为速度、简单性和现实执行优化
• Critic：呈现下行风险、边界情况以及计划可能失败的原因

1. 带偏见护栏进行综合

你既是参与者也是综合者，因此使用这些规则：

• 不要在没有解释原因的情况下驳回外部观点
• 如果外部声音改变了你的建议，明确说明
• 始终包含最强的异议，即使你拒绝它
• 如果两个声音与你的初始立场相悖，将其视为真实信号
• 在裁决前保持原始立场可见

1. 呈现紧凑裁决

使用此输出形态：

Council: [short decision title]

Architect: [1-2 sentence position] [1 line on why]

Skeptic: [1-2 sentence position] [1 line on why]

Pragmatist: [1-2 sentence position] [1 line on why]

Critic: [1-2 sentence position] [1 line on why]

Verdict

• Consensus: [where they align]
• Strongest dissent: [most important disagreement]
• Premise check: [did the Skeptic challenge the question itself?]
• Recommendation: [the synthesized path]

保持在手机屏幕上可快速浏览。

持久化规则

不要从此技能向 ~/.claude/notes 或其他影子路径写临时笔记。

如果议事会实质性改变了建议：

• 使用 knowledge-ops 将经验存储到正确的持久位置
• 或使用 /save-session（如果结果属于会话记忆）
• 或直接更新相关的 GitHub / Linear issue（如果决策改变了活跃执行事实）

只在决策改变了真实事物时才持久化。

多轮跟进

默认是一轮。

如果用户想要另一轮：

• 保持新问题聚焦
• 仅在必要时包含之前的裁决
• 尽可能保持 Skeptic 干净，以保留反锚定价值

适用场景

• 多条可信路径且无明显赢家的决策
• 需要显式呈现权衡取舍
• 用户要求第二意见、异议或多重视角
• 存在对话锚定风险
• go / no-go 判断需要对抗性挑战

限制与反模式

反模式：

• 用 council 做代码审查
• 在任务只是实现工作时使用 council
• 向子代理喂入整个对话记录
• 在最终裁决中隐藏分歧
• 无论重要性如何都把每个决策持久化为笔记

相关技能：

• santa-method — 对抗性验证
• knowledge-ops — 正确持久化持久的决策增量
• search-first — 如需要，在议事会前收集外部参考材料
• architecture-decision-records — 当决策成为长期系统策略时将其形式化

示例

问题：

Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?

可能的议事会形态：

• Architect 推动结构完整性并避免混乱的表面
• Skeptic 质疑 UI 是否真的是门控因素
• Pragmatist 询问现在可以发布什么而不损害信任
• Critic 关注支持负担、期望债务和发布混乱

价值不在于一致。价值在于在选择之前让分歧变得清晰可读。