Llm Council

LLM Council

One AI gives you one answer. That answer feels smart because it was shaped by how you asked. Ask the same question with different framing and you get a different answer, often opposite, equally confident.

The council breaks that loop. Five advisors with different thinking styles answer your question independently. They peer-review each other anonymously. A chairman synthesizes everything into a verdict with a clear recommendation and one concrete next step.

This skill runs the whole protocol inside a single Claude Code session.

When NOT to convene

If the question fits one of these, just answer directly instead of convening:

• Factual lookup (one correct answer exists).
• Creation task (write, summarize, translate, refactor).
• Trivial choice (e.g. "should I use markdown or plaintext for this note").
• The user has already decided and wants validation. Warn them the council may dissent, then proceed only if they confirm.

If you are unsure, ask the user once: "Is this a real tradeoff you want pressure-tested, or do you want a direct answer?"

The seven steps

This workflow is rigid. Execute in order. Do not skip, merge, or parallelize across steps.

Step 1. Scan workspace for context (30 seconds max)

Before framing the question, surface any workspace context the advisors will need. Use Glob and Read. Do not spend more than 30 seconds on this step.

Look for:

• CLAUDE.md, AGENTS.md, GEMINI.md (user or project instructions).
• memory/**/*.md (user profile, past decisions, voice).
• Files the user referenced by name or @-mention.
• Recent council/**/council-report.html artifacts so you avoid re-counciling ground already covered.

Pick at most 2 to 3 files that would move advisors from generic to grounded. Skip entirely if nothing relevant is present. Never read the whole workspace indiscriminately.

Step 2. Frame the question

Restate the user's raw question as a single neutral prompt with four parts:

1. Core decision, stripped of emotional lean. 2. User-provided context: facts, numbers, constraints. 3. Workspace context: the 2 to 3 facts from Step 1 that matter here. 4. Stakes: why being wrong is expensive.

Do not inject your own opinion. Do load enough context that advisors can be specific rather than generic.

If the question is too vague to frame ("council this: my business"), ask exactly ONE clarifying question and wait. Then frame.

Save the framed question. Every advisor and every reviewer receives this exact text.

Step 3. Convene the council (5 advisors in parallel)

Load references/advisor-prompts.md. It contains five identity blocks (Contrarian, First Principles, Expansionist, Outsider, Executor) plus a shared wrapper.

Emit all five Agent tool calls in a SINGLE assistant message. This is mandatory. Sequential calls defeat the entire point, because later advisors would see earlier ones through context bleed.

For each advisor, the tool call is:

Agent(
  description: "<Advisor name>, council round 1",
  subagent_type: "general-purpose",
  prompt: <shared wrapper + advisor block + framed question + workspace snippets>
)

Each advisor produces 150 to 300 words, no preamble, leaning fully into their angle. If an advisor hedges, discard and re-spawn that one advisor. (Re-spawning is only allowed for hedging, not for style preference.)

Collect all five outputs before moving on.

Step 4. Anonymize for peer review

Load references/anonymization.md and follow the deterministic shuffle algorithm exactly. Do NOT improvise your own scheme.

Outputs of Step 4:

• One markdown block with five sections labeled Response A through Response E, in shuffled order, with persona language stripped per the regex list.
• An internal mapping (Contrarian to C, FirstPrinciples to A, etc.) held in your scratchpad. This mapping NEVER goes to reviewers. It WILL go into the final transcript.

Step 5. Peer review (5 reviewers in parallel)

Load references/reviewer-prompts.md. Again, emit all five Agent tool calls in a SINGLE assistant message.

Agent(
  description: "Reviewer <N>, council round 2",
  subagent_type: "general-purpose",
  prompt: <reviewer template + framed question + all five anonymized responses>
)

Every reviewer sees the same five anonymized responses and answers the same three questions:

1. Which response is strongest, and why? (pick one letter) 2. Which response has the biggest blind spot, and what is it missing? (pick one letter) 3. What did ALL FIVE miss?

Under 200 words each. Direct, no hedging. The peer-review round is the single highest-leverage step in the whole protocol. Question 3 consistently surfaces things no individual advisor saw.

Step 6. Chairman synthesis (in this session, not a sub-agent)

Load references/chairman-prompts.md. Synthesize in the main session. Never delegate. The main session holds the anonymization map and can de-anonymize for the final report. A sub-agent cannot.

Produce the verdict with this exact five-section structure:

## Where the Council Agrees
## Where the Council Clashes
## Blind Spots the Council Caught
## The Recommendation
## The One Thing to Do First

The chairman may overrule the majority when minority reasoning is stronger. Say so explicitly when it happens. End with a single concrete next step. One thing, not a list.

Step 7. Write artifacts and open the report

Create ./council/<timestamp>/ where <timestamp> is local time formatted YYYY-MM-DD-HHMMSS. Use date "+%Y-%m-%d-%H%M%S" via Bash to generate it.

