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.

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: 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: 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: 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.