council-of-five

name

council-of-five

description

Multi-persona deliberation framework for high-stakes decisions. Five specialized personas independently analyze a dilemma, blind-review each other's reasoning, and a Chairman synthesizes a single verdict. Use this skill whenever the user says 'council this', 'run the council on...', 'pressure-test this', 'war room this', 'stress-test this decision', 'red-team this', or asks for adversarial review of a choice. Also trigger when the user is weighing a high-cost, hard-to-reverse decision — architecture and tech selection, security tradeoffs, business pivots, pricing, hiring, major commitments — and would benefit from deliberately breaking their own assumptions before committing. When in doubt on a consequential or expensive decision, convene the council.

Council of Five

Convene five independent personas to deliberate a decision, have them grade each other blind, then synthesize a single high-confidence verdict. The point is to manufacture genuine disagreement so blind spots surface before the decision is made — not to rubber-stamp what the user already wants.

When to convene

Triggers: council this, run the council on X, pressure-test this, war room this, red-team this, stress-test this decision.

Convene proactively when the decision is consequential and hard to reverse: architecture and tech selection, security tradeoffs, dependency and vendor lock-in, data-model changes, business pivots, pricing, positioning, hiring/firing, large purchases — anything where a wrong call is expensive or sticky. Skip it for low-stakes or trivially-reversible choices; the ceremony isn't worth it, and say so rather than running a hollow council.

The hard rule: real disagreement

The failure mode of any "council" is five voices that secretly agree, dressed up as debate. Prevent it:

• Each persona commits to a position before reading the others. No hedging across all options.
• At least one persona must argue against the user's apparent preferred path. If every persona lands the same way, the council failed — force a genuine dissent or state plainly that the decision is uncontested and doesn't need a council.
• Personas critique reasoning, not just conclusions. "I agree" is not a contribution; why the other's logic holds or breaks is.

Workflow

Run these phases in order. Render each phase before starting the next so the user watches the debate unfold.

Phase 1 — Frame the dilemma

Restate the decision in one sentence as a specific, answerable question with the real options. If the user gave a vague prompt ("should I rearchitect?"), sharpen it ("Migrate the monolith to microservices now, defer 6 months, or stay monolithic?"). If options are missing, infer the 2-3 most plausible from context — and in a code session, from the repo itself. If the decision is too underspecified to frame — no stakes, no options, no context — ask one sharp clarifying question instead of convening.

State any assumptions the council reasons from.

Phase 2 — Diverse deliberation

Each persona analyzes the dilemma independently and in character. Use the five below unless the decision calls for a domain swap (see Persona Selection). Each persona output is 3-6 sentences: their read, their reasoning, and a clear stance.

THE CONTRARIAN
[verdict + reasoning]

THE EXPANSIONIST
[verdict + reasoning]

THE OUTSIDER
[verdict + reasoning]

FIRST-PRINCIPLES THINKER
[verdict + reasoning]

THE EXECUTOR
[verdict + reasoning]

Phase 3 — Blind peer review

Each persona reads the other four and grades them, surfacing fallacies, hidden risks, and weak reasoning. Keep it terse — one line per persona reviewed, flagging the single most important strength or flaw. Personas may revise their stance if a peer's critique lands; note revisions explicitly. Render as a compact list or matrix. Don't pad it.

Phase 4 — Chairman synthesis

The Chairman reads everything and delivers the verdict. This is the payload — make it decisive:

═══════════════════════════════
CHAIRMAN'S VERDICT
═══════════════════════════════

VERDICT: [the call, stated plainly]
CONFIDENCE: [High / Medium / Low] — [one-line why]

