Loading the skills library…
Skills leaderboard
council
npx skills add affaan-m/ecc --skill council -a claude-code -ynpx skills add affaan-m/ecc --skill council -a claude-code -yConvene four advisors for ambiguous decisions:
This is for decision-making under ambiguity, not code review, implementation planning, or architecture design.
Use council when:
Examples:
| 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 |
| 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.
Reduce the decision to one explicit prompt:
If the question is vague, ask one clarifying question before convening the council.
If the decision is codebase-specific:
If the decision is strategic/general:
Before reading other voices, write down:
Do this first so the synthesis does not simply mirror the external voices.
Each subagent gets:
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:
You are both a participant and the synthesizer, so use these rules:
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.
Do not write ad-hoc notes to ~/.claude/notes or other shadow paths from this skill.
If the council materially changes the recommendation:
knowledge-ops to store the lesson in the right durable location/save-session if the outcome belongs in session memoryOnly persist a decision when it changes something real.
Default is one round.
If the user wants another round:
santa-method — adversarial verificationknowledge-ops — persist durable decision deltas correctlysearch-first — gather external reference material before the council if neededarchitecture-decision-records — formalize the outcome when the decision becomes long-lived system policyQuestion:
Should we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?
Likely council shape:
The value is not unanimity. The value is making the disagreement legible before choosing.
--- name: 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: ```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 ### 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: ```markdown ## 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: ```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.