llm-councillisted

# 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 m