Back to Details

council

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Council

决策委员会

Convene four advisors for ambiguous decisions:
  • the in-context Claude voice
  • a Skeptic subagent
  • a Pragmatist subagent
  • a Critic subagent
This is for decision-making under ambiguity, not code review, implementation planning, or architecture design.
针对模糊决策召集四位顾问：
  • 上下文关联的Claude角色
  • 怀疑派subagent
  • 实用派subagent
  • 批评派subagent
此方法适用于模糊场景下的决策，不适合代码评审、实现方案规划或架构设计。

When to Use

适用场景

Use council when:
  • a decision has multiple credible paths and no obvious winner
  • you need explicit tradeoff surfacing
  • the user asks for second opinions, dissent, or multiple perspectives
  • conversational anchoring is a real risk
  • a go / no-go call would benefit from adversarial challenge
Examples:
  • monorepo vs polyrepo
  • ship now vs hold for polish
  • feature flag vs full rollout
  • simplify scope vs keep strategic breadth
满足以下条件时可使用决策委员会：
  • 决策存在多个可行路径，且没有明显最优解
  • 你需要明确梳理各方权衡点
  • 用户要求获取第二意见、反对观点或多视角参考
  • 存在明显的对话锚定偏差风险
  • 可行/不可行判断能够通过对抗性挑战得到优化
示例：
  • monorepo vs polyrepo
  • 立即上线 vs 打磨后再发布
  • feature flag vs 全量发布
  • 精简范围 vs 保留战略广度

When NOT to Use

不适用场景

Instead of councilUse
Verifying whether output is correct
santa-method
Breaking a feature into implementation steps
planner
Designing system architecture
architect
Reviewing code for bugs or security
code-reviewer
or 
santa-method
Straight factual questionsjust answer directly
Obvious execution tasksjust do the task
不要用决策委员会处理以下场景请使用对应工具
验证输出是否正确
santa-method
将功能拆解为实现步骤
planner
设计系统架构
architect
评审代码的Bug或安全问题
code-reviewer
或 
santa-method
直白的事实类问题直接回答即可
明确的执行类任务直接执行任务即可

Roles

角色说明

VoiceLens
Architectcorrectness, maintainability, long-term implications
Skepticpremise challenge, simplification, assumption breaking
Pragmatistshipping speed, user impact, operational reality
Criticedge cases, downside risk, failure modes
The three external voices should be launched as fresh subagents with only the question and relevant context, not the full ongoing conversation. That is the anti-anchoring mechanism.
角色关注视角
架构师正确性、可维护性、长期影响
怀疑派挑战前提、简化方案、打破假设
实用派上线速度、用户影响、落地可行性
批评派边缘场景、下行风险、失败模式
三个外部角色需要作为全新的subagent启动，仅传入问题本身和相关上下文，不要传入完整的历史对话。这是防锚定机制。

Workflow

工作流程

1. Extract the real question

1. 提取真实问题

Reduce the decision to one explicit prompt:
  • what are we deciding?
  • what constraints matter?
  • what counts as success?
If the question is vague, ask one clarifying question before convening the council.
将决策内容简化为一个明确的提示词：
  • 我们要决策的核心是什么？
  • 有哪些重要约束？
  • 成功的判定标准是什么？
如果问题模糊，在召集决策委员会前先提出一个澄清问题。

2. Gather only the necessary context

2. 仅收集必要上下文

If the decision is codebase-specific:
  • collect the relevant files, snippets, issue text, or metrics
  • keep it compact
  • include only the context needed to make the decision
If the decision is strategic/general:
  • skip repo snippets unless they materially change the answer
如果决策和特定代码库相关：
  • 收集相关文件、代码片段、issue文本或指标数据
  • 保持内容精简
  • 仅包含决策所需的必要上下文
如果是战略类/通用类决策：
  • 跳过仓库代码片段，除非它们会显著影响决策结果

3. Form the Architect position first

3. 先形成架构师立场

Before reading other voices, write down:
  • your initial position
  • the three strongest reasons for it
  • the main risk in your preferred path
Do this first so the synthesis does not simply mirror the external voices.
在参考其他角色的意见前，先写下：
  • 你的初始立场
  • 支持该立场的三个最有力理由
  • 你偏好的路径存在的主要风险
优先完成这一步，避免最终综合意见只是简单照搬外部角色的观点。

4. Launch three independent voices in parallel

4. 并行启动三个独立角色

Each subagent gets:
  • the decision question
  • compact context if needed
  • a strict role
  • no unnecessary conversation history
Prompt shape:
text
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.
Role emphasis:
  • Skeptic: challenge framing, question assumptions, propose the simplest credible alternative
  • Pragmatist: optimize for speed, simplicity, and real-world execution
  • Critic: surface downside risk, edge cases, and reasons the plan could fail
