# Superpowers with Spire

Superpowers (obra/superpowers) is not part of Spire's cycle. This page is for when you use it anyway: an older model that needs more rails (Opus 4.6 and earlier), or a brief or user that asks for one of its skills.

Dated observations, 2026-10-15, upstream v7.0.0. Sources: the workpad research of that date on superpowers alternatives, Spire coupling and plan anatomy.

## Why it is not the default

On Opus 5.5 its ceremony costs more than it catches: review and fix grew to about two thirds of the work, and scope grew past the plan. The causes are structural, not tuning:

- One fresh implementer plus a review per task (`subagent-driven-development`): 2 to 12 dispatches per task, plus a fix loop of up to 5 rounds.
- Plans written for an implementer with "zero context and questionable taste": small steps, code in the plan. Every planned line becomes an obligation a reviewer enforces.
- Reviewer rules that widen scope: "a spec's silence is not permission", a YAGNI argument never downgrades a finding, and the plan's Review Focus adds tests by design.
- The SessionStart hook ("if there is even a 1% chance a skill applies, you must invoke it") turns optional skills into automatic ones in every main session.

## What the lean cycle overrides

| Superpowers | Spire |
|---|---|
| Review after every task, re-review after every fix | One fresh review per phase, one fix pass, re-check only Critical/Important |
| Plan with bite-sized steps and full code | Plan at the altitude of decisions, contracts, invariants, scope fence |
| Execution handoff: the user picks subagent-driven or inline | The attack reshapes the plan into a build plan; the user sees it once |
| Brainstorming HARD-GATE: user approves spec, plan and execution method | Brainstorm is optional; decisions belong before the run |
| Reviewer treats anything the spec did not mention as a finding | Unplanned work is recorded, never reverted automatically |
| TDD iron law for every change | Fail-first test for bugs you do not yet understand; tests once per phase |
| Files under `docs/superpowers/` | The workpad decides placement |

## Still useful as tools

- `systematic-debugging` for a stubborn failure.
- `test-driven-development` for a fail-first test inside a block.
- `verification-before-completion`: evidence before claiming a gate or test passed.
- On older models, `writing-plans` for the planner, then the attack as usual. Upstream v6.4.2 already dropped full code and 2–5-minute steps from plans; prefer a current version.
- If you do run superpowers' own execution, upstream's Native mode (v6.4.1: one final review) is the cheaper path, not `subagent-driven-development`.

Forks that keep the per-task loop as the default (e.g. pcvelz `superpowers-extended-cc`) add ceremony rather than remove it.