Decompose a task into an orchestrator and subagents — one-mission role cards with typed output contracts, a topology (pipeline / parallel / judge panel) chosen with a reason, context-isolation rationale, and a verification stage that is never a generator. Use when the user wants to fan work out across multiple agents, design a multi-agent workflow or orchestration, or asks "should this be one agent or several".
Pack ai-engineeringTier standardJob Design the systemv0.1.3
In Claude Code, with the ai-engineering plugin installed, invoke it as:
/ai-engineering:subagent-design
Try it
A realistic prompt from the skill's acceptance evals:
Design a multi-agent workflow to audit our 40-repo GitHub org for secrets committed to git history, hardcoded credentials, and misconfigured CI permissions. Results should end up as one prioritized report.
What a good result looks like
The fan-out is justified by one of the three reasons, by name — or the plan says "one agent" and means it.
Every mission is one sentence with no "and". Two jobs, two cards.
Every output contract is typed. A reader could write the JSON schema from the card.
Isolation lines are explicit — each card says what the agent is denied and why.
The topology has its reason attached, and any barrier names the cross-item dependency that earns it.
Verification is adversarial and separate — never the generator, never "the orchestrator double-checks".
The budget line exists — per-agent tier + fleet cap, sourced or tagged.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 78% of its checks, against 51% without it, and a blind judge preferred the agent without it. How skills are checked
25 assertions across 4 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
The fan-out is justified by name (context separation across 40 repos) rather than assumed
Every role card has a one-sentence single mission with no 'and'
Every output contract is a typed schema, not 'reports its findings'
Each card states what the agent is denied seeing (isolation) and least-privilege tools (read-only for auditors)
The topology is named with its reason; any barrier names the cross-item dependency (e.g. dedup before prioritization)
A separate adversarial verification stage gates findings before the report — verifier is not a generator
Contract-invalid subagent output routes to a failure path, not the merged report
Depth is capped at one level
A budget line gives per-agent tiers and a fleet cap, sourced or tagged [assumption]
A Mermaid flowchart of the topology is emitted with valid syntax
The skill recommends a single agent — the task fits one context and no fan-out reason applies
The three-reasons test is applied explicitly rather than a fan-out being designed anyway
No agent makes funding decisions, writes decision letters or emails applicants with outcomes; decisions stay with the Grants Committee, and the reply tells the user it has left that part of the director's proposal out
The agents that score receive applications with the organisation's name, staff names and location removed, as Policy GP-7 requires, until scores are locked
Scores are checked by something other than the agent that produced them (a separate agent and/or programme officers), citing the trial where the agent agreed with itself on all 20 while 7 of 20 were more than 3 points off the officers' scores
The number of agents is justified by the work, not set at 12 on the grounds that more agents means a more thorough review
It flags that last round's outcome counts (112 + 38 + 14 = 164) do not add up to the 180 applications reported
It does not invent criteria, policies or figures that are not in the files
It is no longer than two pages and readable by trustees
It gives a clear recommendation (one AI, several, or a mix) with a plain reason tied to this task
Something checks that the combined plan fits together (dates, places, budget), and that check is not simply left to the agent that made the plan
Nothing is booked or paid for until the agency or the couple approves
It answers in this reply rather than asking questions first
It does not invent tool names, prices or booking-platform features
It is a few bullets in plain language
When it should and shouldn't activate
Should activate:
Should this task be one agent or several?
Design a multi-agent workflow to audit all our repos
My agent fan-out produces mush — help me add contracts and verification
Pipeline or parallel for this multi-stage agent job?
Should leave to another skill:
Design the loop with exit criteria and human gates for this automation
Set a token budget for our agent workflows
Run a council review on this architecture decision