Superpowers 6: What Actually Changed, and Why Your Agent Got Harder to Fool

The short answer

If you already write code with Claude Code, OpenCode, or Codex, you have probably heard of Superpowers. It is not another “magic prompt.” It is a skill framework that makes your agent work by process — turning the habits of a good engineer (“think before you act”, “write the test before the code”, “collect evidence before fixing the bug”) into operating procedures the agent must follow.

From v6.0.0 to the latest v6.1.1, Superpowers shipped a dense run of upgrades: Subagent-Driven Development (SDD) lost half its reviewers but got stricter; plans gained a Global Constraints block and per-task Interfaces; the brainstorming companion got a one-time key; Codex can install from the marketplace; and Gemini CLI was dropped after Google EOLed it.

This article unpacks the wave, what you actually get, and why it makes your agent’s output steadier.

Figure 1: Superpowers 6 from v6.0.0 to v6.1.1 at a glance — fewer tokens, stricter process, broader harness support.

1. First, what problem does Superpowers actually solve

A common illusion when you start with agents: if the model is strong enough and the prompt is long enough, the agent will just do the job well. After a while you notice agents are excellent at pretending to be done — “should be fine” without running tests, “fixed” without reading logs, or diving into code before the design is settled.

Superpowers’ idea is simple: instead of betting on the model’s self-discipline, write the process into skills and make the agent stop and check at every node.

An analogy: hand an intern a broken car with no procedure and they start unscrewing things, only to find they removed the wrong part. Superpowers is the repair manual — step 1 observe, step 2 read fault codes, step 3 locate the cause, step 4 replace the part, step 5 test. Veterans run on experience; interns run on the manual. Agents are the same — the weaker the model, the more it needs the manual.

Figure 2: Top of the official Superpowers repo README (real screenshot). It positions itself as “a complete software development methodology for your coding agents” — not a prompt trick.

Figure 3: Without external process, an agent loops between “guess → edit blindly → claim done → reality bites”. Superpowers inserts a checkpoint at every node and breaks the loop.

The skills fall into roughly five buckets:

2. v6.0: SDD goes from two reviewers to one, and gets stricter

v6.0.0 is the biggest release in this wave. The headline change is in Subagent-Driven Development (SDD).

2.1 Why two reviewers before

Early SDD dispatched two subagents to review each task: spec-reviewer (does the task match the spec?) and code-quality-reviewer (is the code any good?). Sounds professional.

In practice, two problems:

1. Expensive. Each review spawns a fresh agent session, doubling token cost.
2. Gameable. Models are great at bargaining — the controller would hint to the reviewer “this isn’t really severe”, and the reviewer would let it pass.

Like code review at a company where the reviewer and reviewee report to the same manager: a little face-saving and the review becomes theater.

2.2 Now: one reviewer, two verdicts, plan pre-flight

v6.0 merges the two into a single task-reviewer that reads the diff once and returns both a spec-compliance verdict and a quality verdict. One pass, cheaper.

More importantly, several anti-gaming measures:

• Diffs move as files, not pasted text. A pasted diff parks itself permanently in the most expensive context window. Two scripts, task-brief and review-package, write the task text and review diff to files the subagent reads, keeping the main context clean.
• The controller cannot tell the reviewer what to ignore. Real runs caught controllers coaching reviewers to skip a finding or call it “Minor at most”. Suppressing findings and pre-rating severity are now banned outright.
• The reviewer is read-only. A reviewer running git checkout had been orphaning later commits. Now reviewers can look, not touch.
• Plans get a pre-flight read. Before Task 1, the controller scans the plan for internal conflicts (Task A says add a field, Task B says don’t) and raises them all at once, instead of stumbling into them mid-run.
• Every dispatch states its model. Left to choose, controllers stopped naming a model, silently inheriting the session’s most expensive tier — one run put all 26 reviewers on the top model. Templates now require it.

Figure 4: After v6, per-task review goes from “two reviewers guarding separately” to “one reviewer returning two verdicts”, with plan pre-flight and file-level diff delivery. Tighter, and harder to bypass.

2.3 The result: same quality, ~50% fewer tokens

The official eval: Claude Code and Codex produce similar-quality results about twice as fast, spending close to 50% fewer tokens.

This is not “cheaper because we hired one fewer reviewer” arithmetic. The real saving is killing the bargain loop between controller and reviewer. Before, the reviewer would flag a problem, the controller would say “I think it’s fine”, and the reviewer would cave. Now severity is the reviewer’s independent call — no negotiation.

