/hyperpower:run

Take one requirement from start to finish.

Reference

/hyperpower:run "add rate limiting to the signup endpoint"

When to use it

You have one requirement and you want it finished.

What you get

One requirement, finished. A feature with a ten-file diff takes around twelve minutes.

  1. Plans: reads the code and plans the change, with a design step first for UI work.
  2. Builds: writes the code and shows it to you.
  3. Checks: runs the quick checks now and holds the slow ones until you ask.
  4. Reviews and fixes: reviews what it wrote and fixes what comes back broken, up to a set number of rounds.

How it works

You describe one requirement in plain language, and it does the work.

It keeps a record of the run in .hyperpower/runs/<run-id>/. Each step saves its output there. Before the next step reads that output, hyperpowers checks that it is complete and well formed. If a plan comes out broken, the run stops before any code is built from it.

On UI work, design is the only step that waits for you. Every other step either finishes or stops the run.

Rough timing: twelve minutes for a feature task with a ten-file diff, and ninety seconds for a trivial one. Run /hyperpower:route first to see which kind you are about to pay for.

Checks are picked by what they cost. A check that finished inside checks.auto_under_seconds last time runs on its own. A slower one waits, and the run tells you its name and roughly what it would cost. Say "check it" to run the rest, and say ship, commit or open a pull request and it runs everything without being asked.

How much of the rest happens depends on how much of your Claude plan is left. A plan with room runs the full pass. A plan near its limit runs a lighter one and says so in the first line. Set effort in hyperpower.yml to decide it yourself, or say "go deep" for one run.

If a required check cannot run, the run stops. For example, if tsc is missing, the run stops and tells you the tool is missing. A check that did not run never counts as a pass, and neither does one that was deferred.

Keep the requirement to one thing. "Add rate limiting to signup" works. "Add rate limiting and also refactor the auth module and fix that flaky test" gives you a worse plan and a diff nobody wants to review.