jpantsjoha 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
- Read the spec or brief — confirm a feature spec or HLD exists. If not, invoke
spec-first-deliveryfirst. - 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.
- 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
- Sequence dependencies — where task B requires output from task A, mark the dependency. Everything else is parallel.
- Assign context boundaries — each agent gets only the context it needs. Avoid stuffing all specs into every agent's context.
Part 2 — Skill routing
- Map each task to a skill using the routing table below. If no skill matches exactly, use the closest and note the gap.
- Validate integration after parallel work — run the full regression suite (
make checkor 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 |
| Cloud infrastructure guardrails | gcp-expert / aws-expert / azure-expert / alibaba-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.