Coordinators

A coordinator is a long-lived agent that drives one mission — a feature, or a standing track of work — by breaking it into child issues, letting builders implement each, reviewing what comes back, and deciding what happens next. It does not write code itself. Most of the time it is asleep; it wakes when a piece of its work needs attention, acts, and sleeps again.

Child issues and the parent edge

A coordinator works by creating child issues and starting each on a recipe. Every child sets its parent to the coordinator's own issue. That edge is what routes the child's work back under the coordinator and wakes it when the child needs attention; a child created without a parent silently falls out of the mission.

Independent children run in parallel — the coordinator can spawn a whole batch at once, even when they touch the same files, because each runs on its own isolated branch. Only a true dependency is sequenced.

Waking on attention

A coordinator spends most of its life idle. What reaches it from the outside arrives as a wake: a pointer to the thing that needs it — a child's question, an opened pull request, a failed job, a message — carried at one of three levels. A passive notice never starts it; it waits and rides along the next time the coordinator runs for some other reason. A wake starts it while it is idle. An interrupt breaks into a turn already in progress. So a coordinator resumes when a child reaches a state that needs a decision — a child opened a pull request, a job failed, a branch hit a conflict, the user sent a message — reads what happened, decides whether the work is good, and acts: merging a reviewed child, spawning a follow-up, or going back to sleep.

Muting a child

When a child is ready for the user to test or polish directly, the coordinator can mute it. Mute is a downgrade, not a silence: the child's questions, reviews, and routine churn stop waking the coordinator, but they still ride along, folded into its next natural run. The next time something legitimately rouses the coordinator, it catches up on everything the muted child did in one pass — a catch-up digest — so it goes quiet without going blind. The mute holds until the coordinator lifts it.

The board

Each coordinator keeps a living board: a short document holding where the mission is and where it is going — the plan, and the link from each planned deliverable to the child issue that implements it. The board records authored intent (what is planned, deferred, or cancelled); mechanical status (which children are active, waiting, or complete) is derived live from the children themselves and shown alongside it, so the coordinator never hand-types status.

Merging a child

A completed child opens its own pull request. Merging that PR is what actually lands the child's commits and resolves the child issue, and the coordinator does it only after reviewing the work and confirming it is conflict-free. Marking a child "merged" without merging its PR is refused, because it would strand the child's commits.

Creating one

A coordinator runs on its own issue through a coordinator recipe. Its prompt and model tier are editable like any other agent, and edits take effect on its next wake. From there its whole life is the loop above: plan the first slice of children, sleep, wake on attention, act, and sleep again.