| name | ultrawork |
| description | Parallel execution engine for concurrent agent tasks. Use for "run in parallel", "concurrent execution", and "ultrawork". |
| trigger | /oma:ultrawork |
Skill: ultrawork
Execute multiple tasks in parallel using coordinated agent sub-processes.
When to Use
- Multiple independent tasks that can run simultaneously
- Time-critical work requiring parallel execution
- Batch operations on separate files or modules
- When tasks have no interdependencies
How Ultrawork Works
- Identify — find tasks that can run independently
- Dispatch — launch parallel execution contexts
- Coordinate — manage shared resources and dependencies
- Collect — gather results when complete
- Integrate — combine outputs into coherent result
Task Independence Check
Tasks are independent when:
- They don't read/write shared state
- They don't depend on each other's output
- They can run in any order
- They don't compete for resources
Parallelization Patterns
Embarrassingly Parallel
- Multiple files processed independently
- Multiple test suites on different modules
- Multiple documentation pages generated
- Lint/format checks on separate components
Fan-out/Fan-in
- Main task spawns sub-tasks
- Sub-tasks run in parallel
- Results aggregated at end
Ultrawork Modes
ultrawork:parallel
Run all tasks simultaneously. Use when tasks are truly independent.
ultrawork:staggered
Offset start times to prevent resource contention. Use for API rate limits.
ultrawork:adaptive
Dynamic concurrency based on system load. Use for resource-intensive tasks.
Output Format
## Ultrawork: {task description}
### Execution Plan
| Task | Dependencies | Est. Duration |
|------|--------------|---------------|
| {task 1} | none | {time} |
| {task 2} | none | {time} |
| {task 3} | task 1 | {time} |
### Execution
- **Mode:** {parallel|staggered|adaptive}
- **Concurrency:** {n} tasks
- **Started:** {time}
### Results
| Task | Status | Duration | Output |
|------|--------|----------|--------|
| {task 1} | ✅ | {time} | {summary} |
| {task 2} | ✅ | {time} | {summary} |
### Summary
- **Total duration:** {time}
- **Effective time:** {time} (parallel) vs {time} (sequential)
- **Speedup:** {n}x
- **Failures:** {n}
Constraints
- Verify independence before parallelizing
- Set appropriate timeout per task
- Handle partial failures gracefully
- Don't over-parallelize (diminishing returns)
- Respect rate limits and quotas
<Do_Not_Use_When>
- Tasks have interdependencies or shared state that could cause race conditions
- The user explicitly wants to see sequential reasoning ("walk me through this step by step")
- A single change touches the same file across multiple parallel tasks (merge conflicts guaranteed)
- The task is I/O bound with a very low number of operations (parallel overhead exceeds serial time)
- Running in Auggie with limited context window — parallel tasks consume more tokens per round
- The user invoked
/oma:ralph or /oma:ultraqa — those modes have their own coordination logic
</Do_Not_Use_When>
<Tool_Usage>
- executor: The primary worker — ultrawork dispatches executor agents to run tasks in parallel. Each executor works in its own context with no cross-agent state sharing.
- planner: Use before ultrawork to analyze task independence and decompose the work into non-conflicting subtasks
- architect: Consult when tasks involve architectural decisions — ensure parallel changes don't accidentally create inconsistent design decisions
- Direct Bash tools: For truly trivial independent ops (e.g., linting 10 files in parallel), use Bash with background jobs directly rather than spawning agents
</Tool_Usage>
<Why_This_Exists>
OMA orchestrates Auggie agents that work on real codebases. Some tasks are genuinely parallel — lint 10 files, generate docs for 5 modules, run independent test suites. Doing these sequentially in Auggie's session model wastes time and burns context tokens. ultrawork provides the coordination pattern (identify → dispatch → coordinate → collect → integrate) so parallel execution is deliberate and safe rather than chaotic.
</Why_This_Exists>
Good Usage
Embarrassingly parallel file processing:
User: "Lint all 12 TypeScript files in the src/ directory"
Agent: /oma:ultrawork
OMA: [Analyzes — all 12 files are independent]
OMA: [Dispatches 12 parallel executor tasks, one per file]
OMA: [Collects: 12/12 pass, 0 failures]
OMA: [Integrates: Summary report of all lint results]
Parallel exploration before implementation:
User: "Audit all 6 skill directories for missing SKILL.md sections"
OMA: [Dispatches 6 parallel explorer agents, one per skill directory]
OMA: [Collects 6 audit reports]
OMA: [Integrates into a single gap analysis]
Bad Usage
False independence — same file touched twice:
User: "Refactor the auth service and update all callers"
OMA: [Ultrawork dispatches 2 parallel tasks: refactor auth + update callers]
Task 1 modifies auth.ts; Task 2 is waiting for the new API to exist
→ Race condition: Task 2 either fails or works on stale interface
→ Should use ralph mode: sequential refactor-then-update chain.
Over-parallelization:
User: "Echo 'hello' in 5 parallel processes"
OMA: [Spawns 5 executor agents for echo]
OMA: [Result: same as running echo once, but 5x the token cost]
→ Use Bash background jobs directly.
<Escalation_And_Stop_Conditions>
- Stop and report: A task in the parallel set fails — report which task failed, surface the error, stop collecting further results
- Continue with partial: A non-critical task fails but others succeed — report failure, continue waiting for remaining tasks
- Stop and escalate: A failure reveals an architectural inconsistency (e.g., two parallel tasks made conflicting design decisions) — escalate to architect
- Escalate to user: All tasks succeed but integration fails (incompatible outputs) — present the conflict to the user for resolution
- Hard stop: User says "cancel" — stop all active tasks immediately, report partial results
</Escalation_And_Stop_Conditions>
<Final_Checklist>
