---

name: ulw-execute description: "Executes a written ulw-plan work plan with Boulder state, evidence ledger, worktree discipline, and parallel subagents. Use when the user says ulw-execute or asks to run a .omo/plans plan."

ABSOLUTE RULE: YOU ARE AN ORCHESTRATOR — NEVER THE IMPLEMENTER

YOU DO NOT WRITE CODE. YOU DO NOT EDIT PRODUCT FILES. YOU DO NOT RUN QA YOURSELF. EVERY unit of implementation, test, QA, and review work MUST be delegated to a spawned subagent. NO EXCEPTIONS. Your hands touch only plan selection, .omo/ state (Boulder, ledger, plan checkboxes), decomposition, dispatch, verdicts, and evidence records. About to edit a product file or run an implementation command yourself? STOP. SPAWN A WORKER INSTEAD. Orchestrate at MAXIMUM PARALLELISM: every independent unit runs concurrently; only named dependencies serialize.

Codex Harness Tool Compatibility

Translate any OpenCode-only tool name in an inherited example to its Codex equivalent:

| OpenCode example | Codex tool to use | | --- | --- | | final-review task(...) | multi_agent_v1.spawn_agent({"message":"TASK: act as a rigorous reviewer. ...","agent_type":"lazycodex-gate-reviewer","fork_context":false}) | | worker task(...) | multi_agent_v1.spawn_agent({"message":"TASK: act as <role>. ...","fork_context":false}) — for implementation workers add agent_type: "lazycodex-worker-<low|medium|high>" when the spawn schema exposes agent_type | | background_output(task_id="...") | multi_agent_v1.wait_agent(...) for mailbox signals | | team_*(...) | multi_agent_v1.spawn_agent + multi_agent_v1.send_input + multi_agent_v1.wait_agent + multi_agent_v1.close_agent |

When translating load_skills=[...], name the skills inside the spawned agent's message. If a code block below conflicts with this section, this section wins.

Codex exposes ONE of two subagent tool surfaces per session; check your own tool list and route accordingly. If multi_agent_v1.* tools exist, use the table above as written. If instead a flat spawn_agent with a required task_name exists (multi_agent_v2), rewrite every multi_agent_v1.* example: multi_agent_v1.spawn_agent({...,"fork_context":false}) becomes spawn_agent({"task_name":"<lowercase_digits_underscores>","message":...,"agent_type":...,"fork_turns":"none"}) ("all" only when full parent history is truly required); send_input becomes send_message; do not call close_agent/resume_agent (finished agents end on their own; followup_task re-tasks one, interrupt_agent stops one); wait_agent takes only timeout_ms and returns on any child mailbox activity. On the v2 surface agent_type may be absent from the spawn schema — when absent, omit it and describe the role inside message. If a code block below conflicts with this section, this section wins.

Codex tier mapping for the delegation router

When tier worker agents are installed, map the delegation router's parenthesized difficulty to agent_type: (low) -> lazycodex-worker-low; (medium) -> lazycodex-worker-medium; (high) -> lazycodex-worker-high. Explorer/librarian research lanes keep their own roles. On spawn surfaces without agent_type, state the tier inside message. Difficulty (model power) is orthogonal to the LIGHT/HEAVY rigor tier in step 4 — judge each on its own facts.

Codex Subagent Reliability

Every multi_agent_v1.spawn_agent message is a self-contained executable assignment: TASK: <imperative assignment>, then DELIVERABLE, SCOPE, and VERIFY, with role instructions inside message. Use fork_context: false unless full history is truly required; paste only the context the child needs.

Plan and reviewer agents may run for a long time: spawn them in the background and keep doing independent root work. Between multi_agent_v1.wait_agent calls, back off — double the timeout up to ~5 minutes — instead of spinning short cycles. A timeout only means no new mailbox update arrived; treat a running child as alive. Require WORKING: <task> - <current phase> before long passes and BLOCKED: <reason> only when progress stops. Keep the parent visibly alive with active subagent count, names, and latest WORKING: phase. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly BLOCKED:, or no longer running — then record inconclusive (never a pass), close if safe, and respawn a smaller fork_context: false task with the missing deliverable.

ulw-execute

Execute a work plan until every top-level checkbox is complete. This skill pairs with the harness's ulw-execute continuation hook, which re-injects the next turn while .omo/boulder.json says this codex:<session_id> still has unchecked plan work.

Usage

$ulw-execute [plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]

• plan-name (optional): a full or partial file stem under .omo/plans/.
• --worktree (optional): reuse an existing task-owned worktree for the first phase instead of creating one; every phase runs in a task-owned worktree regardless.
• --make-pr (optional): deliver each phase's worktree as a pull request — push the branch, open a reviewer-readable PR, hand off with the URL, and merge only if the user asks.
• --ship (optional): full delivery lifecycle; implies --make-pr. After the PR opens, stay on the job until it is MERGED: watch CI and review gates, fix failures and address feedback from the worktree (fresh QA evidence for behavior changes), merge per the repository's merge policy, then remove the worktree and sync .omo/ state back.

Goal and todo discipline (MANDATORY)

Do ALL of this immediately after the plan is selected, BEFORE the first implementation dispatch. Skipping any step is a defect.

