Add a Slim version

[smortezah]

Superpowers is fantastic but it uses a lot of tokens and takes a long time to complete a task. A Slim version would be great as it would alleviate some of the constraints of superpowers to make completing tasks faster.

[sheengoa]

Yes, this is exactly what I'm thinking. For the current top models, such a cumbersome process is not necessary. They are already very intelligent.

[solerwell]

I strongly agree with this idea. The project should adapt to the future by using more proactive and powerful top-tier llm models, and develop a thinner auxiliary programming skill

[RomainGehrig]

Agreed. I'm aware that the current superpowers workflow is optimized toward results, but I'd like to see a lighter version to use with more intelligent/autonomous models and when speed is more important than perfection (eg. prototyping).

Right now, a modest feature takes an hour to be implemented. It's well tested and handles a lot of edge cases, but it was the wrong way of building it (right specs, painful UX/UI). This would have been caught with less waste of time, token, and attention if the process was lighter. Superpowers v5 felt faster in that regard.

[sjh9714]

A data point for the slim discussion. I benchmarked systematic-debugging last week as a comparison arm against a much shorter skill of my own, so these numbers cut both ways.

Setup: 4 bugfix tasks where the obvious fix is the wrong one, claude-opus-4-8, K=5 per arm (20 runs each), isolated git workspaces, graded by hold-out acceptance tests the agent never sees. v6.1.1 (d884ae0) vendored verbatim, rules-only injection (291-line CLAUDE.md). Medians are medians of per-task medians.

arm	verified repro	accuracy	cost/run	test LOC
no instructions	2/20	20/20	$0.176	1.5
style-only placebo	0/20	20/20	$0.192	1.5
systematic-debugging (291 lines)	8/20	20/20	$0.316	14.5
my repro-first (31 lines)	10/20	20/20	$0.241	11

"Verified repro" = the fix arrives with a test that provably fails on the pre-fix commit and passes after.

Two things that bear on slimming:

1. The Iron Law is doing real work. 8/20 vs 2/20 unaided — and a style-only placebo with no mechanism in it scored 0/20 (it is comparable in length, not identical — 156 words to repro-first's 235), so this isn't just "instructions are present." Whatever gets cut, that part is earning its tokens.
2. It cost +80% per run over no instructions, and on this one axis 31 lines got there at +37%. So a slim version doesn't look like an automatic downgrade — most of the effect on repro discipline survived a ~9x shorter ruleset.

Caveats, and they are large: 4 small self-contained tasks, K=5, and this measures exactly one of the things systematic-debugging does. Accuracy was saturated (every arm 20/20), so nothing here speaks to root-cause quality on a real codebase — which is where I'd expect the full process to earn the cost back. Untested axis, not a null result.

Raw logs and write-up: https://github.com/sjh9714/skill-receipts/blob/main/docs/audits/superpowers-debugging.md — if the setup is wrong I would genuinely like to know.

[obra]

6.0 cut token spend and runtime in half. We're continuing to iterate to make Superpowers faster and more efficient, but doing that without compromising quality takes real work.

If you think you have a "slim" version of Superpowers that doesn't compromise on quality, I'd love to see it. The right eval suite to run with (n=5 or so), is https://github.com/prime-radiant-inc/superpowers-evals I'd recommend starting with the go-fractals evals.

Right now, a modest feature takes an hour to be implemented. It's well tested and handles a lot of edge cases, but it was the wrong way of building it (right specs, painful UX/UI). This would have been caught with less waste of time, token, and attention if the process was lighter. Superpowers v5 felt faster in that regard.

It is important to read the spec and plan before kicking off an implementation. If the spec and plan are right and the build is wrong, please open a detailed bug report. We really want to hear about that. If the UX wasn't as specced, that's an issue.

It is also the case that the current frontier models are a lot slower and a lot more prone to over-building than the previous generation. 6.2, which shipped overnight, should be somewhat better on most harnesses. We're working on a biggish regression we're seeing in Codex for the next release, which should be soon.

[sjh9714]

Straight answer to the invitation: no, I don't have a slim Superpowers. What I have is a benchmark harness and one 31-line bugfix-discipline skill that matched systematic-debugging on a single axis. That is not a slim version of a 14-skill workflow framework and I'm not going to dress it up as one.

Two things that might still be worth something.

1. I re-measured the ruleset at v6.2.0, and it's a null. v6.2.0 trimmed systematic-debugging from 291 injected lines to 278, so I re-ran it on the same four tasks rather than assume a 4% edit is inert: cost/run median $0.316 → $0.291, verified repros 8/20 → 9/20, accuracy 20/20 in both. The −7.9% doesn't survive its own error bars — percentile bootstrap 95% CI [−12.4%, +1.7%], and the four tasks disagree in direction (one went up 5%). So, no detectable change, published as a null: write-up.

Explicitly, because it would be easy to misread: this says nothing about your "6.0 cut token spend and runtime in half." That's the framework — SDD, dispatch, plans, review stages — measured on your evals. Mine injects one SKILL.md as a CLAUDE.md against a no-instruction baseline on four small bugfix tasks. Different thing, different baseline; my null is not evidence against your claim.

2. A methodology note, offered rather than asserted. I read the pr1998 campaign design and the 2026-06-10 cost-experiment log first — "negative results get equal billing… nobody re-purchases a $50 disproof" is a norm I wish were more common. Your controls are paired dev-arm vs PR-arm, contemporaneous, with n raised where a scenario is known noisy. For "should this change merge," that is the right control and I have nothing to add to it.

The arm I couldn't find is a floor: the agent with no Superpowers at all, and beside it a placebo — an instruction of comparable length and shape with no mechanism in it. Those answer a different question than yours: not "did this change help" but "how much of a compliance score is mechanism versus the mere presence of confident, process-shaped prose." I raise it because that arm has flipped conclusions on my own tasks — a style-only placebo never reduced code on any of 12 tasks and increased it on 7, so an on-vs-off comparison would have overstated my own skill. A compliance grader seems more exposed to that than a LOC metric, not less, since prose can look like process.

I'm not suggesting you re-run 80 cells for it — your own log puts go-fractals near $12 and 45–90 minutes a run, so a floor arm isn't free. If it's interesting I'll sketch where it would sit cheapest. And if it already exists and I just missed it in the harness, I'd genuinely rather be told that.