| name | council |
| description | 召集四方会议处理模糊决策、权衡取舍及继续/停止决策。当存在多个有效路径且需要在选择前进行结构化异议时使用。 |
| origin | ECC |
在模糊决策时召集四位顾问：
这适用于模糊性下的决策制定，而非代码审查、实施规划或架构设计。
在以下情况使用顾问团：
示例：
| 不应使用顾问团的情况 | 应使用 |
|---|---|
| 验证输出是否正确 | santa-method |
| 将功能拆解为实施步骤 | planner |
| 设计系统架构 | architect |
| 审查代码中的错误或安全漏洞 | code-reviewer 或 santa-method |
| 直接的事实性问题 | 直接回答 |
| 明确的执行任务 | 直接执行 |
| 声音 | 视角 |
|---|---|
| 架构师 | 正确性、可维护性、长期影响 |
| 怀疑论者 | 质疑前提、简化、打破假设 |
| 实用主义者 | 交付速度、用户影响、运营现实 |
| 批评者 | 边缘情况、下行风险、失败模式 |
三个外部声音应作为全新子代理启动，仅提供问题和相关上下文，而非完整对话历史。这是反锚定机制。
将决策简化为一个明确提示：
如果问题模糊，在召集顾问团前先提出一个澄清性问题。
如果决策与代码库相关：
如果决策是战略/通用性的：
在阅读其他声音之前，写下：
先完成此步骤，以确保综合意见不会简单镜像外部声音。
每个子代理获得：
提示模板：
你是四声部决策委员会中的[角色]。
问题：
[决策问题]
背景：
[仅包含相关片段或约束条件]
回复格式：
1. 立场 — 1-2句话
2. 理由 — 3个简洁要点
3. 风险 — 你建议中最大的风险
4. 意外点 — 其他声部可能忽略的一个方面
直接明了，不要含糊。控制在300字以内。
角色重点：
你既是参与者也是综合者，因此需遵循以下规则：
使用以下输出格式：
## 委员会：[简短决策标题]
**架构师：** [1-2句立场陈述]
[1行理由说明]
**怀疑论者：** [1-2句立场陈述]
[1行理由说明]
**实用主义者：** [1-2句立场陈述]
[1行理由说明]
**批评者：** [1-2句立场陈述]
[1行理由说明]
### 裁决
- **共识点：** [各方达成一致之处]
- **最大分歧：** [最重要的争议点]
- **前提检验：** [怀疑论者是否质疑了问题本身？]
- **建议方案：** [综合后的行动路径]
确保在手机屏幕上可快速浏览。
不要从此技能向 ~/.claude/notes 或其他隐藏路径写入临时笔记。
若顾问团实质性改变了建议：
knowledge-ops 将经验教训存储在正确的持久化位置/save-session（若结果属于会话记忆）仅在决策改变实际内容时进行持久化。
默认为一轮。
若用户要求另一轮：
santa-method — 对抗性验证knowledge-ops — 正确持久化重要决策变更search-first — 在顾问团前收集外部参考资料（如需要）architecture-decision-records — 当决策成为长期系统策略时正式化结果问题：
我们现在应该以 alpha 版本发布 ECC 2.0，还是等到控制平面 UI 更完善后再发布？
可能的顾问团形态：
价值不在于达成一致。价值在于在选择前让分歧清晰可见。