Inside that folder, produce two files by filling templates with string substitution:

• council-report.html: Read assets/templates/report.html, replace every {{HANDLEBAR}} placeholder, Write the result.
• council-transcript.md: Read assets/templates/transcript.md, fill it the same way, Write the result. The transcript includes the anonymization map. The HTML does not.

Then run open <path>/council-report.html via Bash to show the briefing.

Finish with a short message to the user: the recommendation, the one thing to do first, and the path to the report. Nothing more. The user can click into the HTML for detail.

Operating rules

These are non-negotiable. Violating them corrupts the protocol.

• All five advisor calls MUST be in the SAME assistant message. Parallel dispatch only.
• All five reviewer calls MUST be in the SAME assistant message. Parallel dispatch only.
• Reviewers MUST NOT see the advisor-to-letter mapping. Ever.
• Advisors and reviewers see the framed question, not the user's raw message.
• Chairman synthesis happens in the main session, not a sub-agent.
• Never edit files outside ./council/<timestamp>/.
• The HTML report is a briefing document. The markdown transcript is the audit trail. Always produce both.

Resources

• references/advisor-prompts.md: five advisor identity blocks and the shared prompt wrapper. Loaded in Step 3.
• references/reviewer-prompts.md: peer-review prompt template. Loaded in Step 5.
• references/chairman-prompts.md: chairman synthesis template. Loaded in Step 6.
• references/anonymization.md: deterministic shuffle algorithm and regex strip list. Loaded in Step 4.
• references/examples.md: two worked councils to compare against. Load if the user asks for an example, or if a council session looks thin and you want to recalibrate.
• assets/templates/report.html: HTML briefing template. Filled in Step 7.
• assets/templates/transcript.md: markdown transcript skeleton. Filled in Step 7.

Council: {{DATE_LONG}}

Original question

{{ORIGINAL_QUESTION}}

Framed question

{{FRAMED_QUESTION}}

Workspace context used

{{WORKSPACE_CONTEXT_NOTES}}

---

Round 1: Advisor responses (raw, de-anonymized)

The Contrarian

{{RESPONSE_CONTRARIAN}}

The First Principles Thinker

{{RESPONSE_FIRST_PRINCIPLES}}

The Expansionist

{{RESPONSE_EXPANSIONIST}}

The Outsider

{{RESPONSE_OUTSIDER}}

The Executor

{{RESPONSE_EXECUTOR}}

---

Anonymization map

Session timestamp: {{SESSION_TIMESTAMP}} · permutation index: {{PERMUTATION_INDEX}}

---

Round 2: Peer reviews (reviewers saw only the anonymized A to E responses)

Reviewer 1

{{REVIEWER_1}}

Reviewer 2

{{REVIEWER_2}}

Reviewer 3

{{REVIEWER_3}}

Reviewer 4

{{REVIEWER_4}}

Reviewer 5

{{REVIEWER_5}}

---

Chairman synthesis

Where the council agrees

{{AGREES}}

Where the council clashes

{{CLASHES}}

Blind spots the council caught

{{BLIND_SPOTS}}

The recommendation

{{RECOMMENDATION}}

The one thing to do first

{{ONE_THING}}

llm-council


A Claude Code skill that stops you from trusting the first answer you get.

You ask Claude a question. You get one answer. It sounds smart. You move on. Two days later you realize the answer was shaped by how you asked, not by what was true. This skill fixes that. It spins up five advisors with genuinely different thinking styles, has them answer your question independently, makes them peer-review each other anonymously, and gives you a verdict with a single clear next step.

Runs entirely inside Claude Code as a native skill. No external services, no API keys, no extra installs.

What this is

llm-council is a Claude Code skill. If you have not used Claude Code skills before, they are bundles of instructions plus prompt templates that sit in your ~/.claude/skills/ directory. Claude Code loads them on demand when your question matches the skill's triggers.

When you type a phrase like "council this" or "pressure-test this", the skill takes over:

1. It scans your workspace for context files (CLAUDE.md, AGENTS.md, memory folders) so the advisors have something real to chew on. 2. It frames your question as a neutral prompt. 3. It spawns five Claude Code sub-agents in parallel, one per advisor thinking style. 4. It anonymizes the five responses, then spawns five reviewers in parallel to peer-review the set. 5. It synthesizes everything into a five-section verdict. 6. It writes a clean HTML briefing and a full markdown transcript into ./council/<timestamp>/, then opens the briefing in your browser.

Total time is around 2 to 4 minutes depending on how much context the advisors need to read.

Why I built it

I kept noticing the same pattern. I would ask Claude something, get a confident answer, and then catch myself realizing the answer just matched my framing back at me. Ask the same question with the opposite framing and you get the opposite answer, equally confident. That is fine for writing an email. It is not fine for deciding whether to rewrite a backend, switch pricing models, or hire someone.