Analogy: before, “QA flags a defect, the floor manager says let it through, QA concedes”; now, “QA independently marks it fail and sends it back, the floor manager cannot overrule”. No extra steps, but the loophole is closed.

3. v6.0: Plans grow a skeleton

The other big change is in writing-plans.

3.1 Global Constraints

Plans used to be free-form; constraints lived between the lines. Now every plan has a Global Constraints block copied in verbatim — version floors, dependency limits, naming, copy, exact values.

Back to the repair analogy: “be careful” means different things to different mechanics; “wear insulated gloves, hang a warning tag, disconnect power for 5 minutes before operating” needs no interpretation.

3.2 Interfaces

Every task now declares what it consumes and what it produces. If Task 3 needs the API response schema from Task 2, that contract is named in the Interfaces block.

So even a subagent that only sees its own task knows what its neighbors hand it and what it hands back. Like a production line: the output of station N is the input of station N+1.

Figure 5: Plan structure after v6. Global constraints span every task, interfaces pin the seams, and each task is sized to earn its own test cycle. In testing, a plan written this way passed in one round; the control needed 2–4 and shipped a real bug.

4. v6.0: The brainstorming companion gets a one-time key

The brainstorming skill has a Visual Companion — a small web page the agent opens alongside the conversation so you can see the plan in your browser.

This page used to have no authentication at all. If the port was reachable, anyone with the URL could read your brainstorm, or inject events the agent would treat as your input.

v6.0 gives it a real security model:

1. A per-session one-time key, embedded in the URL, stored as a tab-scoped cookie, required on every request and WebSocket connection.
2. The file server is sandboxed: refuses symlinks, .. traversal, and dotfiles.
3. The companion is offered only when a picture beats text, and a “no” stands.
4. Reconnects on its own — agent runs, you watch; if the page drops, it reconnects.
5. Idle timeout raised from 30 minutes to 4 hours.

Analogy: the old companion was a whiteboard on the sidewalk — anyone could read or wipe a marker. The new one is a meeting room with a one-time keycard — you hand out a card for this session, you swipe to enter, strangers stay out.

5. v6.0: One skill set, every harness

Superpowers used to speak “Claude” — “use the Task tool”, “put it in CLAUDE.md”. v6 rewrites that vocabulary in terms of actions (“dispatch a subagent”, “your instructions file”) and keeps a per-harness “action → tool” mapping.

Figure 6: After v6, the same skill set runs on 9+ coding agents via per-harness tool mapping. Switching agents is like switching phones — the contacts are the same, only the sync differs.

Supported harnesses (partial list):

Codex can now install from the marketplace

v6.1.0 added Codex marketplace support — search superpowers in /plugins and install. Previously you had to clone and symlink, a much higher bar.

Gemini CLI removed

Google EOLed Gemini CLI on 2026-06-18 and closed the extension channel. Superpowers dropped Gemini support — keeping it would be dead weight.

6. The five anti-gaming details are the hard core of v6

Lay the SDD changes flat and you see five independent, mutually reinforcing anti-gaming measures. Each looks small alone; together they are the real reason for “same quality, half the tokens”.

Figure 7: The five measures added in v6. Real runs caught a controller coaching a reviewer to skip a finding — the flaw shipped. So “suppressing findings” and “pre-rating severity” are now banned outright.

A single analogy for all five: you hand an intern an assignment to fix. Before, “he says he’s done and submits”. Now, “he must paste every changed line separately (diff as file), he cannot pre-buddy up to QA (controller muted), QA can look but cannot touch his work (read-only reviewer), the task list is checked for self-contradiction before anyone starts (plan pre-flight), and every assignment names who it goes to (model stated)”. None of them is decorative.

7. v6.1: Leaner bootstrap, stricter packaging

v6.1.0 and v6.1.1 are mostly “fixing ourselves” work.

7.1 Bootstrap slimmed

using-superpowers is injected into every session, so its size is paid constantly. v6.1.0:

• Dropped the graphviz skill-flow diagram (replaced with prose)
• Folded Instruction-Priority into User Instructions
• Removed per-platform “How to Access Skills” walkthroughs
• Trimmed per-harness tool-mapping files (deleted guidance modern agents already follow)

Same behavior, lower per-session cover charge.

7.2 v6.1.1: the Codex hook trap

v6.1.0 wanted to remove Codex’s SessionStart hook — Codex triggers skills natively, and the bootstrap hook made UX worse. So the hook config was deleted.

It got worse: with the hooks field absent, Codex fell back to auto-discovery, found the Claude Code hook at the repo root, re-registered it, and added a one-time trust prompt.

The fix is almost philosophical: declare an exact empty hooks object, hooks: {}. Codex reads that as “no hooks”. Missing field, [], or an inline empty list all fall back to auto-discovery.

You would never find this bug without hitting it once — “empty” and “absent” are not the same thing in the API spec. Analogy: telling the courier “I have no package to send today” does not register; you must hand them a slip that reads “today’s shipments: none”, and only then do they skip the pickup. “Not said” and “explicitly said none” are different things in a program.

7.3 v6.1.1: packaging script

v6.1.1 also added package-codex-plugin.sh for maintainers building the Codex portal package — .zip or tar.gz, normalized timestamps, preserved executable modes, verifies every skill carries OpenAI metadata, refuses a dirty worktree.

8. Six releases in ~16 days

From v6.0.0 to v6.1.1, six tags in about 16 days. On a timeline you can see the classic open-source rhythm: “big rewrite → fix installs → fix installs → fix paths → another big one → polish”.

Figure 8: Superpowers 6 release cadence. v6.0.0 rewrote SDD, plans, the companion, and cross-platform wording in one go; three patches fixed installs and a protected path; v6.1.0 slimmed bootstrap and wired Codex marketplace; v6.1.1 closed the empty-hooks trap.

9. How to install and verify

Different agents have different install entries, but the goal is the same: make the agent read using-superpowers at session start and load the matching SKILL.md when a task triggers.

9.1 Manual install (general)

Go to the Superpowers GitHub repo README and find your platform:

• Claude Code: /plugin marketplace add obra/superpowers-marketplace, then /plugin install superpowers@superpowers-marketplace
• Codex: /plugins → search superpowers → install
• OpenCode: add "plugin": ["superpowers@git+https://github.com/obra/superpowers.git"] to opencode.json
• Cursor: /add-plugin superpowers

9.2 One-shot automated scripts (run by a human)

Three platform scripts, only system tools (git, curl, bash/zsh/PowerShell), no third-party services, only the official repo. Each clones the repo, prints the version, and shows the install command for your agent.

Ubuntu 26.04 / Linux (bash):

#!/usr/bin/env bash
set -euo pipefail
DEST="${SUPERPOWERS_HOME:-$HOME/.local/share/superpowers}"
echo "==> Clone Superpowers repo to $DEST"
mkdir -p "$(dirname "$DEST")"
if [[ -d "$DEST/.git" ]]; then
  git -C "$DEST" pull --ff-only
else
  git clone --depth 1 https://github.com/obra/superpowers.git "$DEST"
fi
VER="$(git -C "$DEST" describe --tags --always 2>/dev/null || echo unknown)"
echo "==> Version: $VER"
echo "==> Repo ready. Pick your agent's install command:"
echo "    Claude Code : /plugin marketplace add obra/superpowers-marketplace"
echo "                  /plugin install superpowers@superpowers-marketplace"
echo "    Codex       : /plugins -> search superpowers -> install"
echo "    OpenCode    : add \"plugin\":[\"superpowers@git+https://github.com/obra/superpowers.git\"] to opencode.json"
echo "==> Verify: ask your agent 'what Superpowers skills do you have?'"

macOS 26 (zsh):

#!/usr/bin/env zsh
set -euo pipefail
DEST="${SUPERPOWERS_HOME:-$HOME/Library/Application Support/superpowers}"
echo "==> Clone Superpowers repo to $DEST"
mkdir -p "${DEST:h}"
if [[ -d "$DEST/.git" ]]; then
  git -C "$DEST" pull --ff-only
else
  git clone --depth 1 https://github.com/obra/superpowers.git "$DEST"
fi
VER="$(git -C "$DEST" describe --tags --always 2>/dev/null || echo unknown)"
echo "==> Version: $VER"
echo "==> Repo ready. Claude Code / Codex / OpenCode commands are the same as the Ubuntu version."
echo "==> Verify: ask your agent 'what Superpowers skills do you have?'"

Windows 11 (PowerShell, no WSL needed):

$ErrorActionPreference = "Stop"
$Dest = if ($env:SUPERPOWERS_HOME) { $env:SUPERPOWERS_HOME } else { "$env:USERPROFILE\superpowers" }
Write-Host "==> Clone Superpowers repo to $Dest"
if (Test-Path "$Dest\.git") {
  git -C $Dest pull --ff-only
} else {
  New-Item -ItemType Directory -Force -Path (Split-Path $Dest) | Out-Null
  git clone --depth 1 https://github.com/obra/superpowers.git $Dest
}
$Ver = (git -C $Dest describe --tags --always 2>$null)
if (-not $Ver) { $Ver = "unknown" }
Write-Host "==> Version: $Ver"
Write-Host "==> Repo ready. Claude Code / Codex / OpenCode commands are the same as above."
Write-Host "==> Verify: ask your agent 'what Superpowers skills do you have?'"

9.3 Agent-driven install

Send this to your agent:

Please install Superpowers into the agent I'm using right now.
Steps:
1) Identify the current agent type (Claude Code / Codex / OpenCode / Cursor / other);
2) Install superpowers using the official command for this platform;
3) After install, list the loaded Superpowers skills;
4) Run a minimal verification: have it handle a small bug I give you using the
   systematic-debugging approach, and confirm it collects evidence before
   editing code instead of editing first.

9.4 Verify it actually works

Installed ≠ actually working. Five checks:

1. Ask “what Superpowers skills do you have?” — it should list at least using-superpowers, brainstorming, systematic-debugging, verification-before-completion.
2. Give it a small feature request and watch whether it clarifies the goal or proposes a plan first rather than editing files.
3. Give it a real bug and watch whether it collects evidence first rather than editing config.
4. Make it run real verification commands before declaring done — not “should be fine”.
5. In multi-agent setups, different agents should each be able to state their boundaries and checkpoints.

Figure 9: The skills/ directory of the Superpowers repo (real screenshot). Each subdirectory is a skill, with a SKILL.md describing when it triggers and what process it enforces.

10. Frequently asked questions

Q: Will Superpowers slow my agent down? A: Bootstrap injection is once per session; skill loading is on demand. v6.1.0 also compressed the bootstrap. The thing that truly slows the pace is skill checkpoints — and those are the moments you want it slower (for example, brainstorming before writing code).

Q: Which skill should I start with? A: Just three: systematic-debugging (evidence before hypothesis), verification-before-completion (real verification before done), and writing-plans (break big tasks into small steps).

Q: My model is weak. Does it still help? A: The weaker, the more it helps. Superpowers externalizes the parts a model is most likely to drift on. Stronger models fill in process on their own; weaker models need external rails.

Q: Does Superpowers mean I will never get a wrong answer? A: No. It only guarantees the process is followed, not that the plan is optimal, the tests cover 100%, or the business trade-off is right. Code review, log auditing, permission boundaries — you still do those yourself.

Q: SDD now uses a single reviewer. Won’t that miss things? A: The team worried about that too. So they simultaneously added: file-level diff delivery (no information loss), reviewer read-only (no orphaned commits), controller banned from hinting severity, plan pre-flight to surface conflicts, and a whole-branch final review at the end. From the eval, same quality is reached faster and cheaper, not “more loosely”.

Q: Why are “empty hooks” and “no hooks field” different things? A: This is the real trap v6.1.1 hit. In Codex’s manifest, a missing field triggers auto-discovery fallback; only an explicit hooks: {} is read as “definitely no hooks”. Many APIs work this way — “not said” and “explicitly said none” are not the same thing.

11. What actually got stronger this round

Looking back across v6.0 → v6.1.1, the changes worth remembering are really just these:

1. SDD got harder to bypass — one reviewer, two verdicts, diffs as files, controller cannot pre-set stance.
2. Plans got structure — Global Constraints and Interfaces turn “read between the lines” into “read the contract”.
3. The brainstorming companion got a one-time key — from naked to a real security model.
4. Cross-platform unified — same skills, per-platform tool mapping.
5. Bootstrap slimmed — cover price is lower.
6. Codex one-click install — the barrier to entry dropped.

Superpowers does not promise miracles. It only delivers executable engineering discipline: for stronger models, steadier output; for weaker models, earlier-exposed bugs; for multi-agent setups, a common language; for real projects, a “done” that rests on evidence rather than a polished summary sentence.

If you are already using OpenCode, Claude Code, Codex, or another coding agent, the cheapest experiment is: install Superpowers, pick a low-risk repo, run systematic-debugging and verification-before-completion a few times, and watch whether the agent actually “thinks before it touches”.

Happy debugging!

Sources and further reading

• Superpowers GitHub repo: https://github.com/obra/superpowers
• Superpowers official release notes: https://github.com/obra/superpowers/blob/main/RELEASE-NOTES.md
• Superpowers Codex install doc: https://github.com/obra/superpowers/blob/main/.codex/INSTALL.md
• Superpowers OpenCode install doc: https://github.com/obra/superpowers/blob/main/.opencode/INSTALL.md