State Management
Use omx_state MCP tools for ultrawork lifecycle state.
- On start:
state_write({mode: "ultrawork", active: true, reinforcement_count: 1, started_at: "<now>"})
- On each reinforcement/loop step:
state_write({mode: "ultrawork", reinforcement_count: <current>})
- On completion:
state_write({mode: "ultrawork", active: false})
- On cancellation/cleanup:
run
$cancel (which should call state_clear(mode="ultrawork"))
Direct-tool lane:
- update
skills/ultrawork/SKILL.md
Background evidence lane:
- delegate(role="test-engineer", tier="STANDARD", task="Map which hook tests cover ultrawork activation messaging", model="...")
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:
delegate(role="executor", tier="STANDARD", task="Implement whatever seems necessary", model="...")
delegate(role="test-engineer", tier="STANDARD", task="Figure out how to test it later", model="...")
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 (not via Ralph), apply lightweight verification only -- build/typecheck passes when relevant, affected tests pass, and manual QA notes are captured when needed.
- Ralph owns persistence, architect verification, deslop, and the full verified-completion promise. Do not claim those guarantees from direct ultrawork alone.
- 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
ralph (persistence + verified completion wrapper)
-- includes: ultrawork (this skill)
-- provides: high-throughput execution + lightweight evidence
autopilot (autonomous execution)
-- includes: ralph
-- includes: ultrawork (this skill)
ecomode (token efficiency)
-- modifies: ultrawork's model selection
Ultrawork is the parallelism and execution-discipline layer. Ralph adds persistence, architect verification, deslop, and retry-until-done behavior. Autopilot adds the broader autonomous lifecycle pipeline. Ecomode adjusts ultrawork's model routing to favor cheaper models.
</Advanced>
1---2name: ultrawork3description: Parallel execution engine for high-throughput task completion4---56<Purpose>7Ultrawork is a parallel execution engine for high-throughput task completion. It is a component, not a standalone persistence mode: it provides parallelism, context discipline, and smart delegation guidance, but not Ralph's persistence loop, architect sign-off, or long-running completion guarantees.8</Purpose>910<Use_When>11- Multiple independent tasks can run simultaneously12- User says "ulw", "ultrawork", or explicitly wants parallel execution13- Task benefits from concurrent execution plus lightweight evidence before wrap-up14- You need a direct-tool lane plus optional background evidence lanes without entering Ralph15</Use_When>1617<Do_Not_Use_When>18- Task requires guaranteed completion with persistence, architect verification, or deslop/reverification -- use `ralph` instead (Ralph includes ultrawork)19- Task requires a full autonomous pipeline -- use `autopilot` instead (autopilot includes Ralph which includes ultrawork)20- There is only one sequential task with no parallelism opportunity -- execute directly or delegate to a single `executor`21- The request is still in plan-consensus mode -- keep planning artifacts in `ralplan` until execution is explicitly authorized22- User needs session persistence for resume -- use `ralph`, which adds persistence on top of ultrawork23</Do_Not_Use_When>2425<Why_This_Exists>26Sequential 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.27</Why_This_Exists>2829<Execution_Policy>30- Gather enough context before implementation. Start with the task intent, desired outcome, constraints, likely touchpoints, and any uncertainty that would change the execution path.31- If uncertainty is still material after a quick repo read, do a focused evidence pass first instead of immediately editing.32- Define pass/fail acceptance criteria before launching execution lanes. Include the command, artifact, or manual check that will prove success.33- 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.34- 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.35- Fire independent agent calls simultaneously -- never serialize independent work.36- Always pass the `model` parameter explicitly when delegating.37- Read `docs/shared/agent-tiers.md` before first delegation for agent selection guidance.38- 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.39- Use `run_in_background: true` for operations over ~30 seconds (installs, builds, tests).40- Run quick commands (git status, file reads, simple checks) in the foreground.41- 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.42- If the user says `continue`, continue the active workflow branch rather than restarting discovery or re-asking settled questions.43</Execution_Policy>4445<Steps>461. **Read agent reference**: Load `docs/shared/agent-tiers.md` for tier selection.472. **Context + certainty check**:48 - State the task intent in one sentence.49 - List the constraints and unknowns that could invalidate a quick fix.50 - If confidence is low, explore first and narrow the task before editing.513. **Define acceptance criteria before execution**:52 - What must be true at the end?53 - Which command or artifact proves it?54 - Which manual QA check is required, if any?554. **Classify the work by dependency shape**:56 - Independent tasks -> parallel lanes.57 - Shared-file or prerequisite-heavy tasks -> local execution or staged lanes.585. **Choose self vs delegate deliberately**:59 - Work locally when the next step depends on immediate repo context, shared files, or tight iteration.60 - Delegate when the task slice is bounded, independent, and materially improves throughput.616. **Run execution lanes**:62 - Direct-tool lane for immediate implementation or verification work.63 - Background evidence lanes for tests, docs, repo analysis, or regression checks.647. **Run dependent tasks sequentially**: Wait for prerequisites before launching dependent work.658. **Close with lightweight evidence**:66 - Build/typecheck passes when relevant.67 - Affected tests pass.68 - Manual QA notes are recorded when the task needs a human-visible or behavior-level check.69 - No new errors introduced.70</Steps>7172<Tool_Usage>73- Use LOW-tier delegation for simple lookups and bounded evidence gathering.74- Use STANDARD-tier delegation for standard implementation and regression work.75- Use THOROUGH-tier delegation for complex analysis, architectural review, or risky multi-file changes.76- Prefer a direct-tool lane when the immediate next step is blocked on local context.77- Prefer background evidence lanes when you can learn something useful in parallel with implementation.78- Use `run_in_background: true` for package installs, builds, and test suites.79- Use foreground execution for quick status checks and file operations.80</Tool_Usage>8182## State Management8384Use `omx_state` MCP tools for ultrawork lifecycle state.8586- **On start**:87 `state_write({mode: "ultrawork", active: true, reinforcement_count: 1, started_at: "<now>"})`88- **On each reinforcement/loop step**:89 `state_write({mode: "ultrawork", reinforcement_count: <current>})`90- **On completion**:91 `state_write({mode: "ultrawork", active: false})`92- **On cancellation/cleanup**:93 run `$cancel` (which should call `state_clear(mode="ultrawork")`)9495<Examples>96<Good>97Two-track execution with acceptance criteria up front:98```99Acceptance criteria:100- `npm run build` passes101- `node --test dist/scripts/__tests__/codex-native-hook.test.js` passes102- Manual QA: verify `$ultrawork` activation message still points to the session state file103104Direct-tool lane:105- update `skills/ultrawork/SKILL.md`106107Background evidence lane:108- delegate(role="test-engineer", tier="STANDARD", task="Map which hook tests cover ultrawork activation messaging", model="...")109```110Why good: Context is grounded first, acceptance criteria are explicit, and the direct-tool lane runs alongside a bounded evidence lane.111</Good>112113<Good>114Correct use of self-vs-delegate judgment:115```116Shared-file edit in progress across `src/scripts/codex-native-hook.ts` and its test -> keep implementation local.117Independent regression mapping for keyword-detector coverage -> delegate to a test-engineer lane.118```119Why good: Shared-file work stays local; independent evidence work fans out.120</Good>121122<Bad>123Parallelizing before the task is grounded:124```125delegate(role="executor", tier="STANDARD", task="Implement whatever seems necessary", model="...")126delegate(role="test-engineer", tier="STANDARD", task="Figure out how to test it later", model="...")127```128Why bad: No context snapshot, no pass/fail target, and delegation starts before the work is shaped.129</Bad>130131<Bad>132Claiming success without evidence or manual QA:133```134Made the changes. Ultrawork should be updated now.135```136Why bad: No verification output, no acceptance evidence, and no manual QA note when the behavior is user-visible.137</Bad>138</Examples>139140<Escalation_And_Stop_Conditions>141- When ultrawork is invoked directly (not via Ralph), apply lightweight verification only -- build/typecheck passes when relevant, affected tests pass, and manual QA notes are captured when needed.142- Ralph owns persistence, architect verification, deslop, and the full verified-completion promise. Do not claim those guarantees from direct ultrawork alone.143- If a task fails repeatedly across retries, report the issue rather than retrying indefinitely.144- Escalate to the user when tasks have unclear dependencies, conflicting requirements, or a materially branching acceptance target.145</Escalation_And_Stop_Conditions>146147<Final_Checklist>148- [ ] Task intent and constraints were grounded before editing149- [ ] Pass/fail acceptance criteria were stated before execution150- [ ] Parallel lanes were used only for independent work151- [ ] Build/typecheck passes when relevant152- [ ] Affected tests pass153- [ ] Manual QA notes recorded when behavior is user-visible154- [ ] No new errors introduced155- [ ] Completion claim stays inside ultrawork's lightweight-verification boundary156</Final_Checklist>157158<Advanced>159## Relationship to Other Modes160161```162ralph (persistence + verified completion wrapper)163 \-- includes: ultrawork (this skill)164 \-- provides: high-throughput execution + lightweight evidence165166autopilot (autonomous execution)167 \-- includes: ralph168 \-- includes: ultrawork (this skill)169170ecomode (token efficiency)171 \-- modifies: ultrawork's model selection172```173174Ultrawork is the parallelism and execution-discipline layer. Ralph adds persistence, architect verification, deslop, and retry-until-done behavior. Autopilot adds the broader autonomous lifecycle pipeline. Ecomode adjusts ultrawork's model routing to favor cheaper models.175</Advanced>
DuAooo