implement-issues

How agents take one issue from the queue to a ready pull request: who does each step, where you approve plans, and which model does which job. Everything below follows the effort and plan approval you pick in the bar above.

/implement-issues

The three settings

Effort

Low, medium or high. It sets how much review and checking each issue gets. Pass it when you start the run. Without it, the run uses the saved setting, and if there is none, it asks you.

Plan approval

When it's on, each issue stops after its spec and plan and waits on a draft plan PR. You comment or add the plan-approved label, and a later run builds it.

Models

One model for each of ten jobs, such as a cheap one for implementation and a strong one for review. Each is set as a tier (cheap, standard or strong) or an exact model name.

Plan approval and models are saved in docs/agents/delivery.md in your repository. The run asks only for what that file doesn't settle, and offers to save your answers after showing you the change. There is no separate setup step.

Agents started per issue, for a plan of N tasks

Full local check runs after the build, plus CI

Full code reads of the branch diff after the build

Who runs what

Each column is one agent, and time runs downward. Only the steps that run at effort are shown, with the blue plan-approval band; turn on plan approval to add its band.

Runs at every effort Runs only at some efforts Plan approval on Runs the full checks Reads the whole diff

Figure 1. One issue end to end at effort. The planner ends once the plan is written. The build lead stays alive to answer the review and fix CI. The review agent is always a new agent, so no one reviews their own work.

Approving plans

Plan approval is off, so each issue is planned and built in one run, with no plan PR. to see how a plan PR moves across runs.

With plan approval on, an issue spans two or more runs. Nothing needs to stay open in between, because the plan PR on GitHub holds the issue’s state.

Figure 2. A plan PR across runs. Comments send the plan back for revision on the next run, up to at effort. Once the cap is reached, it waits for you. Only you add plan-approved.

Effort, side by side

The column is the one this page is showing. Pick another level in the bar to compare.

What effort decides	low	medium	high
How the plan is built	The build lead builds every task itself	A fresh agent per task, reviewed after each	A fresh agent per task, reviewed after each
Fix rounds per task review	none	2	5, rounds 4–5 escalate
Code review on the PR	intent check only	intent check only	intent check and code review
Local check runs after the build	2	3	4
CI fix attempts	1	2	3
Plan revision rounds	1	2	3

What holds at every effort: one whole-branch review ends the build, the checks run before anything is pushed, the build lead answers the review once, and nothing merges.

Figure 3. Agents started per issue at effort.

Stage by stage

Build the queue Dispatcher
- Lists the open issues, then looks at each one’s pull requests and branches.
- Sorts each issue:
  - a plan PR labeled plan-approved is built;
  - a plan PR with unanswered comments gets its plan revised;
  - any other plan PR waits;
  - any other PR or branch is skipped;
  - an issue with neither gets planned.
Settle the settings Dispatcher
- Prints the effort, plan approval, and the model for every job. A model your agent doesn’t offer stops the run.
- Asks for what isn’t saved and offers to save it. Then asks whether to run the issues one at a time or several in parallel.
Plan Planner, one per issue
- Superpowers’ brainstorming works from the issue and decides how big the work is. A project gets a spec, and a quick spec check if it has its own model. A small change goes straight to the plan.
- writing-plans writes the plan. The planner commits the spec and plan, and stops.
- Plan approval is on, so the dispatcher opens a draft plan PR, and the issue waits for you. A later run revises it on your comments, up to , and builds it once you add plan-approved.
- Plan approval is off, so the build starts in the same run.
Build Build lead, one per issue
- The build lead builds every task itself with executing-plans, tests first. No per-task reviews run.
- It runs Superpowers’ per-task loop (Figure 4): a fresh implementer per task, reviewed after each, with up to fix rounds.
- One whole-branch review ends the build, followed by one fix pass if the review finds anything.
Verify Dispatcher
- Reads the log and the diff, then runs tests, lint and typecheck. The output goes to log files, and only results and failures are read back.
Open the draft PR Dispatcher
- The approved plan PR becomes the built PR, on the same branch.A new draft PR opens. At high effort, the full suite runs once more first.
Review A new review agent
- Checks the PR against the issue. The code isn’t reviewed a second time, because the build’s own whole-branch review already covered it.
- Checks the PR against the issue, then reviews the code as well, with the pr-code-reviewer seat.
Answer and mark ready Build lead, then dispatcher
- The build lead fixes each finding, runs the checks, pushes, and replies to every comment.
- The dispatcher re-checks the pushed head.
- The pushed head isn’t re-checked locally: CI is the evidence. Only a repository without CI gets the local re-check.
- CI failures go back to the build lead, up to . Then the PR is marked ready, and merging is up to you.
Report Dispatcher
- One table: each issue’s state, the effort, the plan state, and the model each job ran on.

