delivery-orchestrator

Files (1)

• SKILL.md

SKILL.md (first lines)

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

| Record | The one question it answers | Written when |
|---|---|---|
| **GitHub issues** | *What exactly is this work, and how will we know it is done?* | Before the first line of code |
| **`STATUS.md`** | *What is happening now, and what waits on whom?* | One entry per working session |
| **`ROADMAP.md`** | *What are we building toward, in what order?* | When a milestone or the plan changes |
| **`CHANGELOG.md`** | *What merged or released, with checks and version links?* | When user-visible work merges |

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](../operating-model-bootstrap/assets/DELIVERY-WORKFLOW.template.md)
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

| Task type | Route to skill |
|---|---|
| New feature / epic planning | `spec-first-delivery` |
| Vision, requirements, user journeys and product acceptance | `product-owner` |
| Material strategic, cost/risk or operating ownership decision | `cxo-oversight` |
| Acceptance coverage and executable user-path checks | `test-strategy` |
| 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, AWS, Azure, Alibaba Cloud) | `cloud-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) |
| An agreed goal to pursue autonomously to a merged outcome | `get-it-done` |
| Developer-machine contention, orphaned automation browsers, cloud-sync stalls | `system-performance-guardrail` |
| Read-only SRE checkup of a GCP project: probes, status table, one `OVERALL:` line | `cloud-checkup` |
| Frontend performance measurement: Core Web Vitals, traces, Lighthouse, heap growth | `frontend-performance-audit` |
| Routing this list | `delivery-orchestrator` (you are here) |

## Adoption and review recovery

Use [the adoption guide](../../docs/HARNESS-ADOPTION.md) 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](../pr-reviewer/references/independent-council.md);
changing candidate or reviewer never erases unresolved findings or spent attempts.

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

From jpantsjoha/ai-native-developer-experience, Apache-2.0.

More from jpantsjoha/ai-native-developer-experience