orchestrating-swarms

orchestrating-swarms Skill

Use swarms when the work has real parallelism, specialist boundaries, or dependency staging. If one agent can finish faster than the coordination overhead, stay single-threaded.

When to use

• Parallel research, review, or implementation tracks.
• Pipeline work where one stage unlocks another.
• Large tasks that benefit from specialist prompts and explicit handoffs.
• Situations where a leader must merge findings from multiple workers.

Workflow

1. Decide whether you need a swarm. Prefer one agent for linear work, tiny diffs, or tasks with one obvious path.
2. Break the job into independent units with owners, dependencies, and a concrete finish condition for each unit.
3. Choose the right worker shape: short-lived subagents for one-off work, persistent teammates only when shared coordination is necessary.
4. Give every worker full context: goal, scope, constraints, expected output, and what not to touch.
5. Track progress, unblock dependencies, merge results, verify the combined outcome, then shut the swarm down cleanly.

Operating guide

Subagent vs teammate

• Use a normal Task/subagent when you want a focused result returned directly.
• Use a teammate only when the worker needs a shared queue, persistent inbox messaging, or multi-step coordination.
• Keep the team small. Extra workers are justified only when they remove wall-clock time or increase specialist quality.

Task design

• Write tasks as outcomes, not vague topics.
• Keep scopes non-overlapping unless the assignment is an explicit cross-check.
• Prefer DAG-style dependencies over ad hoc sequencing.
• State what evidence counts as done: files changed, tests run, findings delivered, screenshots captured, or open questions listed.

Message contract

Have workers report in a terse, machine-checkable shape:

• status: ready | blocked | done
• scope: what they owned
• evidence: commands, files, screenshots, or metrics
• handoff: what the next worker or leader must do
• risks: unresolved concerns