mass-ulw
Executes multiple tasks sequentially or in parallel, managing dependencies. It's useful for large jobs with many parts that need to be done in order.
What it does
This tool organizes tasks that need to be done in a specific order. It ensures one task only starts after previous ones are finished, allowing you to manage complex jobs in stages.
When to use it
- ✓When you have a list of tasks where some depend on others being completed.
- ✓When organizing a multi-step process, like gathering information and then processing it.
- ✓To manage work in 'waves' or phases, where each phase has its own tasks.
Example of what to ask your AI
“Organize these tasks: collect data, analyze data, then generate a report. Analysis can only start after collection, and the report after analysis.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
You define the tasks and specify which ones must be completed before others can begin. The tool runs these tasks in the correct order, allowing you to track progress and retry steps if needed.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add code-yeongyu/oh-my-openagent --skill mass-ulwOr download just the file:
curl -L https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/packages/omo-senpi/skills/mass-ulw/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
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
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 orders nodes and substitutes nothing into a prompt, so data travels through a handoff file the upstream prompt names and the downstream prompt reads. 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.
Ask a decision only the user can make (scope, spend, anything irreversible) from the main session through the question tool, with header Authorize (권한 in Korean) and required: true on the call, before starting the run that depends on it - never from an eval cell or a node prompt. A timed-out, dismissed, or unavailable answer is not an answer, even when the tool result says to continue on your best judgment: do not start that run.
Running a dag - eval is the default
Build and run every dag INSIDE an eval cell. The eval kernel installs the tool.workflow proxy and the extension publishes a small JS SDK at OMO_DAG_SDK_ROOT; driving runs from a cell is what unlocks the orchestration patterns in references/planning.md (data-driven graph construction, multi-run composition, concurrent runs, adaptive retries).
JS cells import the SDK from the path the extension publishes:
const sdk = await import(`${env("OMO_DAG_SDK_ROOT")}/sdk.js`)
const dag = sdk.define({ key: "docs-refresh", name: "Docs refresh" })
dag.node({ id: "audit", category: "unspecified-low", prompt: "Audit docs/ for stale API references and list each stale file with the outdated claim." })
…
FAQ
What is a 'task DAG'?
It's a way to visualize tasks and their dependencies, like a flowchart where arrows show the order things must be done.
Can I redo a step if something goes wrong?
Yes, the tool allows you to restart or fix specific steps without having to begin everything again.
Do I need to define all tasks at once?
You define the tasks for one phase at a time. If you need to add or change something later, you can adjust the plan.
Details
Original description by the author
Drives dependency-ordered child work through the native workflow tool, each phase's stages defined up front in one run, with retry/amend/send recovery. Use when the user asks for mass-ulw, a DAG of tasks, or fan-out work where some tasks must wait on others.
Popularity
- GitHub stars
- 70k
- Ranking position
- #1727
- License
- NOASSERTION
- Updated
- 10/16/2026
Comments
- …
More skills from this repository
comment-checker
Helps your agent understand and respond to feedback from automatic comment checkers. It's useful when the agent needs to process information from tools that automatically review code or content.
code-yeongyu/oh-my-openagent
lcx-contribute-bug-fix
Helps your agent contribute bug fixes for LazyCodex-related projects. It creates issues or pull requests to ensure code quality.
code-yeongyu/oh-my-openagent
lcx-doctor
Lets your agent check the health of LazyCodex and Codex CLI installations. It's useful when the system behaves oddly after updates or changes.
code-yeongyu/oh-my-openagent
lcx-report-bug
Helps your agent report bugs in detail for LazyCodex projects. It creates issues with useful information for developers to fix the problem.
code-yeongyu/oh-my-openagent
Similar skills
agent-architecture-audit
Makes your agent check if everything is working correctly. It finds and fixes problems in AI systems, ensuring they perform as expected.
affaan-m/ECC
agent-eval
Helps your agent compare different AI coding tools. It measures which one is faster, cheaper, and more reliable for specific tasks.
affaan-m/ECC
agent-harness-construction
Makes your agent better understand how to perform tasks. It optimizes the tools and instructions the agent uses to increase its chances of success.
affaan-m/ECC