/dag-ulw

name: "dag-ulw"
description: "[omh] Large multi-part job to run on its own: plan it as a graph of small nodes, run the ready ones in parallel through Hermes' delegate_task, verify the goal with a separate node, and repair failed nodes before reporting. Use when the user says: dag-ulw, dag ulw, ulw dag, dag ultrawork, ultrawork dag."
license: MIT
author: "oh-my-hermes maintainers"
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, agent-coordination]
    category: agent-coordination
    phase: dag-delivery
    role: tracker
    quality_tier: evidence-gated
    related_skills: [ulw-work, ulw-plan]

Dag Ulw

This is a Hermes-native `dag-ulw` workflow skill.

Why This Exists

`dag-ulw` exists so a big job runs end to end without the person driving it: the parent plans a graph OMH can validate and draw, runs the ready nodes in parallel on Hermes' own children, verifies the goal with a separate node, and repairs before it reports.

First Steps

• Start at once; there is no plan approval. Write the goal criteria in one line.
• Plan the graph and call `omh_dag action=define` with the complete run `goal` and each node's id, label, category, prompt, depends_on and write_scope; fix every refusal and read the lint before going on. Never `delegate_task` before `define` returns its calls. The saved goal reaches every native task; local VERIFY does not replace goal acceptance.
• Keep the plan todo as the run's layers in ONE tool: `todo_list` when `todo_list` is in your tool list or tool_search finds it (OMH mirrors it), else `omh_todo`. One item per layer, named for what it delivers, never a list of its nodes (the panel draws those); advance it as each layer settles.
• For each call `omh_dag` returns, run its route (`omh_delegate_route`, set or fallback as given), then `delegate_task` with the tasks unchanged; never more calls than it returned. Then end the turn with one status line; never wait or poll.
• On each completion read the node's handoff file and call `omh_dag action=settle` (accepted, failed, or blocked; a provider error is failed with provider_error). Dispatch what it returns in the same turn.
• When the run reports done, check each node against its SCOPE and the goal criteria: extend the run when work is missing, otherwise report.

Do Not Use When

• One small change with one owner and one check: run it directly, or use `ulw-work` when the person named it.
• The plan itself is still undecided and needs a reviewed decision record first; use `ulw-plan`.
• Workers must talk to each other mid-run rather than hand off through files; use `ulw-work` coordinated lanes.

Examples

Good example:

• Prompt: dag ulw: add the export API, its UI button and the docs page, then verify with the full test suite
• Expected behavior: Define four nodes (api, ui after api, docs after api, verify after all), dispatch api, settle from its handoff, dispatch ui and docs together, run the verification node, report with the run summary.
• Why: Three producers with one ordering edge and a shared verification fan-in is the shape the graph is for.

Bad example:

• Prompt: dag ulw fix the typo in README
• Expected behavior: Fix it directly; a one-node graph adds a tool round trip and a status line for nothing.
• Why: One bounded edit has no parallelism or ordering to plan.

Completion Checklist

• The run was defined in `omh_dag` before the first dispatch, and every dispatched node was settled.
• No two concurrently runnable nodes shared a write scope without an edge.
• A separate verification node ran the real command after every producer.
• Every accepted node was checked against its SCOPE; repairs stayed within two cycles per node and extend rounds within two per run.
• The report names what is still open and includes the observed run summary or an explicit run-summary not_available line before any specific next-action question.

Recovery Notes

• A node whose child returned blocked or failed blocks only its dependents: repair it, or report it.
• When `ready` returns no call because no slot is free, end the turn; the next completion frees one.
• When the conversation was compacted, `omh_dag action=status` still finds the run.

Workflow Lane

• Current lane: **Intent -> plan** (`oh-my-hermes`, `meta-router`, `deep-interview`, `context`, `plan`, `ralplan`, `adversarial-consensus`, `codebase-onboarding`, `+9 more`) - clarify, plan, ship, or loop goals.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `skill_view(name='omh-routing', file_path='references/skill-common-rail.md')`.

When to Use

Use when the request is a job of several parts that can run in parallel or in an order (a feature across modules, a migration, a broad cleanup, research then build then verify), or when the person says dag ulw.

Strong routing signals: `dag-ulw`, `$dag-ulw`, `dag ulw`, `ulw dag`, `dag ultrawork`, `ultrawork dag`

Catalog Metadata

Category: `agent-coordination` Phase: `dag-delivery` Hermes role: `tracker` Quality tier: `evidence-gated` Reasoning demand: `standard`

Quality bar:

• When adapting an existing capability, load `skill_view(name='omh-verification-gate', file_path='references/adaptation-quality.md')` before accepting a plan, dispatching work, or claiming completion; carry its criteria and comparisons into tasks and evidence.
• Split first: many small nodes beat one big one, but never split one shared write scope or one judgement.
• Climb the difficulty ladder `quick` -> `unspecified-low` -> `unspecified-high` with a one-line reason per climb; use `ultrabrain` at most once, and a graph whose every node is `deep` or `deep-work` is a routing failure.
• Write every node prompt self-contained, in order: TASK, DELIVERABLE, SCOPE (what it may read and write), VERIFY (the literal command and expected result), STOP WHEN.
• `depends_on` only orders nodes; data moves through the hand