ultrapowers

_  _ _    ___ ____ ____ ___  ____ _ _ _ ____ ____ ____
|  | |     |  |__/ |__| |__] |  | | | | |___ |__/ [__
|__| |___  |  |  \ |  | |    |__| |_|_| |___ |  \ ___]

Give your Superpowers Ultrapowers.

Ultrapowers writes the plan and runs it. It grew up alongside superpowers, the popular agent skill for a disciplined build workflow, and it now carries its own plan-authoring skill — so you can hand Claude Code a big, ambitious idea and get back finished, reviewed work, without paying frontier-model prices to build every line, and without reviewing code you'd rather not read.

Ambition is expensive

Have you ever asked Claude to do ambitious work and blown through your five-hour token budget before it finished? (If you haven't, you're not trying hard enough;)

Frontier models invite bigger asks. "Product people" love this. You can finally think at the scale of the whole feature, the whole idea, the whole business, instead of the next function. But pointing a frontier model at a huge body of work and saying "build it" is the most expensive way to get it done. The frontier model writes every line, reviews itself, and drags one ever-growing transcript the whole way. You max out your subscription-subsidized tokens, and the work still isn't finished.

Spend your frontier model where it counts

ultrapowers makes ambition affordable by using your frontier model only where it changes the outcome.

• Your frontier model plans. It thinks hard, once, and writes each task as a contract — what the task must be true of, and the proof that decides it — never a script of steps to retype.
• Cheaper models build. A contract that exact leaves the builder no invention to do about what to deliver, so a cheaper model does it well.
• Your frontier model checks the work. Quality is the one place it never cuts corners.
• Each task stays out of your main session. You don't re-pay for one giant, ballooning transcript.
• It won't over-spend. If a plan won't benefit from the heavy parallel machinery, ultrapowers tells you to use a lighter tool instead.

Honest caveat: the parallel-and-review machinery can cost more than a plain sequential run — it's running extra reviewers and isolated build environments. What it saves you from is what you'd reach for otherwise: asking one frontier model to build the whole thing directly. Against that, the savings are real. ultrapowers isn't "cheap" — it's disciplined. It refuses to waste your tokens.

What you get

1. Affordable ambition. You don't pay frontier prices to write boilerplate. Your frontier model plans and checks; cheaper models do the building in between.

2. Quality you don't have to babysit. Every task is checked by a separate reviewer before it counts — so you don't have to read the code yourself. You make one approval at the end, on the finished result, instead of signing off on code you can't (or don't want to) judge.

3. Faster finishes. (Sometimes.) When the plan allows, independent work runs at the same time instead of one piece after another, so big work lands sooner. That's the cherry, not the headline.

Where Superpowers fits

Superpowers is a popular Claude Code skill that gives Claude a disciplined way to build software: brainstorm the idea, write a plan, execute it, review it. It's excellent — but it builds one task at a time, and it keeps you in the loop the whole way.

Superpowers is an optional companion, not a requirement: brainstorming and its practice skills pair well with ultrapowers, but plan authoring is ultrapowers' own — the ultrawrite skill writes the plan. Bring a spec (however you arrived at it) and ultrapowers takes it from there. Same discipline, less babysitting.

What it adds

• It recommends the right tool for the job — even when that's not ultrapowers. Hand it a plan and it sizes up the work. If a lighter, sequential path would do the job better, it says so. Honesty is a feature.
• It shapes plans to run side by side. When you plan with it, it structures the work so independent pieces can run at once later.
• It runs the build between two checkpoints, not twenty. You approve the plan. It does the work. You approve the finished result. No signing off on every step in between.
• The plan is still readable by anything else. A claims-v1 plan has no steps to follow, but a sequential executor can implement task-by-task from contract plus proof.

When to use it — and when not

Reach for ultrapowers on big, ambitious plans with independent pieces — the kind where parallel work and independent review pay off.

Skip it for small or tightly-connected plans, where the work has to happen in order anyway. There, a plain sequential run is the better tool — and ultrapowers will tell you so rather than spin up machinery you don't need.

In field use the human surface compresses to exactly the designed touchpoints: on a recent 7-task production run the operator's entire involvement was the planning decisions and one physical-world check no tooling could reach (confirming an email landed in a personal inbox) — everything between launch and the pre-merge gate ran autonomously, and the operator's unrelated work-in-progress was restored byte-for-byte.

How it works

