Delivery Orchestrator

A skill for choosing skills. Once your harness grows past a handful of skills, the agent needs a way to select the right one. This is that skill.

The orchestrator has three jobs: decompose work into the smallest independently executable units, route each unit to the skill that owns it, and keep the delivery records honest — because a plan nobody can trust is worse than no plan, and it takes longer to discover.

When to use

• Starting a new epic or multi-track piece of work
• When an agent is about to attempt everything in one context window
• When parallel execution across multiple agents is needed
• When you need to decide which skill applies to an incoming task
• When the records have drifted — a status file that stops before today's work, a roadmap asking for a decision already made, a tracker claiming gated with nothing that walks it

The delivery records — the baseline

One fact, one owner. Four artefacts carry delivery state, and each answers exactly one question. Full doctrine, including the issue template and the audit: docs/DELIVERY-RECORDS.md.

The four rules that keep them from drifting:

1. ROADMAP owns build order. Where another document disagrees about what is next, the roadmap wins.
2. CHANGELOG records the proven, not the intended. A changelog of intentions reads as evidence, which makes it worse than none.
3. An issue not filed is not started. The tracker is current before the code, because the failure this prevents is work that accretes from a small fix and is reconciled afterwards, if at all.
4. gated means a test proves a user can reach it; shipped means a person used it. These two are the ones routinely overclaimed. Code existing is built, and deployment is not shipping.

Golden-thread ownership

For intake, dispatch, scope changes and completion, follow the golden-thread section of the adopting project's DELIVERY-WORKFLOW.md, located by its profile. Without an adopted workflow, start with operating-model-bootstrap in the consumer project. Use the workflow template as a checklist while mapping existing records; unresolved placeholders are project questions, not executable paths or permission to invent defaults. Product Owner maintains accepted intent and priorities; CXO provides material oversight; test strategy corroborates coverage. The orchestrator actions and reconciles the tickets, dependencies, status and delivery links. Check in-flight owners before selecting roadmap work.

Procedure

Part 1 — Decomposition

1. Read the spec or brief — confirm a feature spec or HLD exists. If not, invoke spec-first-delivery first.
2. Identify tracks — group work into independent tracks (e.g. backend API, frontend, infrastructure, testing). Tracks can run in parallel. Dependencies between tracks must be explicit.
3. Break each track into atomic tasks — an atomic task is one that:
   • Can be assigned to a single agent
   • Has a clear input and a clear output
   • Does not require coordination with another concurrent task to complete
   • Can be validated independently
4. Sequence dependencies — where task B requires output from task A, mark the dependency. Everything else is parallel.
5. Assign context boundaries — each agent gets only the context it needs. Avoid stuffing all specs into every agent's context.

Part 2 — Skill routing

1. Map each task to a skill using the routing table below. If no skill matches exactly, use the closest and note the gap.
2. Validate integration after parallel work — run the full regression suite (make check or the project's equivalent convergence command) after all parallel tracks complete. Parallel work that skips integration validation is not done.

Skill routing table

Adoption and review recovery

Use the adoption guide to reconcile conversational requirements, skill maintenance ownership, early operational dependencies and measured improvement. Preserve one integration owner and include review/integration in WIP.

Before consequential review declare the work-item attempt/time ceiling. On repeated findings or exhaustion, follow Council loop recovery; changing candidate or reviewer never erases unresolved findings or spent attempts.

Outputs

For workflow audits, maturity exits or reconciliation across records, read references/workflow-audit.md. It defines the vision-to-observation thread, evidence levels, test strategy, promotion and value feedback. Distinguish declared, implemented, enforced and observed controls. Track lane identity/effort, mutation boundary, budget, expected output and acceptance command; check actual lane health before reporting progress. A registry entry is not proof that a model or reviewer ran.

• Task breakdown: tracks, atomic tasks, dependencies
• Skill routing: task → skill mapping
• Parallel execution plan with integration validation step
• A brief orchestration summary for the human lead

Guardrails

• Atomic means independently validatable. If you cannot describe how to verify a task in isolation, it is not atomic — split it further or merge it with its dependency.
• Parallel agents must not share mutable state without a coordination strategy. If two tracks write to the same file or schema, they are not independent. Use worktrees or serialise them.
• Integration validation is not optional. Parallel work that skips the post-merge regression check is not complete.
• Keep agent context lean. Each agent gets its task spec and relevant ADRs, not the entire repo.

Model choice at the delegation boundary

Use the adopting project's model-routing policy before dispatch. Record requested model/effort, allowed paths, Definition of Done and independent checks. Prefer deterministic tools where sufficient; do not equate a smaller task with a qualified cheaper model. Track failed attempts, escalation and parent integration costs. Preserve existing risk floors and stop rules. The routing guide shows a reversible approach; it does not automatically enable routing in consumers.