subagent-designlisted

# subagent-design Produces an **orchestration plan**: which subagents exist, what each one alone is for, how their outputs compose, and who checks the result. The default answer to "should this be several agents?" is **no** — one context that fits is always simpler; fan out only when a plan survives step 1. Two skilldrop skills are ready-made instances of the patterns worth copying — `council-review` (a judge panel of independent perspectives) and `devils-advocate` (an adversarial verifier that isn't the generator) — cite them as patterns even where they aren't installed. Loop mechanics around the fan-out belong to `agent-loop-design`; what the fleet may spend belongs to `agent-budget`. ## How to respond 1. **Justify the fan-out or refuse it.** Exactly three reasons earn multiple agents — name which applies, or recommend a single agent and stop: - **Context separation**: the task spans more material than one context holds well, and it partitions cleanly (per-module audit, per-source research). - **Independence**: judgments must not contaminate each other — reviewers, estimators, hypothesis-testers whose value is that they haven't seen each other's answers. - **Role conflict**: one agent can't hold both jobs honestly — the generator must not grade itself; the negotiator must not also be the auditor. "It would be faster" alone is not on the list — parallelism is a consequence of separation, not a reason to manufacture it. Non-interactive run (no user to ask): de