/ulw-work

name: "ulw-work"
description: "[omh] Accepted plan awaiting implementation: split it into disjoint parallel lanes with per-lane acceptance criteria, verification commands, and owners; prevents two lanes editing the same file. Aliases: ulw. Use when the user says: ultrawork, parallel work, parallel implementation, parallel then integrate, high throughput, coding team, coordinated workers, finish until done."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, execution]
    category: execution
    phase: parallel-delivery
    role: handoff-guide
    quality_tier: handoff-gated

Ultrawork

This is a Hermes-native `ultrawork` workflow skill.

Why This Exists

`ultrawork` exists to choose one-owner, ordered-dependency, or independent-frontier execution for an accepted implementation plan without letting concurrency blur ownership, verification, worker protocol, worktree isolation, or observed runtime evidence. It also carries four named internal capabilities absorbed from sibling engines: `coordinated_scope` (coordinated worker lanes), `delivery_boundary` (one bounded plan-to-PR cycle), `single_owner_persistence` (one owner finishes and verifies), and `durable_checkpoint` (durable goal ledger with checkpoints and a final gate).

First Steps

• Initialize the phase todo before engine work: declare numbered phases in delivery order with `omh_todo` (todo init) — bootstrap, one implement/verify/deliver task per lane or work unit, independent review lanes, and an evidence-and-cleanup close, with one task per observable outcome — keep exactly one item active while working, and update states as lanes complete; the run walks a bounded, HUD-visible checklist instead of an open-ended reasoning loop. Phase names and task titles are written in English — short, operator-legible labels — even when the conversation runs in another language, since the HUD todo checklist is an operator surface under the repo's English-by-default output contract.

Do Not Use When

• Avoid conflicting parallel writers; use single-owner or ordered execution.
• The plan is not accepted, lane boundaries are unclear, or verification commands are missing.
• The user expects Hermes to secretly execute coding lanes instead of preparing explicit selected-runtime handoffs.
• For a decision spike, use `decision-prototype`.
• [capability:coordinated_scope] The lanes are exploratory research or QA coordination without an accepted implementation plan; frame them with the `coordinated_scope` capability before parallel delivery.
• [capability:single_owner_persistence] The request is a settings-only change, one bounded edit that is explicitly low-risk and has a direct owner and verification path, or a direct answer/diagnosis; use one direct owner instead of opening parallel delivery lanes, a finish-until-done loop, or a goal ledger.
• [capability:delivery_boundary] The user wants an open-ended feedback loop or long-horizon campaign; use `loop` instead.
• [capability:single_owner_persistence] Progress must survive sessions as a ledger with multiple checkpoints and a final gate; use the `durable_checkpoint` capability.
• [capability:durable_checkpoint] One concrete, already-scoped task only needs one owner to finish and verify; use the `single_owner_persistence` capability.
• [capability:durable_checkpoint] The next work must be discovered or reframed repeatedly through research and feedback cycles; use `loop`.
• [capability:durable_checkpoint] Acceptance criteria, current checkpoint, and final gate expectations are too vague to make a goal inspectable.

Examples

Good example:

• Prompt: $ultrawork split the accepted docs refresh, CLI output polish, and test updates into parallel implementation lanes.
• Expected behavior: Create disjoint lane prompts with acceptance criteria, verification commands, and review evidence requirements.
• Why: The work can be split cleanly and benefits from parallel execution discipline.

Bad example:

• Prompt: $ultrawork refactor the central router in five agents at once.
• Expected behavior: Keep one owner or re-plan boundaries before parallelization.
• Why: Shared core logic makes parallel edits likely to conflict or hide regressions.

Completion Checklist

• The phase todo was declared before engine work started and every task reached a terminal state; a run that declared none, or that left tasks pending, is not complete.
• Every concurrently runnable lane is disjoint by write scope, invariant, or responsibility, and every ordered unit carries an explicit acyclic dependency edge, before parallel handoffs are prepared.
• Each lane has acceptance criteria, verification command, worker protocol expectation, and review owner.
• Every Hermes-native lane was routed with `omh_delegate_route` before dispatch, or its parent inheritance was explicitly stated; an inherit-labeled wave is an unrouted wave.
• When Hermes owns the coding path, use `hermes_coding_harness/v1` to separate builder, verifier, reviewer, docs, and PR lanes.
• Worker ACK, dispatch, result, review, CI, and merge evidence are observed or explicitly missing.
• Integration verification ran after lane results before the final status claims completion.
• Changed behavior was exercised through the real user surface after diagnostics and relevant tests passed, and every spawned QA resource has a cleanup receipt.
• The closing brief ends with the observed `omh_run_summary` line (elapsed seconds and token usage) or an explicit run-summary not_available statement — never a model-estimated number.
• [capability:coordinated_scope] The integrated status names which coordination lanes are observed, blocked, or still prepared_not_observed.
• [capability:coordinated_scope] Coordination teardown is explicit: released lanes are named and closed instead of lingering as implicit owners.
• [capability:durable_checkpoint] The goal_status_card/v1 or goal_continuation/v1 names the next action and the final status says complete, blocked, or contin