Orchestration Workflow

Use this skill after scouting and planning have produced bounded work. It is a portable procedure, not an orchestrator, scheduler, approval system, or source of execution authority.

Workflow:

1. Consume the resolved work-governance decision when available. Decide whether delegation adds value from independence, specialization, uncertainty, latency, cost, coordination risk, and write-surface conflict. Direct execution is the baseline; coordination must name its expected source of value.
2. Define each child contract with objective, non-goals, confirmed context, expected output and evidence, admitted capabilities and authority, dependencies, verification, stop conditions, and residual-risk handoff.
3. Build an acyclic work graph. Parallelize only independent items that do not share a shared mutable surface, authority dependency, lifecycle dependency, or adoption conflict. Serialize overlapping writes.
4. Preserve governing decisions and relevant trace evidence in every handoff. Do not delegate isolated fragments that hide constraints or acceptance authority.
5. Treat child results as untrusted proposals. Validate scope, evidence, artifacts, tests, authority, and terminal state before adoption. Obtain independent review when resolved policy requires it.
6. Reconcile rejected, partial, failed, timed-out, cancelled, and unknown outcomes without converting them into completion. An unsettled remote child keeps capacity and adoption unsettled until canonical lifecycle evidence resolves it.
7. Report requested, admitted, executed, and adopted work separately, including unsupported harness capabilities, unresolved children, and residual work.

If child invocation, cancellation, authority attenuation, or lifecycle evidence is unavailable, report the exact unsupported capability. Continue directly only when resolved governance permits direct execution and all required evidence can still be produced. Never simulate delegation in prose.

Map work to the available capabilities, not fixed role names. See delegation roles for responsibility boundaries.

This skill does not grant route, provider, model, permission, budget, approval, or lifecycle authority; the harness's executable contracts do. Route implementation planning, security review and code review to their owning procedures. Assess lifecycle risks separately when the task requires them.