ecc-council

用途

ecc-council 用于在模糊情境下做决策，而非代码审查、实现规划或架构设计。当出现以下情况时使用：一个决策有多条可信路径且没有明显赢家；需要明确呈现权衡取舍；用户要求第二意见、异议或多种视角；对话锚定是真实风险；go/no-go 判断能从对抗性挑战中受益。

典型例子包括：monorepo vs polyrepo、现在发布 vs 等待打磨、功能开关 vs 全量发布、简化范围 vs 保持战略广度。

不适用场景及替代方案：验证输出是否正确用 santa-method；把功能拆解为实现步骤用 planner；设计系统架构用 architect；审查代码中的 bug 或安全问题用 code-reviewer 或 santa-method；直接的事实性问题直接回答；明显的执行任务直接执行。

主要能力

议事会包含四个声音与视角：Architect 关注正确性、可维护性和长期影响；Skeptic 关注前提挑战、简化和假设打破；Pragmatist 关注交付速度、用户影响和运营现实；Critic 关注边界情况、下行风险和失败模式。

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

使用方式

工作流程

提取真正的问题将决策简化为一个明确提示：我们在决定什么？哪些约束重要？什么算成功？如果问题模糊，在召集议事会前先问一个澄清问题。
只收集必要上下文如果决策与代码库相关：收集相关文件、代码片段、issue 文本或指标；保持紧凑；只包含做决策所需的上下文。如果决策是战略/一般性的：除非仓库片段会实质改变答案，否则跳过。
先形成 Architect 立场在阅读其他声音前，写下：你的初始立场、支持它的三个最强理由、你偏好路径中的主要风险。先做这一步，综合才不会只是映照外部声音。
并行启动三个独立声音每个子代理获得：决策问题、必要时紧凑上下文、严格角色、不含不必要的对话历史。

提示词形状：

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

Question: [decision question]

Context: [only the relevant snippets or constraints]

Respond with:

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

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

角色侧重：Skeptic 挑战框架、质疑假设、提出最简单可信的替代方案；Pragmatist 优化速度、简单性和现实执行；Critic 揭示下行风险、边界情况和计划可能失败的原因。

带偏见防护地综合你既是参与者也是综合者，因此使用这些规则：不解释原因就不否定外部观点；如果外部声音改变了你的建议，明确说明；始终纳入最强异议，即使你拒绝它；如果两个声音与你的初始立场相左，将其视为真实信号；在裁决前保持原始立场可见。
呈现紧凑裁决使用此输出形状：

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 干净，以保留防锚定价值。

适用场景

ecc-council 适合需要在多个可信方案之间做出取舍、且没有明显赢家的场景。当决策涉及权衡取舍、需要暴露不同视角、需要被对抗性检验，或存在被对话上下锚定风险时，该技能尤为适用。

限制

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

示例

问题：我们应该现在将 ECC 2.0 作为 alpha 发布，还是等到控制平面 UI 更完整？

可能的议事会形态：Architect 推动结构完整性和避免令人困惑的表面；Skeptic 质疑 UI 是否真的是门控因素；Pragmatist 询问现在可以发布什么而不损害信任；Critic 聚焦支持负担、期望债务和发布混乱。价值不在于一致，而在于在做出选择前让分歧清晰可读。

技能介绍

用途