git:20260807.c64e31f to git:20260914.d9753e2

---

name: delivery-orchestrator

description: Decompose an epic into atomic parallelizable tasks and route each task to the right skill. Use this as a meta-router when you have more than one skill available and need to decide which applies. Trigger at the start of any multi-track epic or when the skill count in your harness exceeds ~12.

---

# 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 two jobs: decompose work into the smallest independently executable units, then route each unit to the skill that owns it.

## 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

## 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

| Task type | Route to skill |

|---|---|

| New feature / epic planning | `spec-first-delivery` |

| Architecture decision or trade-off | `the-architect` |

| High-stakes design review | `adversarial-gate` |

| Pre-deployment go/no-go | `release-readiness` |

| Release process governance, SemVer, ADR, changelog | `release-manager` |

| Enterprise policy, compliance, or governance alignment | `governance-guardrail` |

| GitHub repo operations: CI triggers, billing, issues, labels, branch protection | `github-manager` |

| Google ADK agent patterns | `adk-expert` |

| MCP server design or governance | `mcp-server-scaffold` |

| Agent output validation | `domain-validator` |

| PR or code review | `pr-reviewer` |

| LLM cost or model selection | `cost-guardrail` |

| Status or standup synthesis | `sitrep` |

| Plugin-directory, marketplace, or curated-list submission | `plugin-submission` |

| New repo or operating model install / repair | `operating-model-bootstrap` |

| Delivery controls: source of truth, issue/PR conventions, DoD, escalation | `delivery-orchestrator` (own it here) |

| Routing this list | `delivery-orchestrator` (you are here) |

## Outputs

- 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.