mass-ulw

Use this skill when the user asks for mass-ulw, a task DAG, staged fan-out, or any multi-agent job where real dependencies exist: task C needs A and B finished first. For fully independent workers, plain parallel task spawns are simpler. Reach for workflow when the ordering itself is the point. A run covers ONE phase, the unit your loop checkpoints (a goal criterion, a worktree, an evidence gate, a ulw-execute plan wave), and NEVER a whole multi-phase job; a harvest wave or a pipeline stage is not a phase. Define EVERY stage of the phase you can already write (harvest, expand, verify, reduce) in that run before start, chained with dependsOn; split it across concurrent runs only when it would exceed task.dag.max_nodes_per_run, counting the nodes later amends add, and start a reducer that reads several runs as its own run once they settle. Start a NEW run for the next phase, and amend a settled run to add nodes whose prompts need content you must read first. Under ulw-loop or ulw-execute, that contract owns the goal, criteria, evidence, and checkpoints; this skill owns only how each phase's run is defined, driven, and recovered.

Planning - MANDATORY first step

Before defining ANY graph, read references/planning.md (relative to this skill's own directory) IN FULL. Do not call sdk.define, sdk.start, or tool.workflow with action: "start" before reading it. It carries the working doctrine this file deliberately omits: how to decompose the request into nodes, how to route each node's category, how to keep parallel write scopes disjoint, the node prompt contract, the verification wave, and the failure playbook. A graph defined without it is unplanned work.

The shape