The per-task loop

At low effort there is no per-task loop. The build lead builds every task itself with executing-plans, tests first, and the whole-branch review at the end is the only review of the build. Pick medium or high to see the loop.

This loop runs once per plan task. At effort, the fix-round cap is .

Figure 4. Superpowers’ task loop at effort. When a task’s findings are still open after round , the build lead decides each one itself and records why.

The ten model seats

All ten can be set in delivery.md. At effort,

Seat	What it does	Runs at	When not set
`planner`	Brainstorming, the spec, the plan, and plan revisions	every effort	session model
`spec-check`	A quick check of a written spec	when a spec exists	the planner’s model
`build-lead`	Runs the build, answers the review, fixes CI	every effort	session model
`implementer`	Builds one plan task	medium, high	asked when the run starts
`task-reviewer`	Reviews one task’s diff	medium, high	Superpowers picks by task size
`re-reviewer`	Checks that a fix addressed its findings	medium, high	Superpowers picks, cheap to mid
`escalation`	Fix rounds 4–5, after an implementer got stuck	high	one tier above the implementer
`final-reviewer`	The whole-branch review that ends the build	every effort	the most capable model
`pr-reviewer`	The agent that reviews the PR	every effort	session model
`pr-code-reviewer`	The code review inside that PR review	high	the most capable model

A value is a tier (cheap, standard, strong) that the file maps to a real model for each platform, session, an exact model name, or, for the implementer only, by-task. For the five seats Superpowers dispatches, your choice is an instruction rather than a guarantee, so the report shows the model each job actually ran on.

What each agent loads

This counts skill and prompt text only, measured from the installed files, for the agents that run at effort with plan approval on. Code, diffs and test output come on top of it. Planning and building are separate agents, so neither one carries both sets of skills.

Figure 5. Kilobytes of instructions for each agent, with tokens estimated at four characters per token. The review agent’s red segment loads only at high effort.

Where the same work repeats

Step after the build	Commit	low	medium
Whole-branch review	A, the built branch
Stage 5 verify	A
Stage 6 suite run	A again	—	—
Code review on the PR	A	—	—
Answering the review	B, after the fixes
Stage 8 recheck	B again	only without CI
CI	B, on GitHub

Diamonds read the whole diff, and circles run the full checks. A review with no findings has no commit B, so there’s nothing to answer or re-check, and CI runs on A. With plan approval on, each plan revision also runs the full checks and CI, even though only Markdown changed.

Likely hot spots

This is a reading of the skills, filtered to what applies at effort with plan approval on. Nothing here has been measured from a real run yet.

Unset jobs still inherit

If the settings file leaves them out, the planner, build lead and review agent use the session model, and the whole-branch review uses the most capable model, as does the PR’s code review. Set those jobs to bring the cost down.

Code written twice

The plan can hold the code, and the build writes it again. A small change skips the spec, but it still gets a plan and a build.

Two identical reviews

At high, the build’s whole-branch review and the PR’s code review read the same diff with the same prompt. Below high, the PR’s code review is off.

Checks of a commit already checked

Stages 5 and 6 both check commit A. The Stage 8 recheck repeats the run the build lead just did.

Checks on a plan revision

A revision changes only Markdown, yet it runs the full checks, and the push triggers CI.

The build lead’s context at review time

It answers the review still carrying the build’s skills and bookkeeping. This is on purpose: the agent that built the code should answer for it.

Sources: implement-issues and its assets, review-prs, answer-pr-reviews, fetch-issues and superpowers-issue-bridge from this repo, plus Superpowers 7.0.0. File sizes were measured on 17 October 2026. The design behind this flow is in docs/superpowers/specs/2026-10-17-delivery-settings-design.md.