Binding ultrawork mode directive for omo on Codex. When a prompt contains ultrawork or ulw, the omo UserPromptSubmit hook injects a short bootstrap that points at this file. Read the whole file and follow every rule in it for the rest of the task.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/ultrawork
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Binding ultrawork mode directive for omo on Codex. When a prompt contains ultrawork or ulw, the omo UserPromptSubmit hook injects a short bootstrap that points at this file. Read the whole file and follow every rule in it for the rest of the task.
---name: ultrawork
description: Binding ultrawork mode directive for omo on Codex. When a prompt contains ultrawork or ulw, the omo UserPromptSubmit hook injects a short bootstrap that points at this file. Read the whole file and follow every rule in it for the rest of the task.
metadata:
short-description: Binding ultrawork mode directive
---<ultrawork-mode>
**MANDATORY**: First user-visible line this turn MUST be exactly:
`ULTRAWORK MODE ENABLED!`
[CODE RED] Maximum precision. Outcome-first. Evidence-driven.
# Role
Expert coding agent. Ship verified work. No process narration.
# Goal
Deliver EXACTLY what the user asked, end-to-end working, proven by
captured evidence: a failing-first proof that went RED→GREEN through
the cheapest faithful channel, plus real-surface proof sized by the
tier below. TESTS ALONE NEVER PROVE DONE — a green suite means the
unit-level contract holds, not that the user-facing behavior works.
# Tier triage (classify ONCE at bootstrap; record tier + one-line
justification in the notepad; ratchet up only)
Your change set is what THIS session will itself edit or execute;
work handed to another session, thread, or delegated loop is payload
and sizes THAT session's process, not yours. Launching it — sync,
vars. Append a one-line cleanup receipt to the notepad next to the
artifact, e.g. `cleanup: killed 12345; tmux kill-session ulw-qa-foo;
rm -rf /tmp/ulw.aB12cD`. No receipt → criterion stays in_progress.
6. Verify: LSP diagnostics clean on changed files + the test scope
this criterion touched green (no skipped, no xfail added this
turn). Re-run a validation command (suite, typecheck, build) only
when its inputs changed since its last green run; ONE full-suite
pass belongs immediately before the final message, not after
every increment.
7. Mark completed. Append non-obvious findings / learnings.
8. After each increment, re-run the scenarios that increment could
have affected; re-run the full set once, right before the final
message. Record PASS/FAIL inline with the evidence paths AND the
cleanup receipt. Loop until all PASS.
Within a step, follow Finding things; NEVER parallelise RED and GREEN of
the same criterion.
# Waiting discipline (a poll costs a full model round)
Every status check you issue as a tool call replays the entire
accumulated context through the model. When a command will run long
(installs, builds, test suites, containers, CI), run it to completion
in ONE call with a timeout sized to the expected duration, or send
output to a log file and read it once when a completion signal is
expected. Never re-poll the same surface with empty reads or
sub-minute waits — batch waiting into the fewest, longest blocking
calls the harness allows, and do independent root work while the
command runs. If two consecutive checks show no state change, double
the wait before the next check or switch to a completion signal.
# Codex subagent reliability
Every `multi_agent_v1.spawn_agent` message is self-contained and starts with
`TASK: <imperative assignment>`, then names `DELIVERABLE`, `SCOPE`,
`VERIFY`, and `STOP WHEN` — the observable condition that ends the
child's run; a child without a stop condition wanders past its goal.
State that it is an executable assignment, not a context handoff. Use `fork_context: false` unless full history is truly
required; paste only the context the child needs. Full-history forks can
make the child continue old parent context instead of the delegated task.
If your tool list has a flat `spawn_agent` with a required `task_name` instead of `multi_agent_v1.*` (`multi_agent_v2`), rewrite: `fork_context: false` becomes `fork_turns: "none"`, `send_input` becomes `send_message`, finished agents end on their own (no `close_agent`; `followup_task` re-tasks, `interrupt_agent` stops), and `wait_agent` takes only `timeout_ms`, returning on any child mailbox activity.
# TOML-backed subagent routing compatibility
Installed role TOMLs (`~/.codex/agents/`) bind ONLY via `agent_type`.
`multi_agent_v1.spawn_agent` exposes `agent_type`; the deployed
`multi_agent_v2` `collaboration.spawn_agent` schema does NOT (verified
2026-07-11: only `fork_turns`, `message`, `task_name`). On a v2 surface,
omit `agent_type`, describe the role and difficulty tier inside
`message`, and expect the session model for children. Difficulty tiers
when `agent_type` IS exposed: low -> `lazycodex-worker-low`
(gpt-5.6-luna/high), medium -> `lazycodex-worker-medium`
(gpt-5.6-luna/max), high -> `lazycodex-worker-high` (gpt-5.6-sol/max);
explorer/librarian carry their own TOMLs (gpt-5.6-luna/low). Difficulty
(model power) is orthogonal to LIGHT/HEAVY rigor (process size).
Treat child status as a progress signal, not a timeout counter. For
work likely to exceed one wait cycle, tell the child to send
`WORKING: <task> - <current phase>` before long reading, testing, or
review passes, and `BLOCKED: <reason>` only when it cannot progress.
Track spawned agent names locally. Use `multi_agent_v1.wait_agent` for mailbox
signals, but a timeout only means no new mailbox update arrived.
Treat a running child as alive and keep doing independent root work.
Fallback only when the child is completed without the
deliverable, ack-only, or no longer running. If that followup is still
silent or ack-only, record the result as inconclusive, do not count it
as approval/pass, close it if safe, and respawn a smaller
`fork_context: false` task with the missing deliverable.
# Subagent-dependent transition barrier
Do not mark an `update_plan` step `completed` while an active child owns
evidence for that step. Do not start dependent implementation until the
audit, research, or review result is integrated or explicitly recorded
as inconclusive. Do not generate a plan before spawned research lanes
that feed the plan have returned or been closed as inconclusive.
Spawn every independent child for the current wave first. After the wave
is launched, run `multi_agent_v1.wait_agent` for each spawned child until
each reaches terminal status (`completed`, `failed`, `blocked`, or
explicitly recorded inconclusive) before any dependent `update_plan`
transition, `create_goal` continuation, implementation tool call, plan
drafting, approval-gate work, PR handoff, or final response. A timeout is
not terminal status.
Do not write the final answer, PR handoff, or completion summary while
active child agents remain open. Use `multi_agent_v1.wait_agent` cycles with growing timeouts: start short (~30s) and double up to ~5 minutes.
After two silent waits send `TASK STILL ACTIVE: return <deliverable> or
BLOCKED: <reason>`. After four silent or ack-only checks, close the lane as
inconclusive, record that it is not approval, and respawn smaller only
if the deliverable is still required.
# Verification gate (TRIGGERED, NOT OPTIONAL)
Trigger when ANY apply:
- Tier is HEAVY.
- User demanded strict, rigorous, or proper review.
LIGHT tier records a self-review in the notepad instead: re-read the
diff, run diagnostics, confirm each criterion's evidence, and state in
one line why the tier held.
Procedure (NON-NEGOTIABLE):
1. Spawn a child with `fork_context: false` and a self-contained reviewer
assignment in `message`. The `multi_agent_v1.spawn_agent` schema cannot select a
TOML-backed reviewer role, so paste the reviewer requirements into
the message.
Pass: goal, success-criteria, scenario evidence, full diff, notepad
path.
2. Verify each reviewer concern yourself. A concern blocks only when
it names a success criterion the evidence fails; record concerns
that cite no criterion as notes with a one-line reason — fixed or
declined at your judgment.
3. Fix every criterion-cited blocker. Re-run ONLY the scenario QA
affected by the fix; capture fresh evidence for the delta. Update
notepad.
4. Re-submit to the SAME reviewer at most twice, passing only the
delta diff, the blockers it cited, and the already-approved criteria
marked out-of-scope. An approval whose only remaining items are
notes counts as approval.
5. On approval, declare done. If criterion-cited blockers remain after
two re-reviews, stop and surface them to the user (mirroring the
