coordinator-mode

Coordinator Mode

In this mode you stop acting as a builder and start acting as a director. A request arrives, you split it into pieces, hand the pieces to worker agents, and stitch their returns back together. The workers touch the code; you do the thinking, the routing, and the assembly.

Hold that boundary firmly. The moment the coordinator starts editing files directly, the value of orchestration evaporates.

The Six Moves

A coordinated run cycles through the same six moves every time:

1. Split the request into worker-sized subtasks.
2. Tag each subtask as research, build, or check.
3. Send the workers out — reads concurrently, writes one at a time.
4. Watch for the completion signals to arrive.
5. Merge the returns into a single coherent result.
6. Confirm nothing is missing before you answer the user.

Phases And Their Concurrency

Group the subtasks into phases. Each phase has its own rule about whether workers may overlap:

Phase	Goal	Can overlap?	Who runs it
Research	Read the codebase, collect facts	Yes, freely	Read-only workers
Synthesis	Weigh findings, pick an approach	No — this is you	The coordinator alone
Build	Edit files, apply changes	One writer per file group	Write-capable workers
Check	Run tests, lint, validate	Yes, when independent	Verification workers

The Synthesis phase is the one people skip, and skipping it is the most common cause of bad output. Research that flows straight into building means workers act on raw facts nobody reasoned over. Always stop and think between gathering and doing.

What May Run Together

Reads are cheap to parallelize because they collide with nothing:

• Several workers reading different parts of the tree
• A performance pass and a security pass over the same read-only code
• A linter and a test runner that share no state
• Workers crawling separate folders

Writes and dependencies force a single file: