Superpowers can guide a Claude Code user through a substantial change in an owned Git repository: agree on the design, approve a task plan, implement with tests, review each task and inspect the finished branch. This guide follows the official Superpowers 7.0.0 manuals checked on 20 October 2026. BIG CHANGE reviewed the documentation; we did not install the plugin or run a project through it.

The big change

  • What changed: An approved design and implementation plan give the coding agents a specific task and constraints before they edit the repository.
  • Why it matters: The documented task flow pairs observed failing and passing tests with one reviewer’s separate specification and quality verdicts, then a broader review of the whole branch.
  • What to watch: The owner still checks the complete diff and fresh acceptance results and decides what happens to the branch. A completed agent workflow can retain disclosed findings.

Before you start

Choose one authorized, multi-step code change in a repository you own or can edit. It should break into reviewable tasks and have behavior you can test. Write down the requested behavior, affected area, exclusions, original acceptance command and starting commit. Run that command and the relevant existing checks before work begins. If the baseline already fails, identify that failure now; a later green or red result needs a known starting point.

You need Git, an authenticated Claude Code installation, permission to install plugins and create a branch or worktree, and enough plan or API capacity for Claude Code and its subagents. Check your organization’s rules for source-code access and plugin use. Review the plugin’s contents, effective permissions, provider data terms and spending controls before enabling it. Anthropic warns that plugin hooks and server processes can execute with your user privileges outside the tool-call sandbox; ordinary tool permission prompts do not cover all such code. Keep secrets, dependencies, external writes, pushes and releases within the authority you actually have. Claude Code’s plugin security documentation explains this boundary.

The path below uses Superpowers’ subagent-driven-development skill for a change with multiple tasks. The manuals also describe an inline executing-plans path and permit simpler design agreements for small work. Choose the path with the owner before implementation rather than assuming every project must use the full sequence.

1. Install the plugin and verify the active version

In an interactive Claude Code session, enter the official marketplace command:

Text
/plugin install superpowers@claude-plugins-official

Claude Code opens a plugin details panel before installation. Inspect the contents and choose a permitted scope. Local scope enables it for you in this repository; project scope affects collaborators’ repository settings. Read the install summary and Errors tab. Follow the session’s activation instructions or restart, then check the Installed tab and run claude plugin list in a shell. Record the displayed Version, Scope and Status, and confirm the Superpowers skills are available in the active session. The marketplace command does not pin the research commit used for this guide. If the installed version or skill text differs from 7.0.0, reconcile the procedure with that installed version before proceeding. A failed or disabled installation is a stop, not evidence that the workflow loaded. Claude Code’s install guide documents these checks.

2. Approve the design, then the plan

Tell Claude Code the real change, acceptance criteria, baseline result and forbidden edits. Use Superpowers’ brainstorming process to settle intent, design choices and constraints. For this multi-step change, inspect the written design and the builder-check findings, resolve questions that belong to the owner, and approve the full description. Approval should describe the behavior to build; it should not be inferred from the agent continuing to talk. The design manual allows smaller work to use a lighter agreement or an explicit opt-out, so this is a deliberate choice for a substantial task.

Next, ask the writing-plans process to turn that design into tasks. Review the plan’s file boundaries, interfaces, global constraints, test commands and Review Focus. Each task should be small enough to inspect, and its test should measure the agreed behavior. Approve the plan and the subagent execution approach before code changes begin. The planning manual defines the handoff. Avoid treating a plausible plan as permission to add dependencies or change unrelated files.

At execution, using-git-worktrees checks for a suitable existing workspace or prepares an isolated one with the required consent. Record its actual branch, base commit and clean baseline. Use Claude Code’s native worktree support where available. If the workspace contains unrelated edits, resolve ownership before proceeding. The worktree manual describes the check and creation path.

3. Watch each test and task review

With the approved plan, use subagent-driven-development for independently reviewable tasks. The current manual assigns an implementer to a task, then passes the implementation and its diff to one task reviewer. That reviewer returns two judgments: whether the task matches the specification, and whether its implementation quality is acceptable. These are two verdicts from one review, not two sequential reviewer agents. Small tasks of the same shape may be batched under the manual’s rules. The task workflow and reviewer prompt establish this sequence.

For each behavior suitable for test-first work, require an observable red-green cycle: add the behavioral test, run it and see the expected failure; make the smallest implementation, rerun it and see it pass; then refactor while checks remain green. An import error or broken test harness is not the expected red result. Keep the command, output and relevant commit or diff for each task. The test-driven-development manual describes exceptions that require human agreement; this guide assumes a task suited to its normal test-first path.

Read both reviewer verdicts and the actual diff. Resolve any “cannot verify from diff” item against the plan and repository before accepting the task. Inspect repairs and their scoped re-review; do not treat a new assertion of success as a fresh test result. The 7.0.0 workflow caps its repair loop and can park findings with written rulings. Preserve those findings for the later review. A task marked complete does not necessarily have a clean review.

Once the tasks are done, inspect the separate whole-branch review. It can identify interactions between tasks and revisit deferred findings that a task reviewer could not settle from one diff. Ask for the evidence and ruling behind any open issue. Retain the design, plan, test outputs, review reports and full diff before plugin scratch-workspace cleanup. If an expected skill did not trigger, check the active plugin status and version and the documented diagnosing path; do not assume the flow was enforced just because the plugin was installed.

4. Check the branch and choose its disposition

Run the original acceptance command again on the final code, along with the project’s full test suite. Inspect fresh outputs, the complete branch diff and all outstanding findings. Superpowers’ verification manual requires evidence from the current state before a completion claim. If the suite fails, identify the exact failure and repair or leave the branch for review; the documented branch-finish menu is not reached on a failing suite.

On a named branch, finishing-a-development-branch presents local merge, push and create a pull request, or keep the branch as-is. A detached HEAD has the pull-request and keep choices. Discard is handled only after an explicit owner request and typed confirmation; it is not a routine fourth option. The branch-finishing manual sets out those choices. Show the owner the checks, diff and residual findings before they decide. A merge, push, deletion or release needs the authority appropriate to that action.

The useful output is a reviewable branch tied to the original requirement: an approved design and plan, observed test results, both task-review verdicts, a whole-branch review, a full diff and a fresh acceptance result. If installation, access, budget or a check stops the run, keep the verified artifacts and state the last completed stage. The documentation describes a process; it does not establish that this guide’s unrun change took less time, cost less or contained fewer defects.

Sources & further reading

For a narrower accepted-check repair, see BIG CHANGE’s guide to verifying one failing repository check. The process here begins earlier, with the design and plan for a multi-task change.