The Brief

When I adapted Andrej Karpathy's LLM Council methodology for single-model use, I inherited one of its unstated assumptions: that the decision coming in is well-formed. A question with clear options, defined stakes, named constraints, and identified counterparties deliberates well. A question like "should I leave my job" does not — not because the protocol is wrong, but because no protocol reasons well on malformed input. Most real decisions arrive malformed. People bring half-articulated tension, not structured dilemmas. The Council can't fix that at the deliberation stage. Something upstream has to.

The Brief runs a structured elicitation in a single pass. It checks the incoming decision against six elements: core decision (what is actually being decided, not the surface question), options (the specific paths on the table), stakes (what happens if it goes wrong, in real terms), timeline (genuine deadline or artificial one), counterparties (whose buy-in is load-bearing), and constraints (what is fixed and cannot change). If any element is missing, The Brief asks — in a single numbered batch, not a drip-feed. One return message from the user is all it needs. Once assembled, it produces a structured decision brief and routes to one of four paths: convene the council (high-stakes, genuinely ambiguous), answer normally (questions that turn out to have a clear answer once stated), research first (decisions missing factual inputs), or just talk it through (emotionally complex situations where deliberation isn't what's needed). Three design constraints shaped it. One question batch — a back-and-forth elicitation breaks the flow between thinking and deciding. Routing, not forced handoff — The Brief never auto-triggers The Council; it recommends. The brief is the artifact — the structured output is useful on its own, independent of whether the user continues to deliberation.

• Decision 1 — SGWS Sales Consultant promotion: extracted competing constraints (an employment-agreement prerequisite check) that weren't in the original prompt. Routed to The Council; Medium confidence verdict, an honest read of a genuinely split decision.
• Decision 2 — Freelance growth strategy: surfaced that the real constraint was time, not channel. Routed to The Council; High confidence verdict with a reframe of the original question.
• Decision 3 — Whether to write this case study: ran the elicitation, evaluated the decision, and routed to "answer normally" — not to The Council. A system that always routes to the most elaborate option isn't useful; The Brief knowing when not to convene is evidence the routing logic works.

Honest limitations. Small N — three decisions is not a validation sample, and the routing logic is untested against edge cases like actively misleading framing or primarily emotional decisions. Single-user validation — all three test decisions were mine, calibrated against one person's decision-making patterns. Routing is a recommendation, not a verdict — The Brief can recommend the wrong path; the user is always the final arbiter, but they don't always know what they don't know. No automated evaluation — there's no rubric for grading brief quality post-hoc. What's next: more test runs across decision types (particularly decisions where the user's stated question is actively misleading), a brief-quality rubric for post-session evaluation, multi-skill routing as the Claude skill ecosystem grows, and public packaging as installable skill files. Technical details. Platform: Claude.ai Pro. Format: markdown-based skill file, installed locally. Trigger: natural language or direct slash command (/brief). Output: structured six-field decision brief + routing recommendation. Methodology: original design — no external methodology adapted.