每个subagent获取的内容：
  • 决策问题
  • 必要时提供精简上下文
  • 明确的角色要求
  • 不提供无关的对话历史
提示词模板：
text
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. Synthesize with bias guardrails

5. 带有偏差防护的综合意见

You are both a participant and the synthesizer, so use these rules:
  • do not dismiss an external view without explaining why
  • if an external voice changed your recommendation, say so explicitly
  • always include the strongest dissent, even if you reject it
  • if two voices align against your initial position, treat that as a real signal
  • keep the raw positions visible before the verdict
你既是参与者也是综合意见整理者，因此要遵守以下规则：
  • 不要在未解释原因的情况下否定外部观点
  • 如果某个外部观点改变了你的推荐方案，明确说明
  • 即使你反对最强烈的异议，也要将其纳入最终内容
  • 如果有两个角色的意见和你的初始立场相反，将其视为重要信号
  • 在给出结论前，先展示所有角色的原始立场

6. Present a compact verdict

6. 输出精简结论

Use this output shape:
markdown
undefined
使用如下输出模板：
markdown
undefined

Council: [short decision title]

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]
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

Verdict

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

Keep it scannable on a phone screen.
  • Consensus: [where they align]
  • Strongest dissent: [most important disagreement]
  • Premise check: [did the Skeptic challenge the question itself?]
  • Recommendation: [the synthesized path]

确保内容在手机屏幕上也能轻松浏览。

Persistence Rule

持久化规则

Do not write ad-hoc notes to 
~/.claude/notes
or other shadow paths from this skill.
If the council materially changes the recommendation:
  • use 
    knowledge-ops
    to store the lesson in the right durable location
  • or use 
    /save-session
    if the outcome belongs in session memory
  • or update the relevant GitHub / Linear issue directly if the decision changes active execution truth
Only persist a decision when it changes something real.
不要通过此技能向
~/.claude/notes
或其他隐藏路径写入临时笔记。
如果决策委员会的结论显著改变了原有推荐方案：
  • 使用
    knowledge-ops
    将经验教训存储到合适的持久化位置
  • 如果结果属于会话内存范畴，使用
    /save-session
  • 如果决策改变了当前的执行基准，直接更新对应的GitHub / Linear issue
仅当决策会实际影响现有事项时，才对其进行持久化存储。

Multi-Round Follow-up

多轮跟进规则

Default is one round.
If the user wants another round:
  • keep the new question focused
  • include the previous verdict only if it is necessary
  • keep the Skeptic as clean as possible to preserve anti-anchoring value
默认仅执行一轮决策。
如果用户要求进行多轮决策：
  • 保持新问题聚焦
  • 仅在必要时包含上一轮的结论
  • 尽量保持怀疑派角色的输入干净，以保留防锚定的价值

Anti-Patterns

反模式

  • using council for code review
  • using council when the task is just implementation work
  • feeding the subagents the entire conversation transcript
  • hiding disagreement in the final verdict
  • persisting every decision as a note regardless of importance
  • 将决策委员会用于代码评审
  • 任务仅为执行类工作时使用决策委员会
  • 向subagent传入完整的对话记录
  • 在最终结论中隐藏分歧意见
  • 无论重要性如何，将所有决策都作为笔记持久化

Related Skills

相关技能

  • santa-method
    — adversarial verification
  • knowledge-ops
    — persist durable decision deltas correctly
  • search-first
    — gather external reference material before the council if needed
  • architecture-decision-records
    — formalize the outcome when the decision becomes long-lived system policy
  • santa-method
    — 对抗性验证
  • knowledge-ops
    — 正确持久化长期有效的决策变更
  • search-first
    — 必要时在启动决策委员会前收集外部参考资料
  • architecture-decision-records
    — 当决策成为长期系统规则时，将结果正式归档

Example

示例

Question:
text
Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?
Likely council shape:
  • Architect pushes for structural integrity and avoiding a confused surface
  • Skeptic questions whether the UI is actually the gating factor
  • Pragmatist asks what can be shipped now without harming trust
  • Critic focuses on support burden, expectation debt, and rollout confusion
The value is not unanimity. The value is making the disagreement legible before choosing.
问题：
text
Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?
可能的决策委员会意见分布：
  • 架构师主张保障结构完整性，避免产生混淆的对外界面
  • 怀疑派质疑UI是否真的是发布的门槛因素
  • 实用派探讨当前可以发布哪些内容而不损害用户信任
  • 批评派关注支持负担、预期债务和发布混乱的风险
此方法的价值不在于达成一致，而在于在做出选择前将所有分歧清晰呈现。