Council
Run a four-voice adversarial council when a product or shipping decision has credible alternatives and you want explicit dissent before committing.
Overview
Council is a journey-wide agent skill that convenes four structured advisors for ambiguous tradeoffs and go/no-go calls—usable whenever a solo builder needs explicit disagreement before committing.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill councilWhat is this skill?
- Convenes in-context Claude plus Skeptic, Pragmatist, and Critic subagent lenses
- Architect voice stresses correctness, maintainability, and long-term implications
- Explicitly not for implementation planning, architecture design, or code review
- Surfaces tradeoffs and adversarial challenge for go/no-go decisions
- Guards against conversational anchoring when one path sounds obvious in chat
- Four advisory voices: in-context Claude, Skeptic, Pragmatist, and Critic subagents with an Architect lens
Adoption & trust: 3.3k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You face a credible fork (ship, scope, architecture posture, rollout) and chat keeps collapsing onto one biased path without surfaced tradeoffs.
Who is it for?
Indie builders at decision forks who want adversarial perspectives (skeptic, pragmatist, critic) before expensive commitments.
Skip if: Verifying correctness, breaking work into implementation steps, designing system architecture, code/security review, straight factual Q&A, or obvious execution chores—use santa-method, planner, architect, or code-reviewe
When should I use this skill?
A decision has multiple credible paths, you need explicit tradeoff surfacing, the user asks for second opinions or dissent, conversational anchoring is a risk, or a go/no-go call needs adversarial challenge.
What do I get? / Deliverables
You get structured multi-voice disagreement and clearer tradeoffs so you can choose a direction with eyes open—not a task list or a merged architecture doc.
- Structured multi-voice analysis with surfaced tradeoffs and a clearer basis for a go/no-go choice
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Debate whether to cut MVP breadth or keep strategic features before you green-light the build.
Compare monorepo vs polyrepo when both setups are viable for your team size and release cadence.
Choose feature-flagged rollout vs full release when blast radius and support load are unclear.
Resolve ship-now marketing push vs hold for polish when distribution timing affects credibility.
Revisit a operating model change (support vs automation) when maintenance cost and user trust pull in opposite directions.
How it compares
Use instead of single-thread chat consensus when you need named dissent roles—not instead of planner or architect skills for execution or design deliverables.
Common Questions / FAQ
Who is council for?
Solo and indie builders using Claude Code who face ambiguous product or engineering decisions and want a formal multi-voice debate before choosing among credible options.
When should I use council?
Use it journey-wide when tradeoffs lack an obvious winner—e.g. Validate scope for ship-now vs polish, Build pm for monorepo vs polyrepo, Ship launch for feature flag vs full rollout, or Launch distribution for simplifying scope vs keeping breadth—and when you explicitly want seco
Is council safe to install?
It is a procedural decision workflow without built-in shell or repo mutation; review the Security Audits panel on this page and treat subagent outputs as advisory, not authoritative approvals.
SKILL.md
READMESKILL.md - Council
# 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 ## Coun