ultrawork

name	ultrawork
description	High-throughput execution for many independent small tasks. Use with /ultrawork when work can be batched safely.

Ultrawork

Use /ultrawork when there are many independent, low-conflict work items that can be batched.

When to use

• 5+ independent tasks with no shared files
• Work is mechanical or repetitive (e.g. "fix all type errors", "update all imports")
• Each task can be verified independently

Do not use when

• Tasks share files or have ordering constraints — use /ralph
• Tasks need design decisions — use /ralplan first
• Fewer than 5 items — just do them inline

Composition

Ultrawork is the batch-execution branch of /omp-autopilot Phase 3 — a sibling of /ralph (single linear task) and /team (parallel panes), not nested inside them:

/omp-autopilot → /ralph  OR  /team  OR  /ultrawork

Pick /ultrawork when the work is many independent mechanical items. It can also be invoked directly.

Steps

1. Inventory

Register the batch FIRST — before editing any file, read [OMP SESSION] from SessionStart context and run omp ultrawork start "<objective>" --task-count <n> --session-id "<session>". This is mandatory: it tracks the run so omp ultrawork status/cancel and /team nudges can see it, and binds nested execution to the active /goal. Skipping it leaves the batch invisible to the CLI. (For fewer than 5 items, don't use ultrawork at all — just do them inline.) Then list all tasks. For each, note the files it touches. Flag any collisions.

2. Dependency check

If tasks have ordering constraints, group them into waves:

• Wave 1: tasks with no dependencies (fire all at once)
• Wave 2: tasks that depend on wave 1 results
• Complete each wave before starting the next

If all tasks are independent, use a single wave.

3. Execute

Process each wave. For each task in the wave:

• Execute the change
• Verify it individually (test, lint, type-check)
• Mark as done or failed

4. Report

Summarise: completed, failed, blocked. Then clear the tracked state with omp ultrawork cancel.

Stop conditions

• Failure rate > 30% — stop remaining tasks, report what failed and why
• Shared file collision discovered — stop, re-partition, or escalate to /ralph
• Ambiguous task — skip it, escalate to /ralplan

Rules

• Verify each batch before moving to the next
• If a task is ambiguous or risky, escalate — don't guess
• Commit after each successful wave, not at the end

Output

• Waves — how tasks were grouped
• Completed — items done with evidence
• Failed/blockers — items that couldn't be completed and why
• Verification — test/lint/build results per wave

Cost/token note

This skill can drive multiple tool calls or long-running output. Use omp cost [--today] [--session <id>] for local hook-ledger estimates only; it is not provider billing. Keep injected summaries concise and prefer bounded output when rerunning noisy commands.