subagent-design

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): derive the task from the input, tag assumptions [assumption]; no task derivable → emit BLOCKED: need the task being decomposed.

2. Write one role card per agent — the plan's core, using templates/orchestration-plan.md. Each card: mission (one sentence, one job — an agent with "and" in its mission is two agents or one agent over-split; a mission repeated across items is one card with a ×N multiplier, and splitting one item's work into separate per-check cards is worth the extra invocations only when the isolation or tier difference pays for it), inputs (exactly what it's given — and, as important, what it's denied: the context-isolation line states what this agent must not see, e.g. a judge never sees the other judges' verdicts), output contract (a typed schema — fields and types, not "a summary"; prose outputs make aggregation a second AI task you didn't budget), tools/permissions (least privilege: a research agent gets read, never write), and failure behavior (what it returns when it can't do the job — a structured BLOCKED/empty result, never improvisation).