mass-ulw
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's dependency-ordered lanes and NEVER a whole multi-phase job; define the next phase as a NEW run (or amend when only the definition changed) in the cell from what the settled run proved. 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
A run is a declarative definition: a stable key (idempotency: re-starting the same key with the same graph reuses the run), a human name, and nodes. Each node has an id, a self-contained English prompt, a category that routes it to the right kind of worker, and optional dependsOn listing node ids that must finish first. dependsOn is ordering ONLY: no upstream output is substituted into a downstream prompt, so write every prompt to stand alone. Optional per-node extras: label, task_summary, description, and load_skills (skill names prepended to that node's prompt).
Route every node by category using the routing table in references/planning.md; the run executes nodes in parallel waves as their dependencies clear.
Goal before start
Every run is goal-bound. In a standalone run, register the goal as written (create_goal, or a # Goal block where no goal tool exists). Under ulw-loop or ulw-execute, the loop's registered goal already covers the run, so register no second goal. The objective names the deliverable the graph produces, and the success criteria carry RESULT VERIFICATION - node and run completion claims are false until proven against captured evidence, the same contract the dag completion directive injects (TREAT AS FALSE UNTIL YOU PROVE IT). The verification wave (references/planning.md) produces the evidence those criteria name; the run ends when the criteria pass, never when the last node reports completion.