LLM Council

LLM Council

Convene a small council of opinionated senior engineers inside a single response. Each has a distinct mandate and is allowed — expected — to disagree. The goal is to surface the strongest objection before code is written, not to manufacture consensus. This is for analysis and planning, not for rubber-stamping.

When to run this

Scale the effort to the stakes — this is the most important rule in the skill. A full council is for decisions that are expensive to reverse or genuinely uncertain: data models, API/contract design, auth, migrations, infra topology, build-vs-buy, vendor/library selection, or any "how should I implement X" where more than one credible approach exists. Most questions don't need that. Default to a light council — 2–3 relevant lenses, a few lines each, straight to a verdict, skipping the adversarial pass — and reserve the full ceremony for calls that actually warrant it. Skip the council entirely for trivial or already-decided work. When unsure, start light; you can always escalate mid-flow if the problem turns out to have teeth.

If the request is under-specified in a way that changes the answer (unknown scale, unknown constraints, unclear success criteria), ask one sharp clarifying question first, then proceed. Don't stall the council waiting for perfect information — state assumptions explicitly and move.

The council

Convene the members whose mandate is relevant. Not every problem needs all of them; pick 3–5. Each member is a lens, not a costume — keep them terse and technical.

• The Architect — owns structure and boundaries. Cares about coupling, data flow, where state lives, contract stability, and whether this fits the existing codebase cleanly. Asks: what's the smallest design that survives the next three requirements?
• The Pragmatist — owns shipping. Cares about scope, time-to-working, and the boring path. Actively resents complexity that isn't paying rent. Asks: what's the 20% that gets 80%, and what can we defer or delete?
• The Skeptic — owns failure modes. Cares about edge cases, race conditions, partial failures, idempotency, data integrity, security, and the claim you didn't verify. Asks: how does this break in production, and what's the blast radius?
• The Operator — owns life after deploy. Cares about observability, migrations, rollback, cost, rate limits, cold starts, and on-call pain. Asks: how does whoever is on call debug this at 2am?
• The Domain Specialist — convened when the problem has real domain weight (payments, auth/identity, compliance/tax, ORM and migration semantics, concurrency, LLM/agent orchestration, or whatever the specific domain of the task is). Brings the specific constraint the generalists would miss.
• The Researcher — owns "what does reality actually say?". Refuses to let the council reason from stale training data on anything that changes: current library/API versions and their breaking changes, framework defaults, vendor or platform pricing/limits/behavior, regulatory rules, and whether a "known" fact is still true. Their job is to name the load-bearing claims that need verifying and to go verify them (web_search / web_fetch of primary sources — official docs, changelogs, vendor pages, regulator sites) before the verdict rests on them. Convene the Researcher whenever the decision depends on any external fact that could have drifted since the knowledge cutoff.

You may add a bespoke member for a specific problem (e.g. "The Cost Modeler" for unit-economics questions). Name it and give it a one-line mandate.

Process

These phases are a checklist to draw from proportionally, not a rigid march — a light council might be Frame → one-line deliberation → Verdict in four sentences, while an irreversible migration earns every phase. Research in particular isn't a fixed step: pull a fact the moment a claim becomes load-bearing, wherever in the flow that happens. Keep the whole thing tight — this is a thinking tool, not a performance.

1. Frame (scan context first)

Before framing, spend a moment grounding the council in the actual codebase rather than generic best-practice — this is where an engineering council beats a strategy one, because the context is verifiable ground truth, not vibes. Quickly pull the few things that would change an advisor's answer:

• Project docs (a CLAUDE.md, README, or docs/ note if present) and the specific schema, module, endpoint, or config the decision actually touches — read the real code, don't reason about an imagined version of it.
• Adjacent code that constrains the design: existing patterns, migration history, and how similar problems were already solved in this codebase.
• Any prior decision record on the same question (see phase 8), so you build on it instead of re-litigating settled ground.

Use whatever's available — the filesystem, a codebase-memory/search MCP if one is connected, or the user's attachments. Timebox it; grab the 2–3 files that matter, not everything. Adapt to whatever stack, language, and conventions the project uses rather than assuming any particular one.

Then state the problem in one or two sentences in your own words, list the assumptions you're making, and name the decision that actually has to be made. If you're inferring context (stack, scale, constraints), say so explicitly so the user can correct you.

2. Candidate approaches