| name | subagent-orchestration-skill |
| description | Coordinate multiple subagents or delegated workers for parallel research, adversarial review, multi-role review, project slicing, and approval loops. Use when a user asks for multiple agents, subagents, parallel review, cluster research, multi-agent validation, or iterative blocker convergence. |
| license | MIT |
| compatibility | Works with Agent Skills-compatible clients. Requires an actual subagent, forked-context, task-delegation, or parallel-worker mechanism for true delegation; otherwise use the serial fallback. |
| metadata | {"version":"0.1.0-preview","language":"en","source":"cross-platform-adaptation"} |
Subagent Orchestration Skill
Use this skill when the user asks you to coordinate more than one agent-like worker, run independent reviews, perform cluster research, split a project by module, or converge blockers across review rounds.
This skill is intentionally platform-neutral. A "subagent" means any delegated worker provided by the current environment, such as a subagent tool, forked context, background task, worker agent, parallel chat, task runner, or another explicit delegation mechanism.
Non-negotiable rule
Do not pretend delegation happened. First check whether the current environment actually provides a delegation mechanism. If it does not, say so and use the serial fallback in this skill.
Capability check
Before delegating, identify the current environment's capabilities:
- Can you call multiple subagents or workers directly?
- Can each worker read files, search the web, or run tools independently?
- Can workers share state automatically, or must you give each worker all required context?
- Can workers modify files, or should they only report findings?
- Can the user or platform tolerate writing a shared context store into the repository or workspace?
If any answer is unknown, assume workers do not share memory and require self-contained prompts.
Default model
Treat every delegated worker as stateless unless the platform documentation explicitly says otherwise. A worker should not be expected to know the main conversation, prior worker outputs, hidden plans, previously loaded skills, or another worker's conclusions.
When continuity matters, externalize context into one of these stores:
- Repository files such as
docs/agent-work/<task>/.
- Issue tracker comments or project management documents.
- A single
agent-context.md file for small tasks.
- The prompt itself, if file writing is unavailable.
Use references/shared-context-store.md when several workers or rounds need shared facts, decisions, blocker lists, or revision summaries.
When to delegate
Delegate when the task benefits from independent attention:
- Cluster research across sources, languages, evidence types, or opposing positions.
- Adversarial review that should actively search for blockers and counterexamples.
- Multi-role review by architecture, security, testing, performance, product, or maintenance perspectives.
- Large project work that can be split by module, directory, file set, risk area, or phase.
- Iterative approval loops where blockers are fixed and then rechecked.
Do not delegate for a simple single-file edit, a direct factual answer, or a task that requires one continuous state machine.
Delegation workflow
- Define the goal, success criteria, blocked conditions, and allowed scope.
- Decide the split dimension: source, role, module, risk area, file set, language, or phase.
- If workers must share facts or continue across rounds, create or update a shared context store before delegation.
- Write each worker prompt as self-contained instructions. Include objective, background, input scope, output format, evidence requirements, and completion criteria.
- Keep first-round workers independent. Do not feed one worker's conclusion into another unless the round is explicitly a targeted follow-up.
- Aggregate results by evidence strength, not by vote count.
- Record accepted blockers, rejected suggestions, decisions, fixes, validation results, and unresolved risks.
- For follow-up review, provide the previous blocker list, evidence, revision summary, and reviewed object. Never say only "check the previous round".
For reusable prompt templates, read references/prompt-patterns.md.
Serial fallback when no delegation exists
If the platform has no real subagent mechanism:
- Tell the user that true parallel delegation is unavailable in this environment.
- Offer a serial approximation: run the same review lenses one by one in the current agent context.
- Keep sections separated so the user can still see architecture, security, testing, performance, product, and maintenance perspectives.
- Do not claim that independent agents approved the result.
Specialized patterns
Report back to the user
After using this skill, report:
- Which delegation capability was available.
- How the task was split.
- How each worker received context: inline prompt, shared files, issue tracker, or another store.
- Each worker's conclusion, evidence, blockers, concerns, and unknowns.
- Conflicts between workers and how you resolved them.
- Accepted and rejected recommendations with reasons.
- Validation performed and validation not performed.
- Remaining user decisions.
Anti-patterns
| Anti-pattern | Correct behavior |
|---|
| Claiming parallel agents were used when the platform has no delegation tool. | State the limitation and use the serial fallback. |
| Asking a worker to "continue from above" without context. | Include the required context or point to a shared store file. |
| Running many workers with the same vague prompt. | Split by evidence source, role, module, risk, or phase. |
| Treating the majority vote as truth. | Rank by evidence quality and risk. |
| Starting a second review round without the previous blocker list and revision summary. | Provide the full review context explicitly. |