ultrapowers runs on an exe.dev fleet you provision — the plugin is the client, and there is one engine, the Flock (factory/flock/engine.mjs). /ultrapowers <plan-path> publishes your approved plan and starts a run on a disposable sandbox of its own; every builder, every probe, every merge and every check execute there. Nothing builds, tests, or merges on your machine. When the run ends, the sandbox opens the pull request on the repository you ran in — ready if its own checks ended green, a draft otherwise — with the evidence linked in its body. If main moved while the run worked, the sandbox first joins the run's work onto the new main (factory/flock/catchup.mjs) and re-runs the plan's probes and checks there; only then does it merge its own pull request. A conflict or a red check leaves that pull request open and unmerged for you.

The clearest way to see what it does is to zoom in — the whole plan, then one task.

The whole plan, at a distance

Here's a question that sounds simple and isn't: in any plan, which work has to happen in order — and which doesn't?

We do things one after another out of habit, and because a single worker can only hold one task at a time. But most of that sequence is an illusion. You can't paint a wall before it's built; that order is real, forced by the work itself. Two different walls, though? Two crews raise them at the same time, and nothing in the world objects. The only thing that genuinely makes one task wait for another is dependency — one task needing something another produces. Everything else only looks sequential because we're used to one pair of hands.

Take away the false order and you're left with the real skeleton of the job: a web of this must come before that. It's smaller than the to-do list makes it look. And it has an exact shape.

That shape has a name — a directed acyclic graph. Directed, because every arrow points from a task to the task that depends on it. Acyclic, because nothing can depend on itself, even the long way around a loop; if it could, the work could never start. Draw each "must-come-before" as an arrow and your plan stops being a list and becomes a map. Tasks with no path between them can run side by side. The depth of the graph is how long the work really takes; its width is how much can happen at once.

<img src="docs/assets/dag.gif" width="840" alt="An approved plan drawn as a directed acyclic graph. A single plan node fans out into independent tasks; dependency arrows cross between them, each task waiting only for what it needs; everything fans back into one merged pull request. Arrows point from a task to the work that depends on it.">

ultrapowers reads your approved plan and derives exactly this graph — from the files each task touches and the probes each task runs, not from a list you write — then runs it as a pool: every task whose dependencies have landed is started at once, and a task that needs another starts the moment that one lands. There is no round to wait for; the shape of the work is the only clock.

Zoom in: one task's life

Pick any one of those circles. Up close, it isn't a dot — it's a claim on a shared board.

The run is a flock of builder agents with no leader. Each builder claims a task from the board and works on its own copy of the repository, only from the task's contract — what must be true afterwards, and the proof that decides it. Between tool calls, each copy takes in what its peers have published through a content-level merge, so a task that reads what another task wrote builds against it as it lands, not after a round. The pool grows and shrinks with the work that is claimable.

Work is measured, not reviewed: a task is done when its own Run: probes pass on the builder's copy, and every published snapshot is tested at the edge with the run-wide Check: lines. A judge reads only what a probe cannot see, and never blocks a task.

If main moved while the run worked, the sandbox catches the run up: it joins the run's work onto the new main through the same merge and re-runs the plan's setup, probes and checks there. A conflict or a red check leaves a draft pull request instead.

It doesn't improvise

The engine that runs all of this is committed and frozen at the sha the launch names; it never writes a fresh version of itself at runtime. Same plan in, same structure out. And every run happens in a sandbox that exists only for that run — nothing it does can touch your checkout, and nothing it leaves behind survives it except the evidence it pushed.

None of this is magic, exactly. It's all premised on a handful of older, sturdy ideas — dependency graphs, clean clones, content merges, disposable sandboxes — each doing one small job well.

TinyApp screens

A TinyApp's screens come out in the look of 1st-Pouf, a small open-source component set by Mojtaba Beheshti, used here under its MIT licence and kept exactly as its author published it. Nobody writes page code for a screen: each one is a short description of which pieces it shows and which action each button runs. The run checks every screen itself and catches a button that is missing or wired to the wrong action before you see it.

See it before you sign

While a TinyApp is being planned, you see its real screen in Claude's Browser pane, not a mock-up. Jev offers two or three arrangements of it, built only from what the app can actually do, and you pick the one you like. Then you pin notes on any part of it in Comment mode — click a button or drag a box around an area and say what should change — and watch each story play out on it. What you sign is the screen the fleet starts building from.

Get started

Four steps, once each. All of it happens inside Claude Code: the agent does the work and asks you to choose. The only things it cannot do for you are the consents that are yours to give in a browser.

1. Install the plugin

From inside Claude Code:

/plugin marketplace add popmechanic/ultrapowers
/plugin install ultrapowers@ultrapowers

Superpowers is optional. ultrapowers authors and runs plans on its own. Install Superpowers alongside it if you want its brainstorming and practice skills as companions.

2. /ultrapowers setup

