Ultrawork

<Purpose> Ultrawork is a parallel execution engine for high-throughput task completion. It is a component, not a standalone persistence or verification mode: it provides parallelism, context discipline, and smart delegation guidance, but not durable goal tracking, Team's tmux worker lifecycle, Ralph's legacy persistence loop, architect sign-off, or long-running completion guarantees. </Purpose>

<Use_When>

• Multiple independent tasks can run simultaneously
• User says "ulw", "ultrawork", or explicitly wants parallel execution
• Task benefits from concurrent execution plus lightweight evidence before wrap-up
• You need a direct-tool lane plus optional background evidence lanes without entering Team or a durable goal workflow

</Use_When>

<Do_Not_Use_When>

• Task needs durable goal tracking, ledger checkpoints, or resume across stories -- use ultragoal instead
• Task needs coordinated tmux workers, shared task state, mailbox/dispatch coordination, or long-running parallel execution -- use team instead
• Task requires a full autonomous pipeline -- use autopilot instead (default loop: deep-interview -> ralplan -> ultragoal, with team only when needed)
• Task intentionally requires the legacy persistent single-owner completion/verification loop -- use ralph explicitly; do not present it as the default durable path
• There is only one sequential task with no parallelism opportunity -- execute directly, use ultragoal for durable tracking, or delegate to a single executor
• The request is still in plan-consensus mode -- keep planning artifacts in ralplan 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>

• Gather enough context before implementation. Start with the task intent, desired outcome, constraints, likely touchpoints, and any uncertainty that would change the execution path.
• If uncertainty is still material after a quick repo read, do a focused evidence pass first instead of immediately editing.
• Define pass/fail acceptance criteria before launching execution lanes. Include the command, artifact, or manual check that will prove success.
• Prefer direct tool work when the task is small, coupled, or blocked on immediate local context. Delegate only when the work is independent enough to benefit from parallel execution.
• When useful, run a direct-tool lane and one or more background evidence lanes at the same time. Evidence lanes can cover docs, tests, regression mapping, or bounded repo analysis.
• Fire independent agent calls simultaneously -- never serialize independent work.
• Always pass the model parameter explicitly when delegating.
• Read references/agent-tiers.md before first delegation for agent selection guidance.
• Auto-delegate 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.
• Use run_in_background: true for operations over ~30 seconds (installs, builds, tests).
• Run quick commands (git status, file reads, simple checks) in the foreground.
• Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for speculative/blocked lanes, local overrides for the active workflow branch, evidence-backed validation, explicit stop rules, and continuation of clear safe execution branches instead of restarting or re-asking.
• If the user says continue, continue the active workflow branch rather than restarting discovery or re-asking settled questions.

</Execution_Policy>

<Steps> 1. Read agent reference: Load references/agent-tiers.md for tier selection. 2. Context + certainty check:

• State the task intent in one sentence.
• List the constraints and unknowns that could invalidate a quick fix.
• If confidence is low, explore first and narrow the task before editing.

3. Define acceptance criteria before execution:

• What must be true at the end?
• Which command or artifact proves it?
• Which manual QA check is required, if any?

4. Classify the work by dependency shape:

• Independent tasks -> parallel lanes.
• Shared-file or prerequisite-heavy tasks -> local execution or staged lanes.

5. Choose self vs delegate deliberately:

• Work locally when the next step depends on immediate repo context, shared files, or tight iteration.
• Delegate when the task slice is bounded, independent, and materially improves throughput.

6. Run execution lanes:

• Direct-tool lane for immediate implementation or verification work.
• Background evidence lanes for tests, docs, repo analysis, or regression checks.

7. Run dependent tasks sequentially: Wait for prerequisites before launching dependent work. 8. Close with lightweight evidence:

• Build/typecheck passes when relevant.
• Affected tests pass.
• Manual QA notes are recorded when the task needs a human-visible or behavior-level check.
• No new errors introduced.

</Steps>

<Tool_Usage>

• Use LOW-tier delegation for simple lookups and bounded evidence gathering.
• Use STANDARD-tier delegation for standard implementation and regression work.
• Use THOROUGH-tier delegation for complex analysis, architectural review, or risky multi-file changes.
• Prefer a direct-tool lane when the immediate next step is blocked on local context.
• Prefer background evidence lanes when you can learn something useful in parallel with implementation.
• Use run_in_background: true for package installs, builds, and test suites.
• Use foreground execution for quick status checks and file operations.

</Tool_Usage>

State Management

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.

• On start:

omx state write --input '{"mode":"ultrawork","active":true,"reinforcement_count":1,"started_at":"<now>"}' --json

• On each reinforcement/loop step:

omx state write --input '{"mode":"ultrawork","reinforcement_count":<current>}' --json

• On completion:

omx state write --input '{"mode":"ultrawork","active":false}' --json

• On cancellation/cleanup:

run $cancel (which should call omx state clear --input '{"mode":"ultrawork"}' --json)

<Examples> <Good> Two-track execution with acceptance criteria up front:

Acceptance criteria:
- `npm run build` passes
- `node --test dist/scripts/__tests__/codex-native-hook.test.js` passes
- Manual QA: verify `$ultrawork` activation message still points to the session state file

Direct-tool lane:
- update `skills/ultrawork/SKILL.md`

Background evidence lane:
- use /prompts:test-engineer for this scoped task

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>

Agent Tiers

This file defines practical tier guidance for OMX agent routing.

Mental Model

OMX now separates three concepts:

• role: what the agent is responsible for (executor, planner, architect)
• tier: how much reasoning/cost to spend (LOW, STANDARD, THOROUGH)
• posture: how the role behaves (frontier-orchestrator, deep-worker, fast-lane)
• exactModel: optional role pin that bypasses tier defaults when a role needs a

specific model contract.

Use role to choose responsibility, tier to choose depth, and posture to choose operating style.

Tiers

• LOW:

Fast lookups and narrow checks. Use for simple exploration, style checks, and lightweight doc edits. Typical roles: explore, style-reviewer, writer.

• STANDARD:

Default tier for implementation, debugging, and normal verification. Typical roles: executor, debugger, test-engineer, quality-reviewer.

• THOROUGH:

Use for architectural, security-sensitive, or high-impact multi-file work. Typical roles: architect, critic, security-reviewer, executor. Note: deep-executor is deprecated; route implementation to executor.

Selection Rules

1. Start at STANDARD for most code changes. 2. Use LOW only when the task is bounded and non-invasive. 3. Escalate to THOROUGH for:

• security/auth/trust-boundary changes
• architectural decisions with system-wide impact
• large refactors across many files

4. For Ralph completion checks, use at least STANDARD architect verification.

Posture Guidance

• frontier-orchestrator:
• Best for steerable frontier models and leader-style roles.
• Prioritizes intent classification, delegation, verification, and architectural judgment.
• Typical roles: planner, analyst, architect, critic, code-reviewer.
• Ralplan keeps planner and architect in this posture but pins them to

exact gpt-5.4-mini with high reasoning; the critic consensus gate stays on the frontier lane.

• deep-worker:
• Best for implementation-heavy roles that should carry work to completion.
• Prioritizes direct execution, minimal diffs, and strict verification.
• Typical roles: executor, debugger, test-engineer, build-fixer.

• fast-lane:
• Best for cheap/fast models used for triage, search, and narrow synthesis.
• Prioritizes quick routing, concise search, and escalation over deep autonomous work.
• Typical roles: explore, writer, and lightweight research/search specialists.