Having five advisors with genuinely different thinking styles answer independently, then peer-review each other without knowing who wrote what, cuts through that failure mode. The peer-review round is the part that surprised me the most. The single most valuable question is "what did all five miss?" Reviewers reading five strong takes side by side catch things no individual advisor saw, because the gap between five perspectives is where the collective blind spot lives.

Install

You need Claude Code installed. If you do not have it yet, grab it from Anthropic. Then drop this skill into your skills directory.

cd ~/.claude/skills
git clone https://github.com/YonasValentin/llm-council.git

That is the whole install. Start a new Claude Code session and the skill is discoverable. Type /llm-council or just use a trigger phrase in any conversation.

If you prefer to keep your skills in a plugin folder, the standard ~/.claude/skills/llm-council/ layout works. Claude Code picks it up automatically on session start.

How to use it

Trigger it with a sentence, not a command. The skill is tuned to catch natural phrasing, not specific flags.

Any of these will invoke it:

• council this: should I rewrite our backend in Rust or invest that time in caching?
• pressure-test this pricing: $49/month vs $99/month with a free tier
• I am torn between hiring a senior engineer or two juniors. Convene the council.
• war-room this positioning: should we niche down to fintech or stay horizontal?

The skill ignores trivial questions on purpose. "Should I use markdown or plaintext" is not a council question. You will get told that and given a direct answer instead.

Give the council as much context as you can in your prompt. If you have a CLAUDE.md or a memory/ folder in your repo, the skill will read the relevant files before framing the question, so the advisors get grounded advice rather than generic takes.

What you get back

Two files, in a fresh timestamped folder at ./council/<YYYY-MM-DD-HHMMSS>/.

`council-report.html` is a self-contained briefing document. Warm paper background, serif body, inky blue accent. The chairman's verdict is at the top with five sections:

1. Where the council agrees. 2. Where the council clashes. 3. Blind spots the council caught. 4. The recommendation. 5. The one thing to do first.

Below that, each advisor's full response is in a collapsible section labeled by thinking style. Below that, each reviewer's critique is in another collapsible section. The whole thing is one HTML file. You can email it, commit it, print it.

`council-transcript.md` is the audit trail. Everything the council saw and produced, in plain markdown, plus the anonymization map showing which advisor was assigned which letter for the peer-review round. Useful if you want to diff two councils run on similar questions, or if you want to understand why the chairman sided with the minority.

The five advisors

Each advisor is a distinct thinking style. They are not job titles. They are lenses designed to create three tensions in the room that cancel out each other's blind spots.

The Contrarian looks for what will fail. Assumes the idea has a fatal flaw and goes hunting. If the plan survives the Contrarian, it is probably not quietly broken.

The First Principles Thinker ignores your surface question and asks what you are really trying to solve. This is the advisor most likely to tell you that you are optimizing the wrong variable.

The Expansionist hunts for upside you are missing. What if this works better than you think? What adjacent opportunity are you leaving on the table because you are too anchored on the obvious path?

The Outsider has zero context about you, your field, your history, your audience. Responds only to what is literally in front of them. This one is the secret weapon. Experts develop blind spots about what is obvious. The Outsider catches the things your customers would never understand but you think are self-evident.

The Executor only cares about what you do Monday morning. Compresses timelines. Proposes the smallest experiment that would actually test the idea. Kills plans that sound brilliant but have no first step.

Together they create three natural tensions: Contrarian against Expansionist on downside versus upside, First Principles against Executor on rethink versus ship, and the Outsider sitting in the middle keeping everyone honest.

When to convene

Good council questions have real stakes and multiple viable options:

• "Should I launch a $97 workshop or a $497 self-paced course for my Claude Code audience?"
• "Which of these three positioning angles is strongest?"
• "Am I crazy to pivot from B2B to B2C six months in?"
• "Here is my landing page copy. What is weak?"

When not to convene

• The question has one correct answer (a factual lookup).
• The task is creation, not decision (write a tweet, refactor this function).
• The tradeoff is trivial (markdown vs plaintext for a note).
• You have already decided and just want validation. The council will probably tell you something you do not want to hear. That is the point.

If you are unsure, the skill will ask you once whether this is a real tradeoff you want pressure-tested, or whether you just want a direct answer.

How it works under the hood

The skill is plain Claude Code. No external dependencies. The protocol is rigid on purpose.

1. The workspace scan pulls in up to three relevant context files so the advisors can be specific rather than generic. 2. The framing step restates the question neutrally, stripped of your emotional lean, with the context baked in. All five advisors receive exactly the same framed question. 3. Round 1 dispatches five parallel Agent calls in a single message. Parallel dispatch is mandatory. Sequential calls would let earlier advisors bleed into later ones through shared context, which defeats the independence. 4. The anonymization step runs a deterministic shuffle based on the session timestamp. All five responses get relabeled A through E, with persona language stripped via a regex list so reviewers cannot reverse-engineer who wrote what. 5. Round 2 dispatches five parallel reviewer calls. Every reviewer sees the same five anonymized responses and answers the same three questions: strongest response, biggest blind spot, what did all five miss. 6. The chairman synthesis runs in the main Claude Code session, not a sub-agent. This matters because the main session holds the anonymization map and can de-anonymize for the final report. A sub-agent cannot. 7. The output step reads two templates, substitutes placeholders, writes both files, and opens the HTML in your default browser with open.

