Goodbye, Superpowers: I Removed the Always-on Ceremony, Not Skills
Superpowers is not obsolete. But treating heavyweight process as the default for every task is becoming a bottleneck. The better model is Selective Powers: choose process by risk.
I recently removed Superpowers from my default workflow. Not because it is bad—quite the opposite. It made a powerful point early in the AI coding era: agents are capable, but they are also impulsive. Without guardrails, they start before understanding the task and declare success before running anything.
Its answer is a full engineering loop: clarify, plan, isolate work, test, review, and verify. For an earlier generation of agents, that was an excellent safety rail. It helped move AI-assisted coding from “it can produce code” to “it can participate in delivery.”
What I no longer believe is that every task should pay the same process tax. Renaming a variable, adjusting an eight-pixel gap, or removing an unused import has a better path: locate the change, make the smallest edit, run the relevant check, inspect the diff, finish.
When such work has to pass through brainstorming, a spec, a plan, TDD, and a review, rigor becomes theatre. The process is not wrong; the fit is wrong. Ten seconds of change can become five minutes spent demonstrating that we are being careful.
The hidden cost is context. Every permanent instruction, plan template, and subagent briefing competes with the code, error message, and user request that matter now. More rules do not automatically produce more judgment. Sometimes they make the agent optimize for compliance instead of the actual problem.
That is why I am not saying goodbye to Superpowers. I am saying goodbye to the idea of an always-on, one-size-fits-all ceremony. Skills should be a toolbox, not an operating system.
My replacement is simple: low-risk, reversible work gets a direct change and verification. Clear but cross-module work gets a short plan. Security, payments, permissions, migrations, and architectural changes earn the full treatment—research, isolated work, tests, review, and explicit acceptance criteria.
I call this Selective Powers. Keep a small project contract always available: how to run the project, what must not change, and how to validate. Then load the heavy skill only when the task’s blast radius demands it. Stronger models do not mean we should run without process; they mean process itself must become selective.
— End —