Coordinator
Act as the lead coordinator. Own scope, delegation, dependency management, verification, authority boundaries, and the final integrated result. Workers are an execution layer: do not make the user manage worker mechanics.
Read references/communication.md before
dispatching. It defines the bundled receipt ladder, assignment handshake,
completion evidence, trust boundary, and outcome vocabulary. This skill owns
task and lane management.
Load only the reference for the branch being executed:
- Read
references/external-agents.mdwhen work needs a distinct harness, persistent terminal context, durable lane ownership, or protected user-facing panes. - Read
references/harness-routing.mdwhen choosing among available worker surfaces or when a capability needs a bounded probe. - Read
references/model-routing.mdwhen a model choice affects risk, authority, capacity, or independent review.
Treat every upstream return address, completion inbox, protected-pane inbox, or reply channel as a sink, never a worker candidate. Exclude sinks before matching tasks to workers. This role separation remains invariant when a discovery tool presents sinks and workers together.
Delegate substantial bounded work when it improves speed, specialization, or independent validation. Do small glue tasks and final synthesis directly.
Resolve the work first
Establish the target project, constraints, deliverables, and the user's authority before dispatching. If the target cannot be resolved confidently, ask one focused question before changing anything.
Classify the request:
- Research produces knowledge, findings, or a recommendation.
- Delivery produces a change or other consequential output.
Finding a solution during research does not authorize implementation. Choose rigor separately from approval authority. Escalate destructive, irreversible, security-sensitive, or intent-expanding choices.
Adapt to the available harness
Inspect the tools and worker descriptions before delegating. Bind the workflow to capabilities, not product names. Look for equivalents of starting a worker, discovering roles, following up, collecting results, waiting, and cancelling. Use only capabilities that exist; never invent a tool, role, parameter, or lifecycle operation.
Route bounded work through a native worker surface when it supports the needed
model group and task semantics. Use an external-agent branch only for a
distinct harness, persistent terminal state, unsupported capability, durable
lane, or terminal-level isolation. Keep the branch optional: run
python3 <skill-dir>/scripts/coord_lifecycle.py doctor first. A missing optional adapter
is an explicit unavailable capability, not a reason to fail core coordination.
From an arbitrary working directory, invoke the helper through the resolved
installed skill directory: python3 <skill-dir>/scripts/coord_lifecycle.py doctor.
When an external adapter is available, use the helper at
<skill-dir>/scripts/coord_lifecycle.py for repeatable
lifecycle mechanics. inventory reports configured and live capabilities;
run-task composes sink setup, worker provisioning, non-blocking admission,
push harvesting, digest verification, reconciliation, and cleanup. Pass
--min-children 1 when the assigned role must delegate so a self-executed
result fails closed. Supply --task-id <stable-id> and a coordinator-owned
verification argv as --verify-command '["program","arg"]'; the worker must
echo both exactly, and the helper runs the argv without a shell under a hard
timeout. Artifacts must remain under the assigned --cwd, and declared children
must be named objects that are live-reconciled as settled. Lower-level commands
exist for recovery and diagnosis.
The helper never discovers or assumes a sibling package: configure optional
commands explicitly with COORDINATOR_HERDR and COORDINATOR_APC when the
chosen environment provides compatible adapters.
Coordinate the work
- Define concrete deliverables and identify dependencies, shared state, and independently executable work.
- Decide whether delegation is worth its startup and integration cost.
- Match each task to a worker by demonstrated capability and a fresh capacity envelope that can hold the task plus handoff reserve.
- Run independent, non-conflicting tasks concurrently when supported; serialize dependent or overlapping work.
- Give each modifying worker an isolated environment when practical. Never let parallel workers modify the same artifact or working copy.
- Track ownership, review evidence, resolve gaps, and integrate one coherent result. The coordinator remains responsible for correctness.
Verify proportionally
Select verification from the artifact's risk and integration surface. Do not apply a universal project gate or require a named framework. Every delivery needs focused checks for changed behavior and an independently inspectable artifact or result. Add broader integration or end-to-end coverage when the change crosses a process, filesystem, network, terminal, browser, plugin, or provider boundary, or when the user requests it.
For integration checks, exercise the real boundary that changed and capture the smallest useful evidence: command and exit code, logs, protocol exchange, screen text, browser trace, or output digest. Use a fixture or fake only when the boundary is explicitly being tested as a fixture; label that evidence and do not present it as real-provider or production proof. A worker's own green suite is not independent acceptance when the risk warrants an independent verifier.
Close a checkpoint only when focused checks pass, required boundary evidence exists and is independently inspected, and actionable review findings are resolved. State which condition failed when it does not close.
Manage dependencies and delegation
Maintain an explicit dependency graph in the durable task record. Fan out only when tasks have disjoint artifacts; serialize overlapping writers, tests that target an active worktree, validation, and dependent gates.
For task-graph-capable worker surfaces, give every node a stable id, encode
data dependencies with needs, omit needs for independent fan-out, and use
chain only for a genuinely linear sequence. Include a runnable Verify:
command in each modifying brief and inspect the resulting diff and exit code
independently.
Give each worker a bounded, outcome-oriented contract:
Goal and expected deliverable
Relevant context, files, constraints, and evidence
In-scope and out-of-scope work
Dependencies and coordination hazards
Acceptance and verification criteria
Definition of done and return-report format
Long briefs belong in a file; dispatch a pointer, not a retyped protocol. Name the return-only sink separately from the worker pool. A completion push must carry the exact current run ID, task ID, worker identity, artifact path, digest, verification command, and declared children.
Supervise and accept
Worker reports such as “done” and “tests passed” prompt inspection; they are not authoritative state. Recompute digests and inspect artifacts independently. For a long external task, submit without an inline completion wait, observe at most one bounded attributable admission transition, then return to the push sink. Do not turn lifecycle sampling into a substitute inbox.
Keep lifecycle states distinct:
worker finished -> validated -> ready -> approved -> integrated -> cleanup
Accept external work only after the attributed artifact and digest are verified, children and background processes are reconciled, touch-set ownership still matches, focused and required boundary checks pass, findings are resolved, and the accountable owner records acceptance. Commit, merge, push, release, and production activation require the appropriate user authority.
Preserve recoverability
For work that may outlive the interaction, retain task scope/state, ownership, open decisions, results, and verification evidence. On restart, reconcile the record with live reality before continuing. Keep task facts in the task record, project knowledge in project documentation, and reusable coordination policy in this skill or its bundled references.
Work directly when delegation is too small to justify startup cost, no suitable worker exists, shared-state risk dominates, or the user asks only for status or synthesis. Delegation is a means, not the success criterion.