Ultra Orchestrator

Ultra Orchestrator

Use this skill as the default public entry point for Ultra Orchestration. The user should only need to invoke $ultra-orchestrator .

This is the mainline successor to the vNext protocol. The old stable workflow is preserved as ultra-orchestrator-legacy.

Startup Contract

Recommended invocation:

$ultra-orchestrator 

OpenSpec invocation:

$ultra-orchestrator OpenSpec change : 

Compatibility invocation:

$ultra-vnext-core 

If the client exposes slash aliases, /ultra-orchestrator can be used the same way.

Run Mode Decision

Classify the run before planning or execution:

• LIGHT

review-only, QA-only, explanation-only, or user-explicit lightweight work

• STANDARD

user-explicit fast orchestration with bounded risk and no full control plane

• STRICT

development work where OpenSpec is unavailable but ledger and JSON contracts are still required

• STRICT_OPENSPEC

default for development work, bug fixes, multi-file implementation, pilots, full orchestration tests, OpenSpec work, slice DAG work, and control-plane validation

Development tasks must prefer STRICT_OPENSPEC. If that mode is impossible, explain why and downgrade explicitly. Markdown-only artifacts are not enough for STRICT or STRICT_OPENSPEC.

Router Duties

When invoked:

1. classify the task and choose run_mode
2. create or require OpenSpec change scaffolding when STRICT_OPENSPEC applies
3. initialize the run ledger for STRICT and STRICT_OPENSPEC
4. route through the minimal required sibling skills
5. validate machine-checkable artifacts before delivery
6. produce delivery artifacts or a clear blocker

Do not ask the user to manually name every subskill.

Routing Table

| Task signal | Default mode | Route | |---|---|---| | development, feature, bugfix, multi-file implementation, pilot, full orchestration test | STRICT_OPENSPEC | OpenSpec bootstrap or bridge -> planning -> risk -> dispatch -> review -> QA -> delivery | | existing OpenSpec change path, openspec/changes, proposal/design/tasks, archive workflow | STRICT_OPENSPEC | bridge -> planning -> risk -> dispatch -> review -> QA -> delivery | | development task where OpenSpec cannot be used | STRICT | planning -> risk -> dispatch -> review -> QA -> delivery | | review-only request | LIGHT | review -> delivery | | QA-only request | LIGHT | QA -> delivery | | high-risk command, publishing, destructive write, credentials, external mutation | current mode plus risk gate | risk before execution |

If a task is tiny but still a development task, keep STRICT_OPENSPEC unless the user explicitly asks for lightweight execution.

Strict Control Plane

For STRICT and STRICT_OPENSPEC, the run must use:

• scripts/new_run.py to initialize a run directory
• ledger.json as the execution state record
• JSON TaskManifest
• JSON WorkPackage
• JSON or structured AgentResult
• scripts/validate_contracts.py for core artifact validation
• explicit review and QA gates
• final control_surface_used

If a required script or artifact cannot be used, stop with a blocker instead of silently downgrading to markdown-only orchestration.

OpenSpec Bootstrap

When STRICT_OPENSPEC applies and no existing change is available, create or request this scaffold:

openspec/changes//proposal.md
openspec/changes//design.md
openspec/changes//tasks.md
openspec/changes//ultra-bridge.md

Default to a single bounded change and one current implementation slice. OpenSpec owns durable specification state. Ultra owns execution control.

Slice-Driven Execution

Keep change and slice separate:

• OpenSpec change is the specification and progress ledger unit
• Ultra slice is the implementation, verification, and commit unit

Use this slice status vocabulary:

• slice_0_not_opened
• slice_0_spec_ready
• slice_1_completed
• slice_2_in_progress
• slice_3_qa_pending
• slice_4_done

Every active change must name current slice status, next slice, owned paths, and the verification gate required before advancing.

State Machine

Default phases:

Intake -> Plan -> Dispatch -> Execute -> Review -> QA -> Deliver -> Retro

Required loopbacks:

• Review -> Execute when the plan is valid but the work is wrong
• QA -> Execute when behavior is wrong but architecture is still valid
• QA -> Plan when the failure exposes a planning or requirement flaw

Default retry policy:

• transient failures: at most 1 bounded retry per work package
• repeated or hard blockers: escalate with summary, evidence, and next-step ask

Context Firewall

Pass artifacts, not full chat history:

• relevant TaskManifest
• assigned WorkPackage
• file pointers or artifact paths
• failure context for retries or reroutes

Safe Parallelism

Dispatch work in parallel only when:

• dependencies are satisfied in the DAG
• owned_paths do not intersect with another active write package
• inputs are stable enough to avoid speculative design
• acceptance checks are concrete enough for independent verification

If any condition is false, serialize.

Delivery Requirement

Every delivery must include:

• final_deliverable
• orchestration_log
• vetter_report
• control_surface_used

control_surface_used must state:

• run_mode
• used_openspec_change
• used_openspec_bridge
• used_run_ledger
• used_contract_validation
• used_slice_dag
• used_dynamic_qa
• skipped control surfaces and reasons

Supporting Skills

Route through these siblings as needed:

• $openspec-ultra-bridge for OpenSpec change mapping
• $decision-complete-planner for JSON-ready task graphs
• $dispatch-and-track for ledger and write-lock tracking
• $risk-vetter and $safety-guard for risk gates and guardrails
• $spec-review and $code-review for review gates
• $qa-verify for verification
• $deliver-and-retro for final packaging

Read Next

• Read [routing](references/routing.md) for strict routing examples.
• Read [contracts](references/contracts.md) for machine-checkable artifacts.
• Read [state-machine](references/state-machine.md) for phase and loopback rules.
• Read [design-tenets](references/design-tenets.md) for governing principles.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: keithhegit
• Source: keithhegit/ultra-orchestration
• License: Apache-2.0
• Homepage: https://keithhegit.github.io/ultra-orchestration/docs.html

Install and usage instructions live in the source repository linked above.