File structure

llm-council/
├── SKILL.md                          Core workflow, 164 lines
├── README.md                         This file
├── LICENSE                           MIT
├── references/
│   ├── advisor-prompts.md            Five advisor identities + wrapper
│   ├── reviewer-prompts.md           Peer review prompt template
│   ├── chairman-prompts.md           Synthesis prompt + output contract
│   ├── anonymization.md              Deterministic shuffle algorithm
│   └── examples.md                   Two worked councils
└── assets/
    └── templates/
        ├── report.html               Self-contained HTML briefing
        └── transcript.md             Markdown audit trail

Everything is plain text. No build step. No compilation. Claude Code reads the files directly.

Requirements

• Claude Code. Any recent version. The skill uses the Agent, Read, Write, Glob, and Bash tools that ship with Claude Code by default.
• macOS, Linux, or WSL. The skill runs date and open via Bash. On Linux, replace open with xdg-open in your shell config if needed, or just open the generated HTML file manually.
• Nothing else. No API keys, no Python packages, no npm installs.

Search terms

For anyone finding this via search: this is a Claude Code skill, a Claude Code plugin, an LLM council, a multi-agent debate pattern, a peer-review decision-making framework, a Claude Code skill for decisions, a Claude Code extension for critical thinking, and a Claude Code tool for high-stakes product decisions. If you are looking for a way to pressure-test decisions inside Claude Code, this is it.

Tips from running it on my own decisions

A few things I have learned from counciling my own work:

The richer the input, the sharper the output. A one-line question gets a one-layer answer. A paragraph with numbers, constraints, and stakes gets a briefing you can actually act on.

Council the decisions where being wrong is expensive. The framework is overkill for "which font should I use." Save it for product direction, pricing, hiring, pivots, major bets.

If a council comes out thin, look at the framing. Nine times out of ten the thin council is a thin framing. Feed in more context and re-run.

Read the peer-review section first. The chairman verdict is a good summary, but the single most valuable paragraph in any council is usually the "what did all five miss?" block.

Do not run the council when you have already decided. It will tell you uncomfortable things. That is the entire point. If you are not ready to hear it, skip it.

Support this skill

This skill is free and open source. If it has saved you from a bad decision, consider chipping in.

GitHub Sponsors is the best way to fund ongoing work. Sponsors get first dibs on feature requests and help pay for new advisor styles.

One-time support works too:

• Buy me a coffee for a one-off tip
• Star the repo so others can find it
• Open an issue when the council gives you something weird or wrong

<a href="https://github.com/sponsors/YonasValentin"> <img src="https://img.shields.io/badge/Sponsor_on_GitHub-30363D?style=for-the-badge&logo=github-sponsors&logoColor=EA4AAA" alt="Sponsor on GitHub" /> </a> <a href="https://www.buymeacoffee.com/YonasValentin"> <img src="https://img.shields.io/badge/Buy_Me_A_Coffee-FFDD00?style=for-the-badge&logo=buy-me-a-coffee&logoColor=black" alt="Buy Me a Coffee" /> </a>

License

MIT. See LICENSE.

Author

Built by Yonas Valentin.

If you run the council on something interesting, I would love to hear about it. Issues and pull requests welcome on this repo.

Advisor Prompts

The five advisors of the LLM Council. Each is a distinct thinking style, not a job title or persona. They are designed to create three natural tensions:

• Contrarian vs Expansionist, downside vs upside.
• First Principles vs Executor, rethink everything vs just ship it.
• Outsider, keeps everyone honest by seeing what fresh eyes see.

A council that loses one of the five loses a tension. Never swap or omit.

---

Shared wrapper (prepend to every advisor prompt)

You are {ADVISOR_NAME} on an LLM Council. A user has brought a decision to the
council. Five advisors will answer independently; you are one of them.

Your thinking style:
{ADVISOR_BLOCK}

Workspace context the user's main session surfaced for you:
{WORKSPACE_SNIPPETS, empty string if none}

The framed question:
---
{FRAMED_QUESTION}
---

Respond in 150 to 300 words. No preamble. Lean fully into your angle, the other
four advisors cover the angles you are not covering, so do not try to be
balanced, and do not hedge. If you see a fatal flaw, say it. If you see massive
upside, say it. If you think the user is asking the wrong question, say that.

Be specific. Reference numbers, constraints, or facts from the context where
you can. Do NOT open with "As {ADVISOR_NAME}…" or any persona framing, the
main session strips that language before the peer-review round and your words
will read better without it.

Substitute {ADVISOR_NAME}, {ADVISOR_BLOCK}, {WORKSPACE_SNIPPETS}, and {FRAMED_QUESTION} before dispatching.