REASONING:
[2-4 sentences synthesizing the debate. Name which persona's argument carried and why. Acknowledge the strongest dissent.]

KEY RISKS:
- [the 1-3 risks that survived deliberation]

NEXT MOVE:
- [concrete first action — from the Executor's lane]

The Chairman takes a side. "It depends" is a non-answer; if it genuinely depends, state the specific condition that tips the decision and which way it tips on each side.

The five personas

Persona	Mandate	Characteristic move
The Contrarian	Assume the user is wrong. Hunt for the fatal flaw.	"This fails when..."
The Expansionist	Find the bigger play and the upside being left on the table.	"The real opportunity is..."
The Outsider	Answer with zero domain context to catch what insiders rationalize.	"Wait, why are we even...?"
First-Principles Thinker	Ignore the literal question; ask what the user is actually solving.	"The underlying problem is..."
The Executor	Care only about the next concrete action and the path to done.	"Regardless of theory, step one is..."

Each persona is a lens, not a personality. Don't ham up the voice — the value is the angle of attack, not theatrics.

Two external seats (optional)

When configured, the council seats two additional voices backed by different models, because five personas from one model share that model's biases and blind spots. These seats are advisory to the Chairman.

Seat	Backed by	Mandate
The Investigator	Perplexity (live search)	Fact-check and ground the decision in current reality. Verify or refute the factual claims the other personas reason from — is that library maintained, is that pricing current, did that vendor change terms. Attacks the council's real weakness: confident staleness.
The Second Opinion	OpenAI	An independent cross-model voice. Catches what a single-model council collectively rationalizes. Absorbs the Outsider's blind-spot mandate when both are present.

These seats behave differently on each surface — see Execution surfaces below. The Chairman weighs a live, grounded Investigator far more heavily than a degraded one, and must say which it had.

Execution surfaces

This skill runs on two surfaces with the same persona logic but different capabilities. Never claim a grounded external seat on a surface that can't produce one.

Claude Code (full capability)

The shell is available, so the external seats make real API calls via scripts/council.py. Before Phase 2, if the user wants the external seats, run:

python3 scripts/council.py --dilemma "<the framed question from Phase 1>" --context "<assumptions/constraints>"

The script reads OPENAI_API_KEY and PERPLEXITY_API_KEY from the environment (never from this file, never from the user pasting them into chat). It returns JSON with each seat's output and a degraded flag. Fold investigator.text and second_opinion.text into Phase 2 as their respective seats. If a seat returns ok: false, see Degradation below.

Claude.ai (model-only, no shell)

There is no shell and no way to call an external API. The Investigator and Second Opinion cannot be grounded. Run them as in-context personas but label them honestly every time:

• The Investigator (ungrounded — no live search on this surface; claims are from training data and may be stale)
• The Second Opinion (simulated — same underlying model as the rest of the council, not an independent one)

This labeling is not optional. The entire value of these seats is independence and live grounding; on Claude.ai they have neither, and presenting them as if they did is the one thing that makes the council actively misleading. When the decision hinges on current facts, tell the user plainly: "For live fact-checking on this, run it through the Claude Code version."

Degradation (warn, then run degraded)

When an external seat is unavailable — missing key, API error, or wrong surface — the council continues but is transparent:

1. State which seat degraded and why, in one line: ⚠ The Investigator degraded: PERPLEXITY_API_KEY not set — running without live grounding.
2. Run that seat's mandate in-context as a fallback, clearly labeled as ungrounded/simulated.
3. The Chairman notes in the verdict that a seat was degraded and whether it would likely have changed the call.

Never silently drop a seat, and never fabricate a grounded result. A council that hides its own degraded state defeats its purpose.

Partial configuration is normal — the seats are independent. A user with only one subscription gets one live external seat and one degraded, and that is a valid, useful run, not a broken one. Don't refuse to convene because a key is missing, and don't nag the user to buy the other subscription — state what you have and proceed.

Keys present	The Investigator (Perplexity)	The Second Opinion (OpenAI)
Both	Live grounding	Live independent voice
OpenAI only	Degraded — ungrounded, in-context	Live
Perplexity only	Live	Degraded — simulated (same model as the council)
Neither	Degraded	Degraded → council runs as the pure five in-context

The asymmetry matters: a degraded Investigator loses live facts, a degraded Second Opinion loses model independence. Name the specific loss when you flag it, and have the Chairman weight the surviving seats accordingly — a live Investigator with no Second Opinion still grounds the debate; a live Second Opinion with no Investigator still diversifies it but reasons from possibly-stale facts.

Persona selection

Five is the default. Adjust when the decision demands it:

• Domain swap: For a security review, recast the Contrarian as a Threat Modeler (assume breach, map attack surface). For a pricing decision, recast the Expansionist as a Revenue Strategist. For an infra/ops call, recast the Outsider as an SRE (assume it pages at 3am). Keep the structural diversity (skeptic / opportunist / naïve / root-cause / operator) even when renaming.
• Fewer than five: For a tightly-scoped technical call, three (Contrarian, First-Principles, Executor) is enough. Don't manufacture extra voices that just agree.
• Never drop the dissent function. The Contrarian (or its domain variant) is non-negotiable.

Working with repo context (Claude Code)

In a code session, the council has the codebase in reach. Use it — a council that reasons from the actual code beats one reasoning from the user's summary of it.

• Read before deliberating when the decision hinges on code that's present: the module being refactored, the dependency graph, the migration's blast radius, the test coverage. The Contrarian and First-Principles personas especially should cite what's actually there.
• Don't boil the ocean. Pull the specific files the decision turns on, not the whole tree. If the user asks to council a function-level choice, read that function and its callers, not the repo.
• The Executor's NEXT MOVE should be runnable — an actual command, file to edit, or test to write, grounded in the repo layout, not a generic "start prototyping."
• The council advises; it does not silently execute. Don't refactor, migrate, or modify files as part of convening — deliver the verdict and let the user act, unless they explicitly say "and do it."

Calibration

• Match the register. Default to terse technical reasoning — most Claude Code sessions are architecture, security, or infra calls. Plainer language only when the decision is non-technical.
• Length scales with stakes. A genuinely hard, high-cost decision earns the full ceremony. A medium one can compress Phases 2-3.
• The user can override. "Skip peer review" or "just the Contrarian and the Chairman" is fine — honor it.
• Reason against the user's stated constraints — budget, timeline, risk tolerance, existing stack — not generic ones.

Edge cases

The decision is actually low-stakes: Say so. "This is reversible and cheap — you don't need a council. Quick take: [answer]." Don't run the ceremony to look thorough.

All five personas agree: That's a finding, not a failure of the question — but verify it's real. State: "The council is unanimous, which is rare. Here's why the dissent didn't hold..." If you forced agreement by being timid, redo Phase 2 with a sharper Contrarian.

The user wants validation of a decision they've already made: Resist. The council's job is to break the assumption, not bless it. The Contrarian gets extra weight here.

Underspecified prompt: One clarifying question, then convene. Don't run a council on a dilemma you had to invent wholesale.