Openspec ultra bridge v2
Skill keithhegit/ultra-orchestration/skills-vnext/openspec-ultra-bridge-v2
Bridge OpenSpec change artifacts into Codex Ultra vNext execution contracts. Use when a repo stores long-lived specs in `openspec/changes` or `openspec/specs`, but execution should still flow through Ultra manifests, work packages, review, QA, ledger tracking, and final delivery rather than replacing Ultra with a separate control plane.From its SKILL.md
npx -y skills add keithhegit/ultra-orchestration --skill openspec-ultra-bridge-v2Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.5 KB, 525 tokens by cl100k_base, as published. Nobody here has run it
OpenSpec Ultra Bridge V2
OpenSpec is the specification layer. Ultra remains the control plane.
This skill is a compatibility bridge for vNext users. The default public entry
point is now $ultra-orchestrator, which invokes this bridge as needed.
What This Skill Does
Translate:
proposal.mddesign.mdtasks.md- optional
ultra-bridge.md
into:
TaskManifestWorkPackageset- bridge notes for review and QA
Bridge Rules
- Do not let OpenSpec replace Ultra's execution ledger or review gates.
- Prefer one bounded
changeas the default execution unit. - Use OpenSpec for durable spec memory and archive history.
- Use Ultra for dispatch, retries, review, QA, and delivery.
- In
STRICT_OPENSPEC, do not continue without change scaffold, slice status, JSON-ready planning artifacts, and ledger handoff.
How To Use
- Point the bridge at an OpenSpec change directory.
- Read the proposal, design, and task assets.
- If
ultra-bridge.mdexists, treat it as the preferred mapping hint. - Normalize the change into a reviewable
TaskManifestandWorkPackageset. - Hand off those outputs to
ultra-planningorultra-execution-control.
Required Change Scaffold
For newly opened strict changes, initialize at minimum:
proposal.mddesign.mdtasks.mdultra-bridge.md
Default status:
slice_0_spec_readywhen the change is ready for implementationslice_0_not_openedonly for unopened planned changes
Slice Contract
Keep change and slice separate:
- OpenSpec
changeis the durable spec and progress node - Ultra
sliceis the implementation and verification unit
Every bridge output should name:
change_id- current slice status
- next slice
- owned paths
- review targets
- QA targets
- blockers for status sync or archive
Script
Use scripts/bridge_change.py to extract and materialize bridge artifacts from
a real OpenSpec change directory.
Read Next
- bridge-pattern
- teammate-pilot
- the shared contracts in
../ultra-vnext-core/references/contracts.md
What ships with it: 4 files
5.3 KB alongside SKILL.md, 1 of them executable
agents/
- openai.yaml232 B
references/
- bridge-pattern.md654 B
- teammate-pilot.md422 B
scripts/
- bridge_change.pyruns4.1 KB