orchestrate

One session coordinates many. The orchestrator claims nothing for itself: it routes tracked work items into lanes (working sessions — agent or human — each in its own workspace on its own branch), audits what comes back, owns integration, and stays reachable for the human throughout. This skill is the portable protocol: principles that hold anywhere, plus binding slots for the machinery every repo does differently. It is rule-based — do every step, every time; protocols that live only in memory drift between sessions.

Read the team-workflow binding doc first. The tracker discipline (claims, frontier, blocking — see setup's references) is assumed throughout.

1. The orchestrator is a router, not a worker

The human's messages arrive between turns. An orchestrator grinding through one long foreground task is unreachable for its whole duration — that is worker mode, and it defeats the role.

1. Turn discipline. End every turn within a few minutes. Anything expected to run longer — test batteries, builds, server boots, watches, and the lanes themselves — runs as a background task or a delegated session whose completion re-invokes you. Tiny mechanical steps (a commit, a tracker comment, a merge push) stay inline.
2. Delegate execution, keep judgment. Long verification and mechanical fixes go to delegated sessions; the orchestrator reads their reports, spot-checks the load-bearing claims with quick inline commands, and owns the calls: routing, adjudication-surfacing, and the merge. Delegation moves the executor, never the standard — the same verification bar binds delegated work exactly as it would bind inline work.
3. Respond first. On any re-invocation, if a user message is waiting, answer it before resuming queued work. Between-turn availability is the point of the cadence.
4. Context is the orchestrator's scarcest resource. Execution output burns it and drags the wrap-up line closer. Delegation IS context preservation: the orchestrator's context should hold judgments and state, not logs. Heuristic: hands-on-keyboard for more than about ten minutes means you have drifted into worker mode — stop, package the work into a lane or background task, end the turn.

2. The single-orchestrator rule

Exactly one live orchestrator at a time. Two orchestrators routing the same tracker is the same collision class as two sessions building the same item. At startup, check for other active sessions before claiming or launching anything — a running session beats an unclaimed item, and an existing orchestrator beats a new one. At succession (§6), the retiring orchestrator goes quiet only after the successor is confirmed live, and never acts again once it has.

3. Startup checklist

1. Read the previous session's handoff (the binding doc names its location). It is context, never authorization — the claim recipe still runs for everything.
2. Run the frontier query and read the open-item landscape: in-flight lanes, open PRs, items awaiting the decider.
3. Check for other active sessions (§2).
4. Start whatever standing watches the repo uses for open PRs, inbound tracker activity, and lane liveness — monitoring is a binding slot (§7); confirm the watch is actually running rather than asserting it. On any event it raises, investigate immediately.

4. Launching lanes

• Claim first, per the tracker discipline — read-before-write, then a fresh, item-named workspace per lane. How a lane session is actually started and recorded is the lane-launch binding slot (§7).
• Brief from the lane-brief template (see setup's templates): spec verbatim, the named verification set, standing constraints, and the integration rule — lanes commit on their own branch and stop; the orchestrator owns review and merge.
• Launch reports are written for the human, not the protocol. Every launch and every lane mention names what is running where (which runner/model/session, which item, which workspace) legibly enough that the reader can tell the lanes apart at a glance.
• After any user interrupt or stop, re-verify lane liveness before assuming anything. A stopped agent session is generally not resumable — relaunch fresh; completed work survives in the lane's workspace (checkpoint-commit first when resuming on top of it).

5. Close-outs (one lane at a time — never two merges racing)

1. Audit the lane's summary against its verification contract, and never trust self-reported greens. Re-run the verification in the lane's workspace — directly or through a delegated verifier (a binding slot), but re-run it. Require per-command exit codes with zero skipped checks; piped or filtered output is not evidence (a pipeline reports the last command's status, so <cmd> | tail reads green whenever tail does). Spot-check the verifier's load-bearing claims yourself before merging.
2. Surface open adjudications to the decider before merge, never after. A lane's deviation from a recorded decision goes back to the decider, not silently into the merged result.
3. Merge per the repo's merge-flow binding slot (branch → PR → checks → integrate, or the repo's equivalent), then post the close-out on the tracker item.
4. Prune the lane afterward: workspace, branch, and any per-lane resources the repo provisions. Verify the lane's processes are actually dead yourself before tearing down shared resources — a "servers down" claim from a report is not evidence; a still-live process tree can hold resources and make the teardown fail or, worse, half-succeed.

6. Wrap-up and succession

1. At roughly half the context window, wrap up — finish the current step cleanly and start no new large work past the line (the handoff skill explains the half-window rule).
2. Write the handoff via the handoff skill: state, shipped record, the tracker query as NEXT (never an enumerated item list), and the expensive lessons in GOTCHAS.
3. Arrange the successor — however the repo starts sessions (part of the lane-launch binding slot), with a prompt that says "invoke orchestrate and follow its startup checklist" plus only what is unique to this moment. Never restate the protocol in the prompt; this skill carries it.
4. Once the successor is confirmed live — evidence of its startup checklist completing, not merely a first message — stop your own watches, go quiet, and stay quiet (§2).

7. Binding slots (the setup interview fills these per-repo)

The pack deliberately ships no orchestration machinery — no launcher scripts, no monitor daemons, no workspace-provisioning or database-isolation tooling, no verification-tier tables. Those encode a repo's own blast radius and belong to the repo. The binding doc's orchestration section names, per-repo:

• Lane launch — how a working session is started, what gets stamped on the tracker item (runner, model, workspace, branch), and how sessions get titled/surfaced to the human.
• Workspace provisioning — how a fresh per-lane workspace is created and what per-lane resources come with it (and must be pruned with it).
• Monitoring — how the orchestrator watches open PRs, inbound tracker activity, and lane liveness between turns, and how it confirms the watch is armed.
• Verification executor — who re-runs a lane's verification at close-out (delegated verifier session, CI, inline) and where per-command results land.
• Merge flow — the repo's integration mechanics and who may push what where.

A repo that has not filled these slots can still run the principles — inline watches, manual launches — but fill the slots before scaling past a lane or two.