ultra-orchestrator — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited ultra-orchestrator (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Use this skill as the default public entry point for Ultra Orchestration. The user should only need to invoke $ultra-orchestrator <task description>.
This is the mainline successor to the vNext protocol. The old stable workflow is preserved as ultra-orchestrator-legacy.
Recommended invocation:
$ultra-orchestrator <task description>OpenSpec invocation:
$ultra-orchestrator OpenSpec change <change-id or path>: <task description>Compatibility invocation:
$ultra-vnext-core <task description>If the client exposes slash aliases, /ultra-orchestrator can be used the same way.
Classify the run before planning or execution:
LIGHTreview-only, QA-only, explanation-only, or user-explicit lightweight work
STANDARDuser-explicit fast orchestration with bounded risk and no full control plane
STRICTdevelopment work where OpenSpec is unavailable but ledger and JSON contracts are still required
STRICT_OPENSPECdefault 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.
When invoked:
run_modeSTRICT_OPENSPEC appliesSTRICT and STRICT_OPENSPECDo not ask the user to manually name every subskill.
| 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.
For STRICT and STRICT_OPENSPEC, the run must use:
scripts/new_run.py to initialize a run directoryledger.json as the execution state recordTaskManifestWorkPackageAgentResultscripts/validate_contracts.py for core artifact validationcontrol_surface_usedIf a required script or artifact cannot be used, stop with a blocker instead of silently downgrading to markdown-only orchestration.
When STRICT_OPENSPEC applies and no existing change is available, create or request this scaffold:
openspec/changes/<change-id>/proposal.md
openspec/changes/<change-id>/design.md
openspec/changes/<change-id>/tasks.md
openspec/changes/<change-id>/ultra-bridge.mdDefault to a single bounded change and one current implementation slice. OpenSpec owns durable specification state. Ultra owns execution control.
Keep change and slice separate:
change is the specification and progress ledger unitslice is the implementation, verification, and commit unitUse this slice status vocabulary:
slice_0_not_openedslice_0_spec_readyslice_1_completedslice_2_in_progressslice_3_qa_pendingslice_4_doneEvery active change must name current slice status, next slice, owned paths, and the verification gate required before advancing.
Default phases:
Intake -> Plan -> Dispatch -> Execute -> Review -> QA -> Deliver -> Retro
Required loopbacks:
Review -> Execute when the plan is valid but the work is wrongQA -> Execute when behavior is wrong but architecture is still validQA -> Plan when the failure exposes a planning or requirement flawDefault retry policy:
Pass artifacts, not full chat history:
TaskManifestWorkPackageDispatch work in parallel only when:
owned_paths do not intersect with another active write packageIf any condition is false, serialize.
Every delivery must include:
final_deliverableorchestration_logvetter_reportcontrol_surface_usedcontrol_surface_used must state:
run_modeused_openspec_changeused_openspec_bridgeused_run_ledgerused_contract_validationused_slice_dagused_dynamic_qaRoute 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~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.