with one click
ultrawork
Parallel execution engine for high-throughput task completion
Menu
Parallel execution engine for high-throughput task completion
[OMX] Strict autonomous loop: $deep-interview -> $ralplan -> $ultragoal (+ $team if needed) -> $code-review -> $ultraqa
Socratic deep interview with mathematical ambiguity gating before execution
Run a comprehensive code review
Adversarial dynamic e2e QA workflow - generate hostile scenarios, test, verify, fix, report, and clean up
Self-referential loop until task completion with architect verification
Alias for $plan --consensus
| name | ultrawork |
| description | Parallel execution engine for high-throughput task completion |
<Use_When>
<Do_Not_Use_When>
ultragoal insteadteam insteadautopilot instead (default loop: deep-interview -> ralplan -> ultragoal, with team only when needed)ralph explicitly; do not present it as the default durable pathultragoal for durable tracking, or delegate to a single executorralplan until execution is explicitly authorized
</Do_Not_Use_When><Why_This_Exists> Sequential task execution wastes time when tasks are independent. Ultrawork keeps the execution branch fast while tightening the protocol: gather enough context first, define pass/fail acceptance criteria before editing, decide deliberately between local execution and delegation, and finish with evidence rather than vibes. </Why_This_Exists>
<Execution_Policy>
model parameter explicitly when delegating.docs/shared/agent-tiers.md before first delegation for agent selection guidance.researcher when official docs, version-aware framework guidance, best practices, or external dependency behavior materially affect task correctness; treat it as an evidence lane, not a replacement primary workflow.run_in_background: true for operations over ~30 seconds (installs, builds, tests).continue, continue the active workflow branch rather than restarting discovery or re-asking settled questions.
</Execution_Policy><Tool_Usage>
run_in_background: true for package installs, builds, and test suites.Use the CLI-first state surface (omx state ... --json) for ultrawork lifecycle state. If explicit MCP compatibility tools are already available, equivalent omx_state calls are optional compatibility, not the default.
omx state write --input '{"mode":"ultrawork","active":true,"reinforcement_count":1,"started_at":"<now>"}' --jsonomx state write --input '{"mode":"ultrawork","reinforcement_count":<current>}' --jsonomx state write --input '{"mode":"ultrawork","active":false}' --json$cancel (which should call omx state clear --input '{"mode":"ultrawork"}' --json)Direct-tool lane:
skills/ultrawork/SKILL.mdBackground evidence lane:
Why good: Context is grounded first, acceptance criteria are explicit, and the direct-tool lane runs alongside a bounded evidence lane.
</Good>
<Good>
Correct use of self-vs-delegate judgment:
Shared-file edit in progress across src/scripts/codex-native-hook.ts and its test -> keep implementation local.
Independent regression mapping for keyword-detector coverage -> delegate to a test-engineer lane.
Why good: Shared-file work stays local; independent evidence work fans out.
</Good>
<Bad>
Parallelizing before the task is grounded:
use /prompts:executor for this scoped task use /prompts:test-engineer for this scoped task
Why bad: No context snapshot, no pass/fail target, and delegation starts before the work is shaped.
</Bad>
<Bad>
Claiming success without evidence or manual QA:
Made the changes. Ultrawork should be updated now.
Why bad: No verification output, no acceptance evidence, and no manual QA note when the behavior is user-visible.
</Bad>
</Examples>
<Escalation_And_Stop_Conditions>
- When ultrawork is invoked directly, apply lightweight verification only -- build/typecheck passes when relevant, affected tests pass, and manual QA notes are captured when needed.
- Ultrawork does not own persistence, durable ledgers, architect verification, deslop, full QA, or the full verified-completion promise. Do not claim those guarantees from direct ultrawork alone.
- Escalate to `ultragoal` when the work needs durable goal state, story checkpoints, or resume across implementation steps.
- Escalate to `team` when the work needs coordinated tmux workers, shared task state, or durable multi-worker lifecycle control.
- Escalate to explicitly requested `ralph` only for the supported legacy single-owner persistence/verification fallback.
- Ralph owns persistence, architect verification, deslop, and the full verified-completion promise only when explicitly selected as the supported legacy fallback; direct ultrawork does not own those guarantees.
- If a task fails repeatedly across retries, report the issue rather than retrying indefinitely.
- Escalate to the user when tasks have unclear dependencies, conflicting requirements, or a materially branching acceptance target.
</Escalation_And_Stop_Conditions>
<Final_Checklist>
- [ ] Task intent and constraints were grounded before editing
- [ ] Pass/fail acceptance criteria were stated before execution
- [ ] Parallel lanes were used only for independent work
- [ ] Build/typecheck passes when relevant
- [ ] Affected tests pass
- [ ] Manual QA notes recorded when behavior is user-visible
- [ ] No new errors introduced
- [ ] Completion claim stays inside ultrawork's lightweight-verification boundary
</Final_Checklist>
<Advanced>
## Relationship to Other Modes
ultrawork (this skill) -- provides: in-session parallel execution discipline + lightweight evidence
ultragoal (durable goal execution) -- owns: goal ledger, checkpoints, resume across stories, final gate discipline -- may use: team for parallel lanes when a story benefits from coordinated workers
team (tmux coordinated execution) -- owns: worker panes, shared task state, mailbox/dispatch, lifecycle control -- can return: checkpoint-ready evidence to an Ultragoal leader
autopilot (strict autonomous delivery loop) -- default flow: deep-interview -> ralplan -> ultragoal -> code-review -> ultraqa -- may use: team only when an Ultragoal story needs parallel execution
ralph (supported legacy explicit fallback) -- owns: single-owner persistence loop + architect verification when intentionally selected
ecomode (deprecated compatibility-only) -- do not route users there from ultrawork; it is not the current model-selection path
Ultrawork is the parallelism and execution-discipline layer. Ultragoal is the current default durable goal/ledger follow-up. Team is the coordinated tmux parallel runtime, often nested under an Ultragoal story when durable work needs multiple lanes. Autopilot orchestrates the full default lifecycle through deep-interview, ralplan, ultragoal, code-review, and ultraqa. Ralph remains active as an explicit legacy fallback for persistent single-owner verification, but it is not the recommended default durable path. Ecomode is deprecated compatibility-only and should not be advertised as the ultrawork model-selection route.
</Advanced>