委员会¶

为模糊的决策召集 4 位顾问： - 上下文中的 Claude 的声音 - 怀疑论者子代理 - 现实主义者子代理 - 批评家子代理

这是用于模糊条件下的决策，而不是用于代码审查、实现计划或架构设计。

使用时机¶

在以下情况下使用委员会： - 决策存在多个可信路径，且没有明显赢家时 - 需要明确权衡时 - 用户希望获得不同意见、反对意见或多个视角时 - 对话锚定构成实际风险时 - 推进/不推进的判断能从对抗性挑战中受益时

示例： - 单体仓库 vs 多仓库 - 立即发布 vs 为打磨而暂缓 - 功能标志 vs 全量发布 - 简化范围 vs 保持战略性广度

不应使用的情况¶

角色¶

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

工作流¶

1. 提取真正的问题¶

将决策缩减为一个明确的 Prompt： - 我们要决定什么？ - 哪些约束重要？ - 什么被视为成功？

如果问题模糊，在召集委员会之前先提出一个澄清问题。

2. 仅收集必要的上下文¶

如果决策与代码库相关： - 收集相关文件、代码片段、任务文本或指标 - 保持简洁 - 仅包含做出决策所需的上下文

如果决策是战略性或通用的： - 除非会实质性改变答案，否则跳过仓库代码片段

3. 先形成架构师的立场¶

在阅读其他声音之前，写下以下内容： - 初始立场 - 支持它的三个最强理由 - 首选路径的主要风险

先这样做，可以避免综合结果仅仅反映外部声音。

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

每个子代理接收以下内容： - 决策问题 - 如需要，简洁的上下文 - 严格的角色 - 无不必要的对话历史

Prompt 格式：

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.

角色强调： - 怀疑论者：挑战框架，质疑假设，并提出最简单且可信的替代方案 - 现实主义者：优化速度、简洁性和现实世界的可执行性 - 批评家：揭示下行风险、边缘情况以及计划可能失败的原因

5. 使用偏差护栏进行综合¶

你既是参与者又是综合者，因此使用以下规则： - 不要在没有解释的情况下驳回外部观点 - 如果外部声音改变了建议，明确说明 - 即使驳回，也要始终包含最强的反对意见 - 如果两个声音反对初始立场，将其视为实际信号 - 在裁决之前保持显示原始立场

6. 呈现简洁的裁决¶

使用以下输出格式：

## 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 任务

仅当决策改变了某些实际内容时才持久化。

多轮跟进¶

默认为一轮。

如果用户希望进行另一轮： - 保持新问题聚焦 - 仅在必要时包含之前的裁决 - 为保持反锚定的价值，尽量保持怀疑论者干净

反模式¶

• 在代码审查中使用委员会
• 当任务只是实现工作时使用委员会
• 向子代理传递整个对话记录
• 在最终裁决中隐藏分歧
• 无论重要性如何，都将所有决策作为笔记持久化

相关技能¶

• 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?

委员会可能的形态： - 架构师主张结构一致性，并避免混乱的界面 - 怀疑论者质疑 UI 是否真的是门控因素 - 现实主义者询问在不损害信任的情况下现在可以发布什么 - 批评家关注支持负担、期望负债和发布混乱

价值不在于一致。价值在于在选择之前明确分歧。