Run /ultrapowers setup and answer what it asks. The agent runs the doctor, reads its rows — exe-dev, capacity, claude, accounts, github, integrations, evidence, verb-drift, kata, cloudflare — and fixes every red row with you, offering each choice as options rather than asking you to invent an answer. Setup is safe to re-run: the doctor (fleet/doctor.mjs) only reports, and setup only touches what is still red.

Your evidence repository. Every run's plan and record live in one private repository of your own, never in the repository being built — so you can run on someone else's repository too. The evidence row walks its one-time setup in three steps: name it in ~/.ultrapowers/fleet.json as "evidence": "<owner>/<repo>" (a launch can override it with --evidence-repo <owner>/<repo>), create it with gh repo create <owner>/<repo> --private, and give the fleet its integration with node fleet/target.mjs <owner>/<repo>. A run on <owner>/<repo> then leaves its record in that repository's runs/<owner>-<repo>/<N>/, at the tag <owner>-<repo>/run-<N>.

Three browser consents are yours to give, because only you can give them. You sign up at exe.dev and add your ssh key; you approve the GitHub app on your account; you approve ultrapowers on claude.ai, which hands back a single code, copied to your clipboard, where the agent picks it up. Everything else setup does itself.

What a run costs. A run bills your Claude Max subscription through an edge proxy, plus one exe.dev VM for the hours the run is up.

3. Write the plan

Authoring needs no fleet and no account. A session begins with one sentence — what you will be able to see or do after the run — and there are three places that sentence comes from:

• An issue you filed. The common start. Write what should be true afterwards, in your own words, then ask for the ultrawrite skill and name the issue: that sentence becomes the plan's Claim, quoted, and you confirm it rather than write it again.
• An idea you can spec in one sitting. Ask for ultrawrite and it asks you scenario questions — after this run, what can you see that you couldn't before? — with two or three concrete options to pick from. If you have Superpowers installed, its brainstorming skill is a good companion here; it ends by handing off to ultrawrite.
• A foggy program, many sessions. Chart it first (a map of decision tickets); each destination is a spec that ultrawrite takes unchanged.

Whichever way you arrive, ultrawrite writes a claims-v1 plan — each task a contract and the proof that decides it, no steps to retype. You read that plan and approve it. That is the first of your two checkpoints.

4. Build

In the repository you want built, run /ultrapowers <plan-path>. The plan rides to the sandbox on your evidence repository's live/<owner>-<repo>/run-<N> branch, and the run happens there: the builders, the probes, the merges, the checks. Watch it or walk away.

At the end you get the finished result: the sandbox opens the pull request on that repository — ultrapowers itself is just one such repository, and ultra/integration-run-<N> is the only branch a run ever pushes to it. Its body carries the gate receipt and links the run's record in your evidence repository. The pull request merges itself on the run's own evidence — once its own gate is green and main has not moved off the tip it caught up to. Launch with --hold and the pull request stays open instead — your second checkpoint, yours to merge or close. A run the gate parked leaves a draft pull request, and the sandbox merges nothing after a park: acknowledge it by hand — mark it ready, gh pr update-branch <N> if it is behind main, gh pr merge --squash <N>. Either way the run is over and the sandbox is gone.

One hazard: keep the GitHub integration personal

--act-as-user is unavailable on team integrations. On an exe.dev team account that means every pull request a run opens is authored by exe-dev-github-integration[bot] rather than by you, and nothing downstream can undo it. Set the fleet up on your personal exe.dev account, and if setup offers you a choice of accounts, the GitHub integration has to stay personal.

Go deeper. The full mechanics — how plans become parallel work, how reviews are anchored, how the engine handles failure — live in skills/ultrapowers/SKILL.md and skills/ultrapowers/references/.

The intent tray

When Claude has a screen ready for you to look at, it opens the intent tray beside the chat (its tool for that is show_screen). The tray is where you tell Claude what you want from that screen: pick a version, add notes, and send them all back with one press.

A band above the prompt carries three buttons: Add note (n), Send (s) and Clear (c). Click a button, or press its letter once the band has focus (ctrl+x tab). The band shows only while the tray holds a screen, pick or note, and Send and Clear empty it. In the pane the note box takes typing, so click a version, Send or Clear there. /tray opens the tray yourself, and /note <element>: <note> adds a note about one element. Send hands everything — your pick first, then each note in the order you added it — to Claude as one message.

A preview page can leave picks and notes for the tray too: it writes them, one JSON object per line, to .ultrapowers/feedback.jsonl in the session's working directory, and the tray takes them in as if you had made them.

The tray needs Claude Code 2.1.287 or later.