ultrapowers
A parallel execution engine for approved Superpowers plans.
The bottleneck
Superpowers gives Claude Code a disciplined path from idea to merged code: brainstorm the design,
write a structured implementation plan, then execute that plan task-by-task with independent
review. The execution step, however, is serial by design. Superpowers' executors
(subagent-driven-development, executing-plans) run one task at a time, because execution
shares a single working tree — parallel tasks would trample each other's files.
Most plans don't need that caution everywhere. A six-task plan often has four tasks that touch
disjoint files, and with a sequential executor you wait for them in single file anyway.
ultrapowers is an alternative execution engine for exactly that step, built on
Dynamic Workflows — the orchestration engine
Anthropic recently shipped in Claude Code (research preview; you may know it as the ultracode
keyword), which lets one script coordinate up to 16 parallel subagents while keeping intermediate
results out of the main context window. ultrapowers reads the same approved plan, works out which
tasks can safely run at the same time, and hands the Workflow runtime a committed orchestration
script that runs them in parallel waves — each task in its own git worktree, each result
independently reviewed, everything merged onto one integration branch for your approval. Same
plan, same discipline, same human gates; parallel throughput on the parts of the plan that allow
it. And if you've been curious what ultracode can actually do, an approved plan is about the
most structured test drive it gets.
New to Superpowers? It's a plugin that teaches Claude Code a rigorous build workflow
(brainstorm → plan → execute → review). Install it first — ultrapowers plugs into that workflow at
the "execute the plan" step: brainstorming, planning, and branch-finishing hand off to superpowers skills at runtime, while the execution-time review discipline is baked in from superpowers sources at build time (drift-tested, manually re-baked).
Why you might want it
- Throughput where the plan allows it. Independent tasks run concurrently (up to 16 agents);
dependent tasks wait only for the prior wave to land. Plans too small or too entangled to benefit
are detected up front and run sequentially through the same machinery (see Cost honesty below).
- Deterministic orchestration — and deterministic compilation. The engine is a frozen,
version-controlled Dynamic Workflow script (
skills/ultrapowers/harnesses/waves.js) with the review
discipline baked in at build time and drift-tested against its reference sources. A run never
improvises its own orchestration and never depends on live superpowers skill resolution. And for
marked plans (see ultraplan below), the wave computation itself is no longer model judgment: an
executable compiler (skills/ultrapowers/scripts/compile_plan.py) parses the plan — fence-aware —
into waves, dispositions, and dependency edges, reserving judgment for heuristic classifications
it explicitly flags.
- Built for drift. ultrapowers depends on two substrates it doesn't control: superpowers'
plan conventions and the experimental Workflow engine. Both are tripwired. Compat tests
(
tests/test_superpowers_compat.py) read the vendored Superpowers snapshot and fail loudly if
the contract ultrapowers parses changes (validated against the vendored Superpowers v6 snapshot (dev 08fc48c) in tests/fixtures/superpowers-v6/, attested in the skill); a
zero-agent probe workflow launches before every real run, so engine drift becomes a clean
sequential fallback instead of a mid-run crash.
- Review that understands parallelism. Each task is verified by an independent reviewer that
diffs the work against the exact integration SHA the task built on (
BASE...HEAD) — not against
main. Without that anchor, a reviewer in wave 3 would see waves 1–2's merged work in the diff
and flag it as scope creep. Review depth is set per task: routine tasks get one pass, high-stakes
tasks two independent passes.
- Nothing fails silently — and one failure costs one task. The test suite runs once before the
first task, so pre-existing failures aren't pinned on the wrong agent. A crashed agent call
degrades to a single failed task instead of killing the run; a failed task blocks its declared
dependents rather than letting them build on work that never landed; blocked tasks, merge
conflicts, deferred work, reviewer disagreements, and autonomous judgment calls all surface in a
structured end-of-run report — with per-task cost signals (model tier, review depth, fix rounds)
so you can see whether the parallelism paid off.
How a run works
You invoke /ultrapowers <plan-path> from inside the target repo. The skill then:
