
Ultrawork
- 54 installs
- 40 repo stars
- Updated August 4, 2026
- akillness/oh-my-skills
ultrawork is a Claude Code/Codex skill that runs a high-parallelism work burst across independent implementation or cleanup lanes via $ultrawork or $ulw.
About
ultrawork runs a high-parallelism work burst for independent implementation or cleanup lanes. A developer invokes $ultrawork or $ulw to parallelize separable work such as separate packages, routes, docs, tests, or migrations when shared-file contention is low. It matters because it keeps file ownership explicit and serializes shared edits so parallel lanes integrate cleanly with one final verification pass.
- Runs a high-parallelism work burst across independent implementation or cleanup lanes
- Splits separable lanes with explicit file ownership and serializes shared-file edits
- Runs one full verification pass after integrating the parallel lanes
Ultrawork by the numbers
- 54 all-time installs (skills.sh)
- Ranked #1,053 of 2,715 Automation & Workflows skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
ultrawork capabilities & compatibility
- Capabilities
- parallel execution · lane splitting · worker coordination
- Use cases
- orchestration · refactoring · testing
What ultrawork says it does
Run a high-parallelism work burst for independent implementation or cleanup lanes.
Name owned files or directories before editing.
npx skills add https://github.com/akillness/oh-my-skills --skill ultraworkAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 54 |
|---|---|
| repo stars | ★ 40 |
| Last updated | August 4, 2026 |
| Repository | akillness/oh-my-skills ↗ |
What it does
Parallelize separable implementation, cleanup, docs, tests, or migration lanes with explicit file ownership and a final verification pass.
Who is it for?
Parallelizing separable implementation, cleanup, docs, test, or migration lanes with low shared-file contention
Skip if: Tasks needing a single careful design decision, shared runtime state, or constant coordination
When should I use this skill?
The user invokes $ultrawork or $ulw or asks to parallelize separable work quickly
What you get
Parallel lanes with explicit file ownership integrated with one full verification pass
- Parallel lane plan with owned files
- Integrated result
- Verification pass
By the numbers
- 5-step workflow (identify, name shared files, run parallel, integrate, verify)
Files
Ultrawork
Use this exact-name skill for $ultrawork and $ulw so the parallel-work intent activates directly.
When to use this skill
- The user explicitly invokes
$ultrawork,$ulw, orultrawork. - The task has separable implementation, cleanup, docs, tests, or migration lanes.
- Shared-file contention is low enough to integrate at the end.
Instructions
Run the fit check, split lanes, keep file ownership explicit, and verify after integration.
Fit Check
Use ultrawork only when the work can be split into mostly independent lanes:
- separate packages, modules, routes, docs, tests, or migrations
- low shared-file contention
- clear merge order or a small integration step
Do not use it when the task needs a single careful design decision, shared runtime state, or constant cross-worker coordination.
Workflow
1. Identify independent lanes and the files each lane owns. 2. Name shared files that must be edited last by the coordinator. 3. Run safe lanes in parallel where tools/runtime allow it. 4. Integrate shared-file changes deliberately. 5. Run the full verification command set once after integration.
Runtime Notes
- In OMX-enabled environments,
$ulwand$ultraworkare the Codex-side
equivalents of Claude /ultrawork.
- In plain Codex sessions, apply the same contract with available local tools:
parallelize reads/checks where possible, keep file ownership explicit, and serialize shared edits.
Route-Outs
- Use
teamfor tmux-backed coordinated workers. - Use
ultraqafor test/build/lint review loops. - Use
autopilotfor full idea-to-verified-code execution.
Examples
$ulw split this cleanup across docs, tests, and API handlers$ultrawork parallelize the migration by package
Best practices
- Name owned files or directories before editing.
- Serialize shared-file edits.
- Run one full verification pass after integration.
References
teamfor shared-state workers.ultraqafor QA cycling.
{
"skill": "ultrawork",
"version": "1.0.0",
"cases": [
{
"prompt": "$ulw split this cleanup across docs, tests, and API handlers",
"expected_output": "The ultrawork skill activates, partitions independent lanes, defers shared files, and verifies after integration.",
"checks": [
"Treats `$ulw` as a direct trigger",
"Requires explicit file ownership",
"Runs full verification after integration"
]
},
{
"prompt": "$team 4:executor \"coordinate this shared migration\"",
"expected_output": "The request should route to team because shared runtime state and coordination are required.",
"checks": [
"Does not compete with exact `$team` requests",
"Routes coordinated worker mode to team"
]
}
]
}
N:ultrawork
D:Exact-name `$ultrawork` / `$ulw` front door for high-parallelism independent work bursts. Use when separable implementation, cleanup, docs, tests, or migration lanes can proceed with clear file ownership; route coordinated shared-state work to `team` and QA/review loops to `ultraqa`.
T:Read|Write|Bash|Grep|Glob
G:ultrawork|$ultrawork|ulw|$ulw|omx|codex|parallel-work|burst-work|independent-lanes
F:Codex CLI|Claude Code|Gemini CLI|OpenCode
S:
1:Split work into independent lanes with explicit file ownership
2:Defer shared files to a coordinator integration step
3:Parallelize safe reads/checks/work where the runtime allows
4:Run full verification after integration
R:
team:Use for tmux-backed coordinated workers
ultraqa:Use for QA/review cycling
autopilot:Use for full end-to-end autonomous builds
Related skills
FAQ
When should you not use ultrawork?
When the task needs a single careful design decision, shared runtime state, or constant cross-worker coordination.
How are shared files handled?
Shared files are named and edited last by the coordinator, and one full verification runs after integration.