/ecc-council

name: ecc-council
description: Convene a four-voice council for ambiguous decisions, tradeoffs, and go/no-go calls. Use when multiple valid paths exist and you need structured disagreement before choosing.
metadata:
  origin: ECC

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.

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

When NOT to Use

| Instead of council | Use | | --- | --- | | 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 questions | just answer directly | | Obvious execution tasks | just do the task |

Roles

| Voice | Lens | | --- | --- | | Architect | correctness, maintainability, long-term implications | | Skeptic | premise challenge, simplification, assumption breaking | | Pragmatist | shipping speed, user impact, operational reality | | Critic | edge 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.

Workflow

1. Extract the real question

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

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

3. Form the Architect position first

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

Each subagent gets:

• the decision question
• compact context if needed
• a strict role
• no unnecessary conversation history

Prompt shape:

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

5. Synthesize with bias guardrails

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

Use this output shape:

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

Keep it scannable on a phone screen.

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.

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

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

Example

Question:

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 str