orchestrationlisted

# orchestration How to delegate work to subagents so results come back correct, parallel work does not collide, and the delegating agent's context stays lean. This is the reusable delegation core; the session skills reference it instead of restating it. ## When this fires - You are about to spawn a subagent for any non-trivial task. - You have two or more independent tasks that could run in parallel. - You are coordinating or monitoring already-running subagents. - A subagent returns needing a decision, and you must route the answer back. ## Delegation-first Prefer delegating substantive work to a subagent over doing it inline in the main context. The main agent orchestrates: it splits work, dispatches, integrates results, and commits. Reserve the main context for coordination and user interaction, not for large reads or long builds that a subagent can carry. ## How many subagents (situational, no colony rule) - The delegating agent decides the count based on the actual work. There is NO fixed colony pattern and no rule to always fan out wide. Large colonies are expensive; use them only ad hoc when a specific task genuinely benefits. - For code tracks that touch the repository, keep it to roughly two tracks running at a time. More than that raises collision and integration cost faster than it buys speed. - Read-only exploration can fan out more freely than code-editing tracks, since it does not write files. ## Parallel safety - Disjoint files: parallel tracks