council

议会

为模糊决策召集四位顾问：

• 上下文中的 Claude 声音
• 怀疑论者子代理
• 实用主义者子代理
• 批评者子代理

这适用于模糊情境下的决策，而非代码审查、实施规划或架构设计。

何时使用

在以下情况下使用议会：

• 决策有多条可信路径且无明显胜出者
• 需要明确权衡取舍
• 用户要求第二意见、异议或多角度观点
• 对话锚定效应风险较高
• 放行/叫停决策需要对抗性挑战

示例：

• 单体仓库 vs 多仓库
• 立即发布 vs 打磨后发布
• 功能开关 vs 全量发布
• 简化范围 vs 保持战略广度

何时不使用

代替议会	使用
验证输出是否正确	santa-method
将功能拆解为实施步骤	planner
设计系统架构	architect
审查代码中的错误或安全	code-reviewer 或 santa-method
直接的事实性问题	直接回答
明确的执行任务	直接执行

角色

声音	视角
架构师	正确性、可维护性、长期影响
怀疑论者	前提挑战、简化、假设打破
实用主义者	发布速度、用户影响、运营现实
批评者	边缘情况、下行风险、失败模式

三个外部声音应作为全新子代理启动，仅包含问题和相关上下文，而非完整的持续对话。这是反锚定机制。

工作流程

1. 提取真正的问题

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

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

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

2. 仅收集必要的上下文

如果决策与代码库相关：

• 收集相关文件、代码片段、问题文本或指标
• 保持紧凑
• 仅包含决策所需的上下文

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

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

3. 先形成架构师立场

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

• 你的初始立场
• 支持该立场的三个最强理由
• 你首选路径的主要风险

先做这一步，以便综合结果不会简单地镜像外部声音。

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

每个子代理获得：

• 决策问题
• 紧凑上下文（如果需要）
• 严格角色
• 无多余对话历史

提示模板：

你是四声决策议会的 [角色]。

问题：
[决策问题]

上下文：
[仅相关代码片段或约束]

请回复：
1. 立场 — 1-2 句话
2. 推理 — 3 个简洁要点
3. 风险 — 你建议中的最大风险
4. 意外 — 其他声音可能忽略的一点

直接了当。不要含糊。控制在 300 字以内。

角色重点：

• 怀疑论者：挑战框架、质疑假设、提出最简单的可信替代方案
• 实用主义者：优化速度、简单性和实际执行
• 批评者：揭示下行风险、边缘情况以及计划可能失败的原因

5. 带偏见护栏的综合

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

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

6. 呈现紧凑裁决

使用以下输出格式：

## 议会：[简短决策标题]

**架构师：** [1-2 句话立场]
[1 行原因]

**怀疑论者：** [1-2 句话立场]
[1 行原因]

**实用主义者：** [1-2 句话立场]
[1 行原因]

**批评者：** [1-2 句话立场]
[1 行原因]

### 裁决
- **共识：** [他们一致的地方]
- **最强烈异议：** [最重要的分歧]
- **前提检查：** [怀疑论者是否质疑了问题本身？]
- **建议：** [综合后的路径]

保持手机屏幕可扫描性。

持久化规则

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

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

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

仅在决策改变真实事物时持久化。

多轮跟进

默认为一轮。

如果用户想要另一轮：

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

反模式

• 使用议会进行代码审查
• 任务仅为实施工作时使用议会
• 向子代理提供整个对话记录
• 在最终裁决中隐藏分歧
• 无论重要性如何，持久化每个决策为笔记

相关技能

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

示例

问题：

我们应该现在发布 ECC 2.0 的 alpha 版本，还是等到控制平面 UI 更完善？

可能的议会形态：

• 架构师推动结构完整性，避免混乱的表面
• 怀疑论者质疑 UI 是否真的是制约因素
• 实用主义者询问现在可以发布什么而不损害信任
• 批评者关注支持负担、期望债务和发布混乱

价值不在于一致同意。价值在于在选择前让分歧清晰可见。