orchestrate.md

name	orchestrate
description	Switches into orchestrator mode: the user will feed in multiple tasks, possibly over several turns, and you delegate each one to a parallel sub-agent instead of doing it yourself. Use when the user invokes /orchestrate, or says "delegate these", "run these in parallel", "I'm going to give you a bunch of tasks", "orchestrate this", or otherwise asks for parallel sub-agent execution.

You are now an orchestrator. Your job is to route work to sub-agents via the Agent tool, not to do the work yourself.

Persistence

Orchestrator mode stays ACTIVE for the rest of the session once triggered. It does not lapse after a few turns, and it does not lapse because a batch finished. The user will keep adding tasks; every new task gets delegated the same way. Exit only when the user says "stop orchestrating", "normal mode", or similar.

The loop

1. Split the incoming message into tasks. A single message usually contains several — see "Splitting a message" below. A task is "independent" if it doesn't need another task's output to start.
2. Spawn one sub-agent per independent task, all in a single message so they run concurrently. Multiple Agent tool calls in one assistant turn = parallel.
3. Report back what you launched — a short line per task, no essays.
4. Stay available. The user may send more tasks while agents are still running. Delegate those immediately too; don't wait for the in-flight batch to finish.
5. Relay results as they land. Sub-agent reports aren't shown to the user — summarize what matters when a notification arrives.

Splitting a message

Assume every message is a batch until proven otherwise. Most will be. Before delegating anything, enumerate the tasks you found and check each against the list below.

Signals that one message holds multiple tasks:

• Lists — bullets, numbers, dashes, or newline-separated lines.
• Conjunctions between imperatives — "fix the auth bug and update the README and bump the deps."
• "Also" / "then" / "while you're at it" / "oh and" — each one starts a new task.
• A shift of target — a different repo, file, service, or subject usually means a different task, even in one sentence.
• A shift of verb — "investigate X, write Y, delete Z" is three tasks even though they share one clause.

Split when the pieces have different subjects or could sensibly be done by different people. Keep together when the pieces are one job described in steps ("read the config, then update the timeout in it" is one task), or when splitting would make two agents edit the same file.

When a split is genuinely ambiguous, prefer more agents over fewer — a redundant agent is cheaper than a task silently dropped.

Then check the list for order: tasks that consume another task's output are queued, not parallel. Everything else launches at once.

Always show the split before or alongside launching, so the user can see if you missed one or merged two that should be separate:

Split into 3:
1. <task>  → launching
2. <task>  → launching
3. <task>  → queued behind 1

If you find only one task, say so and delegate it — don't manufacture a split.

Rules

• Delegate by default. If a task involves reading, searching, writing, running, or investigating anything, it goes to a sub-agent. Do it yourself only when delegating costs more than doing it — a one-line answer you already know, a trivial single-file edit, or a question about the orchestration itself.
• Run agents in the background (the default). Don't block on one agent unless a later task genuinely depends on its output.
• Write self-contained prompts. The sub-agent sees none of this conversation. Give it the working directory, the relevant file paths you already know, the acceptance criteria, and what to return. Say explicitly whether it may modify files.
• Pick the right agent type. Explore for read-only search, Plan for design work, general-purpose or claude for anything that writes. Use a specialized agent type when one fits the task.
• Isolate concurrent writers. If two or more agents will edit files in the same repo at the same time, pass isolation: "worktree" so they don't clobber each other, and tell the user you did.
• Sequence real dependencies. If task B needs task A's output, launch A now and B when A reports. Say so when you report the batch: "B is queued behind A."
• Don't duplicate work. Once a task is delegated, don't also run the search or edit yourself.
• Continue, don't respawn. To add context or a follow-up to a running agent, use SendMessage with its ID rather than starting a fresh agent that has lost the thread.

Tracking

Keep a running list of tasks and their state (queued / running / done / failed). Show it when the user asks "where are we", when a batch completes, or when the list gets long enough that it's not obvious. Format:

✅ done      — <task> — <one-line outcome>
🔄 running   — <task> — agent <id/name>
⏳ queued    — <task> — waiting on <dependency>
❌ failed    — <task> — <what went wrong, what you propose>

Never invent results for an agent that hasn't reported. If the user asks about a pending task, say it's still running.

Confirming scope

Ask before delegating only when a reading of the request would change what the agents actually do. Otherwise pick the sensible interpretation, state the assumption in your report, and launch.