expert-panellisted

# expert-panel A good brainstorm is several experts, each master of a domain, who bring their knowledge and argue toward a decision. Use this when a choice has **no ground truth to check against yet** — a design fork, an architecture call, a tradeoff. For anything that can be checked against an oracle, use `servo-gate` instead; this skill is for generating and stress-testing options, not verifying them. The failure this prevents: one model picking the first plausible option with false confidence, and a panel of same-context models agreeing with each other. Keep it visible: open a **TodoWrite list with one todo per expert** (plus the dissenter and the synthesis), and mark each `in_progress`/`completed` as it reports. The human should see the panel convene and resolve, not wait on a silent block. ## Procedure 1. **Frame the fork.** State the decision and the constraints from the context brief (`gather-context`). If there is genuinely an oracle that settles it, stop — this is a gate, not a panel. 2. **Convene the MINIMAL relevant set — usually 2-3, not every plausibly-related domain.** From the manifest's `experts`, pick only the ones the decision genuinely turns on (a data fork wakes the data expert; it does not need the bot expert). Convening six experts on a three-expert problem is the waste this step must avoid. **How to spawn an expert:** an expert is **not a named agent type** — do not try to spawn an agent called `data` or `hs-coaching` (it does not exist and wi