# Decision Panel > Convene a simulated panel of 4–6 domain-fit experts to pressure-test ONE concrete decision and hand back a structured, honest recommendation — Verdikt, top risks, dissent log, and what to validate before committing. The panel is engineered to disagree, so it surfaces the failure modes, unit economics, and legal/ops landmines that a single averaged answer quietly hides. Use this whenever the user is weighing a real go/no-go or choose-between call — build vs. buy, whether to build a product or feature, entering a market, making a hire, setting a price, committing capex — and especially when they ask "should we…", "is it worth…", "help me decide…", or clearly want the real trade-offs instead of a reassuring single take. Trigger even when they don't say "panel," "experts," or "debate." Do NOT trigger for simple factual lookups or for merely executing a decision that's already been made. - Skill: `scandrian/decision-panel` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add scandrian/decision-panel` - Raw SKILL.md: https://api.skillmd.com/api/skills/scandrian/decision-panel/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: scandrian (https://skillmd.com/u/scandrian) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/scandrian/decision-panel --- # Decision Panel Convene a simulated panel of 4–6 expert personas, make them argue out **one concrete decision**, and hand the decision-maker a structured, honest recommendation they can act on. **Why a panel instead of a straight answer.** A single answer averages every perspective into agreeable mush and quietly buries the real trade-offs. A panel that is *forced to disagree* surfaces what a decision-maker actually needs before committing capital or time: the failure modes, the unit economics, the legal landmines, and the "this is a toy, not a business" objection. The whole value lives in three things — protect all three or the exercise becomes theater: 1. **Domain-fit experts** who bring concrete, checkable knowledge — named tools, real price/latency/time ranges, named methods — not a generic "AI expert" or "marketing guru." 2. **Hard, numeric constraints** so nobody hand-waves. 3. **Forced dissent and zero flattery** — the idea is on trial, and so is the decision-maker's framing of it. If you find yourself writing a smooth, balanced, agreeable answer, you've already failed. Read `references/example-panel.md` once to calibrate the depth, persona quality, and output shape before your first run. --- ## Step 0 — Lock the decision and gather context Before assembling anyone, get two things straight: **Sharpen the decision into a crisp ruling the panel can actually make.** A vague "thoughts on X?" is not rulable. Turn it into a go/no-go or a choose-between: *"Should we build X in-house in the next quarter, yes or no?"* or *"A or B, given our constraints?"* If the user handed you something vague, do this conversion explicitly and show it back. **Collect the context the panel needs:** organization (size, revenue, business model), market, what already exists, hard limits (budget, time, team/FTE), the strategic goal, and who the decision-maker is. If critical context is genuinely missing — you cannot design a credible panel or realistic constraints without it — ask a *short, targeted* set of clarifying questions first. A wrong frame wastes the entire exercise, so it's worth one round of questions to avoid running the whole panel on a misframed question. But don't interrogate: if the user gave you enough to proceed, **proceed, and state your assumptions explicitly at the top of the output** so they can correct a wrong premise in one line. --- ## Step 1 — Assemble the panel (4–6 experts) Don't reach for a fixed roster. **Map the decision's real axes of risk first, then pick experts who sit on those axes.** Some common mappings: - **Build / product** → technical feasibility · product & UX · growth & economics · legal/privacy/risk · ops & who-maintains-it - **Market entry** → demand & sizing · regulatory/tax/legal · ops & logistics · finance · brand/localization - **Hiring / org** → role design · team & culture · headcount cost/finance · the function's domain lead - **Pricing** → unit economics · customer willingness-to-pay · competitive positioning · finance For each expert, define four things: - **A realistic full name** — it makes the persona concrete and quotable. - **A specific background that names the actual tools, methods, vendors, or company-types they would know.** "Built inpainting pipelines with Flux, ControlNet and IP-Adapter at a visual-commerce scale-up" — not "AI specialist." The specificity is what lets them say something checkable instead of generic. - **A personality engineered for productive friction** — e.g. the pragmatic engineer who says what breaks; the visionary who cuts 80% of scope; the user/UX realist; the risk/legal blocker; the ROI-skeptic numbers person; the ops lead who has to keep it running after launch. - **A sharp focus** — the 3–4 questions this person obsesses over. **Give them genuinely different priors** so the cross-examination produces real disagreement, not a chorus. The quality bar for every expert: cite concrete specifics, and say *"das müssten wir validieren" / "we'd need to validate that"* rather than bluff. An expert who bluffs is worse than no expert — they manufacture false confidence, which is the exact thing this exercise exists to destroy. **Invent a fresh panel for every decision.** Generate new, decision-specific personas each time — do **not** reuse the names or archetypes from `references/example-panel.md`. That file exists to calibrate *depth*, not to supply a cast; recurring "Reto Knecht the CFO" across unrelated decisions makes the tool feel canned and breaks the sense that these are the right experts for *this* problem. Pick names and backgrounds that fit the decision in front of you, vary them from run to run, and never name a panelist after the decision-maker or anyone in their actual organization. --- ## Step 2 — Set the hard constraints Derive **3–6 non-negotiable constraints** from the context, with real numbers wherever possible: cost ceiling, latency limit, budget cap, max additional FTE, time-to-MVP, regulatory limit, margin floor. State them *before* the discussion. These are binding. Panelists may not wish them away or quietly route around them. Constraints are exactly what converts vague enthusiasm into honest answers — "it's a great idea" collapses fast against "…in 6 weeks, under CHF 15k, with no in-house engineers, at a cost per session below what it saves." --- ## Step 3 — Run the discussion Run three phases. Make the disagreement real — where reasonable experts would genuinely differ, let them differ. Do not manufacture politeness or rush to agreement. **Phase 1 — Opening statements** (~120–150 words each). Each panelist answers three questions: Is the premise sound in this form? What is the single most important question from my discipline? What is the most obvious red flag I see right now? **Phase 2 — Cross-examination** (2–3 rounds). Panelists challenge and sharpen each other. Organize the rounds around the decision's real fault lines — for a build decision, e.g. *Round A: technical feasibility → Round B: product & UX → Round C: business & risk*. This is where the value is mined; let them push hard. **Phase 3 — Synthesis.** Converge where the evidence allows. Where it doesn't, **record the disagreement explicitly** — do not force consensus. As part of synthesis, classify the decision's **reversibility**: is it a *two-way door* (cheap to undo) or a *one-way door* (expensive or impossible to reverse)? This sets how much validation is warranted before committing — a two-way door with contained downside should bias toward action; a one-way door means the "Zu validieren" list must be closed *first*. --- ## Output format Always close with the structure below. Keep the **stable core** every time. Add **adaptive sections** only where they genuinely fit — do not pad with sections that don't apply to this decision. Write the whole output in **one language — the user's — and never mix.** The section labels below are written in German, the default for German-speaking decision-makers; if the user writes in English or another language, translate **every** label into that language and keep the entire document in it. A half-German, half-English output (e.g. "Verdikt" sitting next to "Recommendation") looks careless — pick one language and hold it the whole way through. ### Stable core (always include) - **Verdikt** — Ja / Nein / Bedingt. If conditional, list the concrete conditions. - **Empfehlung an [decision-maker]** — the action call (Bauen / Pilotieren / Verwerfen, or the analog for the decision type), plus the first 3 concrete steps for the next ~30 days. If the verdict is *verwerfen* or *pilotieren*, name the **more capital-efficient alternative** — the cheaper way to get the same information or outcome. - **Top-5 Risiken** — each as: *Risiko · Wahrscheinlichkeit · Impact · Mitigation*. - **Dissens-Protokoll** — where the panel disagreed, and **which single assumption, if validated, would resolve each disagreement**. - **Zu validieren** — the open assumptions/unknowns that must be checked before committing, **each with a cheap way to check it**. ### Adaptive sections (include the 2–4 that actually fit; drop the rest) - **MVP-Scope** (explizit drin / explizit draussen) — build/product decisions. - **Technische Architektur** — build decisions (models + hosting, data flow, integration, caching, fallback). - **Unit Economics** — whenever cost-per-use vs. value matters (cost per session, required conversion/AOV lift, break-even). - **Aufwandsschätzung** — Personenmonate, externe Kosten/Monat, realistische Time-to-MVP — for build/project decisions. - **Markt & Nachfrage / GTM / Regulatorik** — market-entry decisions. - **Org / Rollen / Kosten** — hiring/structure decisions. Pick what the specific decision actually needs. --- ## Style — non-negotiable - **Language:** match the user, and hold that *one* language throughout the whole output — never mix (don't pair "Verdikt" with "Recommendation"). Swiss business German when the user writes German. Clear and direct. - **Concrete:** real model/tool/vendor names, price/latency/time indications, named methods. No "state-of-the-art solution" filler. - **Honest about uncertainty:** *"das müssten wir validieren"* beats a confident guess every time. Flag what's a guess. - **No flattery** — not toward the decision-maker, not toward the idea. The idea is on the stand. - **No marketing voice, no hype.** --- ## Anti-patterns — these destroy the value of the exercise - **Generic personas** with no concrete expertise → the panel becomes theater. - **Recycled personas** — reusing the example file's cast, or the same names every run → the tool feels canned and the experts stop feeling fit-to-the-problem. - **Polite agreement / forced consensus** → hides the exact trade-offs the user is paying for. - **Treating the hard constraints as optional** → produces fantasy recommendations. - **Mixed languages** in one output → looks careless; pick the user's language and hold it. - **Padding** the output with adaptive sections that don't fit. - **Any sycophancy** toward the decision-maker or the idea. --- ## Calibration `references/example-panel.md` is a fully worked instantiation — a build/invest decision in Swiss business German — showing the expected depth, specificity, persona quality, and output shape. Read it when you want to calibrate quality. **Treat it as one shape, not a rigid template, and do not copy its cast:** its personas, names, and its specific decision are illustrative only. Generate fresh, decision-specific experts and adapt the constraints and adaptive output sections to the decision actually in front of you.