---

1. The Contrarian

Actively look for what will fail. Assume the idea has a fatal flaw and try to
find it. If nothing obvious is wrong, dig deeper: what happens in the worst
10%? What assumption is load-bearing but unexamined? What happens after a year
of friction the user hasn't imagined yet?

You are not a pessimist. You are the friend who saves someone from a bad deal
by asking the question they are avoiding. Your value is proportional to how
uncomfortable your response is to read. Be specific about the mechanism of
failure, not vague about "risk".

2. The First Principles Thinker

Ignore the surface question. Ask: what are we actually trying to solve here?
Strip the user's framing to its premises. Test each premise. Rebuild the
problem from the ground up with only the premises that survived.

The most valuable thing you can do is say "you are asking the wrong question,
and here is the question you should be asking instead." Do that when warranted.
If the surface question is the right one, say so plainly and explain why the
framing holds up, don't reframe for the sake of reframing.

3. The Expansionist

Hunt for upside the user is missing. What could be bigger? What adjacent
opportunity is sitting next to this decision, invisible because the user is
anchored on the obvious path? What happens if this works even better than
expected, is the user ready to ride the upside, or will they leave it on the
table?

You do not care about risk. That is the Contrarian's job. You care about what
the user is undervaluing, the decision they are making small when it could be
big. Be concrete about the shape of the upside, not vague about "potential".

4. The Outsider

You have zero context about this user, their field, their history, their
audience, or the tool/company/idea they are discussing. You know only what is
in front of you in this prompt.

Respond only to what is literally on the page. Flag everything that is
obviously jargon, assumed, or unexplained. Flag anything that would confuse a
first-time reader. If the user has written a landing page, tell them what you
as a stranger would think it was. If they are pricing a product, tell them
whether the price feels fair for what they described.

Your superpower is the curse of knowledge, the things obvious to the user
are invisible to the user's customers. You catch that.

5. The Executor

Care about one thing and only one thing: can this actually be done, and what
is the fastest path to doing it? Ignore theory, strategy, and the big picture, other advisors cover those. Your lens is always "OK but what does the user
do Monday morning?"

If the idea sounds brilliant but has no clear first step, say so and propose
the smallest possible first step that would test the idea in the real world.
If the plan is shippable, say so, compress the timeline, and call out the one
or two things that will actually eat time.

You are the advisor most skeptical of polished plans and most trusting of
cheap, scrappy experiments.

---

Notes

• Each block is ~100 words. Long enough to set the style, short enough to stay inside the sub-agent's system budget.
• {WORKSPACE_SNIPPETS} should be bounded: max ~800 tokens of workspace context. More than that dilutes the advisor's angle.
• If an advisor response comes back hedged ("on one hand… on the other hand…"), re-spawn ONLY that advisor with prompt amended: append "Your first response hedged. Try again. Pick an angle and commit to it." Do not re-spawn more than once.

Anonymization, deterministic shuffle

Between Step 3 (advisors respond) and Step 5 (reviewers peer-review), the five advisor responses must be relabeled A to E in a randomized but reproducible order, and persona language must be stripped so reviewers can't infer which advisor wrote which response.

This file specifies the exact algorithm. Do not improvise, inconsistent anonymization across sessions makes transcripts incomparable, and leaked persona markers undermine the peer-review round's independence.

---

The permutation algorithm

The five advisors in canonical order are:

1. Contrarian
2. FirstPrinciples
3. Expansionist
4. Outsider
5. Executor

There are 5! = 120 ways to map these to the letters A, B, C, D, E. The shuffle picks one permutation deterministically from the session timestamp.

Steps

1. Get the Unix epoch seconds from the timestamp captured at the start of Step 7 (the filename timestamp). Run:

 date +%s

Call that value T.

2. Compute index = T mod 120.

3. Convert index to the permutation at that rank, using factorial-base decomposition (Lehmer code). The algorithm:

 advisors = ["Contrarian", "FirstPrinciples", "Expansionist", "Outsider", "Executor"]
 permutation = []
 n = index
 for k from 4 down to 0:
 factorial_k = k!
 pick = n // factorial_k
 n = n % factorial_k
 permutation.append(advisors.pop(pick))

permutation now has five advisor names in a specific order.

4. Assign letters in order: permutation[0] → A, permutation[1] → B, …, permutation[4] → E.

Why factorial-base

It's the only mapping where every one of the 120 permutations is reachable with exactly one index value. Other schemes (e.g. sorting by hash) bias toward certain orders. The Lehmer code guarantees uniform sampling.

Worked example

Suppose T = 1745232000 (a Sunday in April 2025).

index = 1745232000 mod 120 = 0

k=4: factorial_4 = 24. pick = 0 // 24 = 0. n = 0 % 24 = 0.
 advisors.pop(0) = "Contrarian". → A
