Ultrawork

Ultrawork

This is a Hermes-native ultrawork workflow skill.

Why This Exists

ultrawork exists to split an accepted implementation plan into independent lanes without letting parallelism 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).

Do Not Use When

• The work touches the same files or invariants in ways that need one owner.
• 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.
• [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

• All work lanes are disjoint by file, invariant, or responsibility before preparing parallel handoffs.
• Each lane has acceptance criteria, verification command, worker protocol expectation, and review owner.
• When Hermes owns the coding path, use hermes_coding_harness/v1 to separate builder, verifier, reviewer, docs, and PR lanes.