Superpowers 6.0: Not a Speed Tweak—158 Commits Turn the Reviewer into a Read‑Only Adjudicator

1. Review‑stage rewrite in Superpowers 6.0

Release notes describe 6.0 as “a rewrite of how subagent‑driven‑development reviews each task — cheaper, stricter, and harder to game”. The three adjectives form a progression. Inspection of skills/subagent-driven-development/ shows the reviewer transformed from a mutable, coachable component into a read‑only, skeptical adjudicator.

Three technical levers close three cost holes: merging two reviewers into one, replacing pasted diff with file‑based context, and requiring explicit model declaration for each dispatch.

2. Merging two reviewers into one

In the 5.x version each task ran two independent reviewers—one for spec compliance, one for code quality—each reading the git diff separately. 6.0 consolidates them into a single task-reviewer using the merged prompt task-reviewer-prompt.md, whose first lines state:

The reviewer reads the task's diff once and returns two verdicts: spec compliance and code quality.

This eliminates one diff read and one subagent, saving tokens and wall‑clock time.

Directory layout before and after:

skills/subagent-driven-development/
├── SKILL.md                (418 lines, main flow)
├── implementer-prompt.md   (139 lines, implementer template)
├── task-reviewer-prompt.md (188 lines, merged reviewer template)
└── scripts/
    ├── task-brief          (40 lines, extracts a task brief)
    ├── review-package      (44 lines, packages diff info)
    └── sdd-workspace       (22 lines, parses workspace path)

In 5.x the separate prompt files spec-reviewer-prompt.md and code-quality-reviewer-prompt.md have been removed and their logic rewritten.

3. Reviewer becomes a read‑only skeptic

The merged prompt contains a section titled “Do Not Trust the Report” (lines 55‑62). It instructs the reviewer to treat the implementer’s report as an unverified claim that must be validated against the diff, preventing a cheating path where an implementer claims “I deliberately kept it simple”.

Read‑only enforcement (lines 52‑53) adds:

Your review is read‑only on this checkout. Do not mutate the working tree, the index, HEAD, or branch state in any way.

Previously a reviewer that performed git checkout could create orphan commits. The controller is also barred from influencing the reviewer via the SKILL.md red‑flag lines (169‑173), preventing pre‑rating of severity.

4. Files replace pasted context: the economics of context

In 5.x the controller pasted the entire diff into the dispatch prompt, causing every line of diff to remain in the session context for the rest of the run. The comment in SKILL.md (lines 220‑223) warns that everything pasted stays resident and is re‑read on every later turn, inflating token usage.

6.0 introduces three helper scripts: task-brief (≈40 lines) extracts the full text of a numbered task from the plan file and writes it to .superpowers/sdd/task‑N‑brief.md. review-package (≈44 lines) runs git log --oneline, git diff --stat, and git diff -U10, then writes the combined output to a .diff file named by commit range. sdd-workspace (≈22 lines) parses the workspace path and writes a self‑ignoring .gitignore file.

Subagents now read the diff from the generated file instead of receiving a pasted prompt, reducing token and wall‑clock cost by roughly 10 % (official claim) and treating context as a consumable resource.

5. Progress ledger guards against compaction forgetting

Long sessions suffer from context compaction, which erases the controller’s memory of completed tasks, causing it to re‑dispatch the entire task sequence. The source adds a git‑ignored progress.md ledger where each completed task appends a line like:

Task N: complete (commits base7..head7, review clean)

After compaction the controller reads this ledger and runs git log to reconstruct progress, trusting the ledger over its own recollection.

6. Model discipline: explicit declaration

In 5.x the controller inherited the session’s default model for every subagent, often the most expensive top‑tier model, even for simple review tasks. 6.0 forces each prompt to declare a model explicitly:

model: [MODEL — REQUIRED: choose per SKILL.md Model Selection;
an omitted model silently inherits the session's most expensive one]

The accompanying note explains that turn count outweighs token price; cheaper models may take 2‑3× more turns on multi‑step work, making them more expensive overall. Thus 6.0 recommends matching model tier to task complexity rather than always using the cheapest model.

7. Open questions and unverified claims

Performance numbers (≈2× speed, ≈50 % token reduction) are based on evaluations using Claude Code and Codex; other harnesses such as OpenCode, Cursor, Gemini CLI were not measured. The disclaimer “these numbers won't hold on every harness and for every workload” remains important.

Version 6.0.3 fixed a runtime constraint where the .git/ directory was protected, moving all artifacts to a self‑ignoring .superpowers/sdd/ directory.

External articles claim dramatic speedups (e.g., 41× for chardet) but lack independent verification.

8. Skills de‑dialectisation

All skill files now use a vendor‑neutral action language instead of Claude‑specific commands. The new principle (line 44 of using-superpowers/SKILL.md) states: “skills speak in actions (dispatch a subagent, create a todo, read a file) rather than naming any one runtime's tools.” Mapping files under skills/using-superpowers/references/ translate these actions to concrete tools for 11 supported harnesses.

Conclusion

Superpowers 6.0 hardens the reviewer by merging two reviewers into a single read‑only adjudicator, forbidding controller influence, isolating context via files, enforcing explicit model selection, and persisting state in a progress ledger. The result is faster, cheaper execution achieved through stricter engineering discipline rather than algorithmic optimization.