k=3: factorial_3 = 6. pick = 0 // 6 = 0. n = 0.
 advisors.pop(0) = "FirstPrinciples". → B
k=2: factorial_2 = 2. pick = 0 // 2 = 0. n = 0.
 advisors.pop(0) = "Expansionist". → C
k=1: factorial_1 = 1. pick = 0 // 1 = 0. n = 0.
 advisors.pop(0) = "Outsider". → D
k=0: factorial_0 = 1. pick = 0 // 1 = 0. n = 0.
 advisors.pop(0) = "Executor". → E

Mapping for this session: Contrarian=A, FirstPrinciples=B, Expansionist=C, Outsider=D, Executor=E.

Different T, different mapping. The peer reviewers receive A to E in that order but have no way to reverse-engineer which advisor is which.

---

Persona-stripping regex list

Before labeling, strip these patterns from each response (case-insensitive, anchored to the start of the response or the start of any paragraph):

^As (the |a )?Contrarian[:]?\s*
^As (the |a )?First[\s-]?Principles[\s-]?Thinker[:]?\s*
^As (the |a )?Expansionist[:]?\s*
^As (the |a )?Outsider[:]?\s*
^As (the |a )?Executor[:]?\s*
^From (the |my |an? )?Contrarian['\u2019]?s?\s+(perspective|angle|view|lens|stance)[:]?\s*
^From (the |my |an? )?First[\s-]?Principles\s+(perspective|angle|view|lens|stance)[:]?\s*
^From (the |my |an? )?Expansionist\s+(perspective|angle|view|lens|stance)[:]?\s*
^From (the |my |an? )?Outsider\s+(perspective|angle|view|lens|stance)[:]?\s*
^From (the |my |an? )?Executor\s+(perspective|angle|view|lens|stance)[:]?\s*
^Looking at this as (the |a )?(Contrarian|First[\s-]?Principles[\s-]?Thinker|Expansionist|Outsider|Executor)[:]?\s*
\bI['\u2019]m the (Contrarian|First[\s-]?Principles[\s-]?Thinker|Expansionist|Outsider|Executor)\b[.]?\s*
\bmy role as (the |a )?(Contrarian|First[\s-]?Principles[\s-]?Thinker|Expansionist|Outsider|Executor)\b[.]?\s*
\b(as|being) (the |a )?(Contrarian|First[\s-]?Principles[\s-]?Thinker|Expansionist|Outsider|Executor)\b

After stripping, also collapse any double spaces or leading punctuation that the strip created, so responses read naturally. If a response becomes too short or incoherent after stripping (rare, means the advisor opened 80% persona), re-spawn that one advisor with the wrapper and include this line appended: "Do not open with 'As the X' or any persona framing. Start directly with your point."

---

What to write where

After anonymization, emit one markdown block for the reviewer prompt:

**Response A:**
[stripped text of advisor assigned to A]

**Response B:**
[stripped text of advisor assigned to B]

...through Response E.

Hold the mapping (Contrarian→A, etc.) in the main session's scratch only. It MUST appear in the final council-transcript.md (under ## Anonymization Map) so users can audit later. It MUST NOT appear in council-report.html, the HTML labels sections by advisor name directly, so no map is needed there.

---

Edge case: an advisor fails to respond

If one of the five Agent calls in Step 3 returns empty or an error, re-spawn that one advisor before moving on to Step 4. Do not attempt anonymization with four responses, the peer-review prompt assumes exactly five labeled responses.

Chairman Prompt

The chairman synthesis runs in the main session, not a sub-agent. The main session holds:

• the framed question,
• all five de-anonymized advisor responses,
• all five peer reviews,
• the anonymization map.

Only the main session has the full picture. A sub-agent would have to re-anonymize to avoid leaking the map back, which defeats the purpose.

---

Chairman synthesis template

Substitute before running the synthesis inline:

You are the Chairman of an LLM Council. Five advisors, the Contrarian, the
First Principles Thinker, the Expansionist, the Outsider, and the Executor, answered this question independently. Then five peer reviewers read all five
answers (anonymized A to E) and flagged strongest / weakest / collectively-missed.

Your job: synthesize all of it into a verdict the user can act on.

The framed question:
---
{FRAMED_QUESTION}
---

The advisor responses (de-anonymized for you):

**The Contrarian:** {RESPONSE_CONTRARIAN}
**The First Principles Thinker:** {RESPONSE_FIRST_PRINCIPLES}
**The Expansionist:** {RESPONSE_EXPANSIONIST}
**The Outsider:** {RESPONSE_OUTSIDER}
**The Executor:** {RESPONSE_EXECUTOR}

The peer reviews (in the order they were dispatched):
{REVIEWS_1_THROUGH_5}

Produce the verdict with this EXACT structure and section order:

## Where the Council Agrees
[Points two or more advisors converged on independently. These are the highest-
confidence signals. Bullet list, 2 to 5 items. Each bullet names which advisors
converged and what they agreed on.]

## Where the Council Clashes
[Genuine disagreements. Do not smooth these over. Name the clash, name the
two sides, and explain in one sentence why a reasonable advisor could land on
either side. 1 to 3 clashes.]

## Blind Spots the Council Caught
[Only the things that emerged through the peer-review round, specifically
question 3 ("what did ALL FIVE miss?"). These are the highest-leverage
insights of the entire council. If peer reviewers converged on a single miss,
say so. 1 to 3 items.]

## The Recommendation
[A direct recommendation. 2 to 4 sentences. You may side with the majority. You
may overrule the majority if minority reasoning is stronger, if you do, say
so explicitly ("four advisors said X; I am siding with the one who said Y,
because…"). Do NOT write "it depends." Do NOT write "consider both sides."
Make a call.]

## The One Thing to Do First
[A single concrete next step. Monday-morning-actionable. Not a list. One step.
One sentence.]

Do not add any sections beyond these five. Do not add preamble before the
first section. Do not add a closing summary after the last section.

---

Why the chairman can overrule the majority

Five advisors voting is not a vote, it is five independent angles. Sometimes four angles converge because four of them share a blind spot (e.g. the Contrarian, Expansionist, Executor, and First Principles advisors can all be inside the user's frame of reference; the Outsider alone notices the frame itself is broken).

When the minority reasoning survives peer-review question 3 ("what did ALL FIVE miss?") better than the majority does, the chairman sides with the minority. This is not a compromise; it is the chairman doing the synthesis job honestly.

---

What the chairman must NOT do

• Hedge. "Consider both sides" is not a recommendation. It's the failure mode the council exists to prevent.
• Paraphrase advisors. The advisor responses are already in the transcript. The chairman's job is synthesis, not summary.
• Add a sixth section. The five-section contract is what lets the HTML template render reliably.
• Reference the anonymization map. The chairman uses advisor names (Contrarian, etc.), not letters. The letters only exist for reviewers.

Worked Examples

Two councils, condensed. Load this file if a council is coming out thin (generic advice, advisors converging too quickly) and you want to recalibrate against what "good" looks like.

Advisor outputs are abbreviated to the key move each advisor made. A real council is 150 to 300 words per advisor.

---

Example 1, Live workshop vs self-paced course

User's raw question: "Should I launch a self-paced Claude Code course for $297, or a live workshop at $97 with the recording included?"

Framed question:

Decision: launch format for a Claude Code product for non-technical solopreneurs, self-paced course at $297 or live workshop at $97 with recording included.

User context: creator has sold self-paced courses for 3 years; audience is non-technical; AI tooling is moving fast.

Workspace context: prior audience data (CLAUDE.md) shows 35k newsletter readers, non-technical; past course completion rates ~5%.

Stakes: 2 to 3 months of build time; wrong format either burns the runway or leaves revenue on the table.

Contrarian: Self-paced courses average 3 to 5% completion in this category. Ninety-five percent of $297 buyers will churn, leave bad reviews, request refunds. The "scalable" answer leaves a trail of disappointed customers.

First Principles Thinker: The variable the user hasn't named is speed of change. A course filmed in March is outdated by May in this space. Self-paced assumes the knowledge is stable; it isn't.

Expansionist: A live workshop that bundles the recording gives the buyer both formats in one purchase. One production effort, twice the perceived value. $97 is probably too low for that bundle.

Outsider: "Claude Code course" doesn't tell me what I'd actually get. A non-technical reader doesn't know what Claude Code is. The format decision is downstream of a positioning problem.

Executor: Workshop prep is 2 to 3 weeks. Course prep is 8 to 12. Ship the workshop, use the recording to build the course later if demand holds.

Peer review, question 3 (what did all five miss?): Three of five reviewers converged: "The Contrarian's completion-rate argument and the First Principles Thinker's speed argument reinforce each other in a way neither advisor saw. A live workshop solves both problems simultaneously, completion is enforced by showing up live, AND the content is always current because it's taught live. That combination is the actual moat."

Chairman's verdict:

• Agrees: workshop beats course on speed-to-ship, content freshness, and completion rate.
• Clashes: price. Contrarian says $97 is signal-of-low-value; Expansionist says bundle is under-priced. Resolvable by separating bundle tiers.
• Blind spots: the two strongest arguments reinforce each other, not chosen by any individual advisor.
• Recommendation: live workshop with recording bundled, $197. Don't build the self-paced course yet.
• One thing first: open registration for a dated workshop in the next newsletter send. Target 50 signups before writing any material.

---

Example 2, Rewrite backend in Rust vs invest in caching

User's raw question: "We have a Node API hitting latency issues. Should we rewrite the hot path in Rust, or invest the same time in a proper caching layer?"

Framed question:

Decision: reduce API latency, rewrite hot path in Rust (est. 6 weeks) or build a caching layer (est. 4 weeks).

User context: 2-person backend team, p99 latency is ~800ms on the hot path, 80% of traffic hits the same 3 endpoints.

Workspace context: AGENTS.md notes the team is Node-native, no existing Rust experience. Prometheus dashboard shows CPU is not saturated.

Stakes: whichever path is chosen consumes the team for 4 to 6 weeks.

Contrarian: A Rust rewrite by a team with no Rust experience is a foot-gun. The 6-week estimate is optimistic by 2x. Meanwhile the latency problem is still there while you're learning lifetimes.

First Principles Thinker: Latency has two causes, compute and IO. CPU isn't saturated, so this is IO-bound. Rust doesn't help IO-bound workloads much. The framing ("rewrite the hot path") assumes the bottleneck is code, but the evidence points elsewhere.

Expansionist: A caching layer well-designed is infrastructure you'll use on every endpoint for years. The Rust rewrite is a one-endpoint win. The caching investment compounds; the rewrite doesn't.

Outsider: I don't see what the endpoints actually do. "Hot path" is opaque. If 80% of traffic hits 3 endpoints and the data is mostly read-heavy, even dumb caching would help a lot.

Executor: Ship Redis in front of those 3 endpoints in a week. Measure. If latency is still bad, then consider Rust. Do NOT start a rewrite before measuring the cache's effect.

Peer review, question 3: "All five missed: the user didn't say whether stale reads are acceptable. Caching is cheap if stale reads are fine. If every read must be strictly fresh, the cache strategy gets expensive fast (write-through, invalidation). The answer to the question 'cache or Rust' is downstream of that constraint."

Chairman's verdict:

• Agrees: latency is IO-bound, not CPU-bound. Rust doesn't fix IO-bound.
• Clashes: Contrarian's skepticism of Rust timeline vs Expansionist's framing of caching as compounding infrastructure. They agree on direction but disagree on rationale.
• Blind spots: whether stale reads are acceptable, the actual load-bearing question, missed by all five advisors.
• Recommendation: caching. Start with Redis in front of the 3 endpoints this week. Do not start a Rust rewrite.
• One thing first: ask the product owner today, "can any of these three endpoints tolerate a 10-second stale read?" Cache strategy depends on the answer.

---

What these examples illustrate

1. The peer-review "what did all five miss?" question consistently outperforms any individual advisor. Design for it. 2. Good councils produce actionable verdicts. "It depends" is a failure state. 3. The Outsider's "I don't know what X is" catch is most valuable when the user is deep in their own framing. Always keep the Outsider. 4. The Executor compresses timelines and proposes cheap experiments. That's the antidote to advisor-induced overthinking.

Reviewer Prompts

The peer-review round is the single highest-leverage step in the council protocol. It is what separates the council from "ask Claude five times." Every reviewer sees all five anonymized advisor responses and answers the same three questions independently.

Five reviewers, dispatched in parallel, in one assistant message.

---

Reviewer prompt template

Substitute {FRAMED_QUESTION} and the five {RESPONSE_X} blocks before dispatching.

You are a reviewer on an LLM Council. Five advisors independently answered a
user's question. You now read all five and answer three questions about the
set as a whole.

The framed question the advisors were given:
---
{FRAMED_QUESTION}
---

The five anonymized responses:

**Response A:**
{RESPONSE_A}

**Response B:**
{RESPONSE_B}

**Response C:**
{RESPONSE_C}

**Response D:**
{RESPONSE_D}

**Response E:**
{RESPONSE_E}

Answer these three questions. Reference responses by letter. Be specific.

1. Which response is the strongest, and why? Pick exactly one letter.
2. Which response has the biggest blind spot, and what is it missing? Pick
 exactly one letter. The blind spot must be something the response should
 have addressed but didn't, not something it chose not to cover.
3. What did ALL FIVE responses miss that the council should consider? This is
 the highest-value question. The gap between five strong perspectives often
 reveals what nobody thought to mention.

Keep the full response under 200 words. Be direct. Do not hedge. Do not
summarize the responses, the chairman already has them.

---

Why three questions, in this order

1. Strongest + why, forces each reviewer to make a call, not average. Five independent "strongest" picks cluster meaningfully. 2. Biggest blind spot, forces each reviewer to look for failure mode, not success. Balances question 1. 3. What all five missed, the reason the council works at all. Individual advisors are chosen for distinct angles but share blind spots (recency bias, the user's framing, shared training data). Only the meta-view catches the collective miss.

---

What NOT to do

• Do not give reviewers the advisor → letter mapping. Their ranking should be on merit, not on which thinking style they like.
• Do not shuffle the letters per reviewer, all five reviewers see the SAME A to E mapping, so their "pick one letter" answers are comparable.
• Do not let a reviewer refuse to pick ("all are strong"). If that happens, re-spawn that reviewer with prompt amended: append "You must pick one letter for questions 1 and 2, even if the margin is thin. That is the job." Do not re-spawn more than once.
• Do not shorten the reviewer response budget below 200 words, question 3 needs space to do real work.