1. Set the goal, in detail. When a goal tool is available (create_goal), call it with a DETAILED objective: the plan name and path, the concrete end state, the phase and task counts, the delivery mode (direct, --make-pr, or --ship), and how completion will be verified. One work session = one registered goal (the goal tool holds one active goal); each phase then carries its own concrete goal — the ledger entry Phase 2 records before the wave's first dispatch, defined from the previous phase's landed and verified evidence. No goal tool -> record the same objective as the first ledger entry.
2. Register every phase and task as todos. Mirror the plan into the todo/plan tool of your harness: one phase per plan wave, one todo per column-zero checkbox (including the final verification wave). Register ALL of them up front - never keep tasks in memory only.
3. Keep them current at every moment. Mark a todo in_progress when its work dispatches and done immediately after its verification passes. Never batch-complete at the end, never execute work that is not a registered todo; discovered work — a pre-existing bug, failing test, stale doc, or wrong guidance — is appended to the plan as a checkbox, mirrored as a todo before it runs, and fixed to the ideal state, never deferred as a follow-up. A worker that meets a defect outside its assigned files reports it instead of fixing it; only the orchestrator appends the checkbox and dispatches it to a correctly scoped unit. The todo list, Boulder state, and plan checkboxes must always tell the same story.

Phase 1: Select the plan

1. Read .omo/boulder.json if it exists.
2. List work plan files under .omo/plans/.
3. If plan-name was provided, select the matching plan.
4. If exactly one active or paused Boulder work exists for this session, resume it.
5. If no active work exists and exactly one plan exists, select it.
6. If no active work exists and there is no selectable plan, enter No-plan bootstrap.
7. If multiple plans remain possible, ask one focused selection question.

No-plan bootstrap

When the user explicitly said start work / $ulw-execute and no selectable plan exists, treat that phrase as approval: bootstrap ulw-plan to create the approved plan before execution and implementation, instead of stalling or asking for generic approval again. A brief or notes file without waves, checkboxes, and acceptance criteria is NOT decision-complete — enter this bootstrap too.

1. Invoke the ulw-plan skill from the current request and require its dynamic adversarial workflow: collect, verify, design, adversarial plan-review, synthesize.
2. The generated work plan must be saved under .omo/plans/<slug>.md before implementation or Boulder state writes that point at plan work.
3. Use maximum safe parallelism in the generated plan: independent files/tasks fan out; same-file writes, shared state, and named dependencies serialize.
4. Preserve safety boundaries. Ask one focused question only when the objective is missing, destructive, or has a safety/product ambiguity that repository exploration cannot resolve.
5. After the plan exists, continue directly to Phase 2.

Phase 2: Create or update Boulder state

Write .omo/boulder.json before implementation starts. Prefix session ids with codex: so the continuation hook can identify its own session.

{
  "schema_version": 2,
  "active_work_id": "<work-id>",
  "works": {
    "<work-id>": {
      "work_id": "<work-id>",
      "active_plan": ".omo/plans/<plan-name>.md",
      "plan_name": "<plan-name>",
      "session_ids": ["codex:<session_id>"],
      "status": "active",
      "worktree_path": null
    }
  }
}

Every phase (plan wave) runs in its own task-owned worktree with its own goal: before the wave's first dispatch, record the wave's goal — its checkboxes and their acceptance criteria — as a ledger entry, then git worktree add <repo>-wt/<plan>-<wave> <branch off the integration base> (or verify a --worktree path with git worktree list --porcelain), store the absolute path as worktree_path, run every edit, command, test, and evidence capture inside it; the wave lands on the integration base once its checkboxes are verified (direct merge, or the PR under --make-pr/--ship), and the next wave branches from that landed base.

Parallel delivery lanes (teams and worktrees)

Solo orchestration with parallel background workers is the default topology. Decide once, when the wave's lanes are known, and record the verdict in the ledger:

• Independent lanes -> parallel workers. Separate files, no shared contract: one parallel spawn burst; no team.
• Dependency-ordered lanes -> one workflow run per wave. Sub-tasks with real ordering between them (C needs A and B finished first) and a harness with a native workflow tool: dispatch the wave as ONE run (one producer node per lane plus a verification node); recover inside it with retry/amend/send; let node completions wake you instead of arming per-lane watchers; the next wave is a NEW run (or amend when only the definition changed) — never one graph for the whole plan. Read the mass-ulw skill's SKILL.md and references/planning.md IN FULL before defining any graph.
• Overlapping lanes -> a team. The lanes touch the same module or contract AND running them concurrently actually finishes sooner: stand up a team (where the harness has one) so one lane's discoveries relay through you mid-flight.
• PR-mode independent lanes -> a worktree per lane. Under --make-pr/--ship, when a wave holds independent checkboxes, give each lane its own branch and task-owned worktree, delivered as its own PR.

Landing rules, regardless of topology:

• Merge per verified unit. A lane lands the moment its own gates pass — it never waits for the slowest sibling. Integrate landed work back into the base the remaining lanes branch from.
• Only the orchestrator merges. Workers and team members never merge and never push the base branch.
• Conflicts are the orchestrator's job. Decide the landing order and tell the later lane what changed; a worker never resolves a sibling's conflict blin