Ultrawork

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>