agentsclimarketplace

Openspec ultra bridge v2

Skill keithhegit/ultra-orchestration/skills-vnext/openspec-ultra-bridge-v2

Ultra Orchestration 是一套开源的 AI 工程编排技能体系。它将 OpenSpec 规格主线（Program → Milestone → Change → Slice）与 Ultra-Orchestrator 执行阶段（Intake → Plan → Dispatch → Execute → Review → QA → Deliver → Retro）结合，提升交付稳定性与可审计性。

Install
npx -y skills add keithhegit/ultra-orchestration --skill openspec-ultra-bridge-v2

Assembled 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.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

2.5 KB, 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.md
  • design.md
  • tasks.md
  • optional ultra-bridge.md

into:

  • TaskManifest
  • WorkPackage set
  • bridge notes for review and QA

Bridge Rules

  1. Do not let OpenSpec replace Ultra's execution ledger or review gates.
  2. Prefer one bounded change as the default execution unit.
  3. Use OpenSpec for durable spec memory and archive history.
  4. Use Ultra for dispatch, retries, review, QA, and delivery.
  5. In STRICT_OPENSPEC, do not continue without change scaffold, slice status, JSON-ready planning artifacts, and ledger handoff.

How To Use

  1. Point the bridge at an OpenSpec change directory.
  2. Read the proposal, design, and task assets.
  3. If ultra-bridge.md exists, treat it as the preferred mapping hint.
  4. Normalize the change into a reviewable TaskManifest and WorkPackage set.
  5. Hand off those outputs to ultra-planning or ultra-execution-control.

Required Change Scaffold

For newly opened strict changes, initialize at minimum:

  • proposal.md
  • design.md
  • tasks.md
  • ultra-bridge.md

Default status:

  • slice_0_spec_ready when the change is ready for implementation
  • slice_0_not_opened only for unopened planned changes

Slice Contract

Keep change and slice separate:

  • OpenSpec change is the durable spec and progress node
  • Ultra slice is 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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.