Why I did not give my coding agent Superpowers

I recently considered installing Superpowers, a development workflow for coding agents. It promises a reassuring sequence: clarify the design, write a plan, use test-driven development, debug systematically, review the result, and verify everything before declaring victory.

This is sensible. Suspiciously sensible, in fact. It described almost exactly what I wanted from OpenCode, including several things I had already spent time building for myself. Installing it looked like the obvious next step.

So naturally, instead of installing it, I conducted an unnecessarily thorough inspection of my own configuration, the plugin documentation, and the overlap between the two (this is how I relax).

I eventually decided not to install it. Not because Superpowers is bad, and not because reusable workflows are a mistake. I declined because its strongest opinions overlapped with mine while its operating model did not. I already had the process I needed, and I preferred to keep control over when that process activates, which model performs each part, and what every agent is physically allowed to change.

So far, nothing to object to

Superpowers presents a complete software-development method as a collection of composable skills. Its documented flow covers brainstorming, implementation planning, Git worktrees, TDD, systematic debugging, subagent-driven execution, code review, and branch completion.

There is a lot to like there. “Evidence over claims” is an excellent rule for a coding agent. So is refusing to fix a bug before establishing its root cause. Writing a failing test before implementation is certainly less exciting than asking an agent to generate half a project in a morning, but it also means fewer afternoons spent negotiating with a test suite that has developed constitutional objections.

The project is open source, well documented, and available for multiple coding harnesses. For someone starting with a mostly default agent, it offers a coherent process without first having to become the unpaid operations manager of a small synthetic engineering department.

My problem was duplication.

My OpenCode configuration already had separate workflows for defining a spec, planning it, and implementing it with a red-green TDD loop. It had systematic debugging, sequential spec and quality reviews, architecture maps, ADRs, repository audits, and document workflows. The configuration lives in a public repository, partly because version control is useful and partly because even my prompts now require change management.

Installing another opinionated workflow would not fill an empty space. It would place a second set of road markings over roads I had already painted.

Automatic discipline is still automatic

The decisive detail was the bootstrap rule in Superpowers’ using-superpowers skill. It instructs the agent to invoke a relevant skill before any response or action, including clarifying questions, whenever there is even a one-percent chance that a skill applies. The wording is deliberately forceful: using an applicable skill is mandatory, not optional.

I understand the reasoning. A skill library is useless if the model casually ignores it, and models are very good at deciding that a formal workflow is unnecessary approximately three seconds before doing the thing that the workflow was designed to prevent. Strong instructions defend against that.

But they also make process selection automatic. A simple request can enter a workflow because a matching skill exists, not because I decided that the cost was justified. The framework calls that consistency. In my setup, I would experience some of it as ceremony.

I prefer explicit entry points. I use commands such as /define, /plan, /implement, /review, and /audit. They make the contract visible. When I invoke /review, I am validating changed work against acceptance criteria. When I invoke /audit, I am looking for pre-existing problems in a repository, even if the worktree is clean. That distinction emerged after I tried to use a diff-oriented review for a whole-project health check and the workflow, quite correctly and quite unhelpfully, refused.

Explicit invocation does create a risk: I can forget to use the right process. I accept that risk because the alternative is paying the process cost on tasks where it contributes little. My aim is not maximum ritual compliance. It is enough discipline at the point where failure becomes expensive.

A skill tells; an agent can be fenced in

There was another difference that mattered more than prompt style: permissions.

In OpenCode, a skill is a reusable set of instructions loaded into the current context. It explains how work should be done. An agent can additionally have its own model, context, tool access, and runtime-enforced permission boundaries.

That lets me separate advice from enforcement. My review agents are read-only. They can inspect a diff and report a finding, but they cannot quietly “help” by editing the code they are reviewing. A document worker may write only inside its designated evidence and deliverable directories. An implementation agent can edit application files, while a planning agent cannot wander into the source and begin implementing its own plan in a fit of premature enthusiasm.

The skill says, “do not edit.” The permission boundary says, “you cannot edit.” I sleep better with the second one.

This also keeps responsibilities legible. Interactive work such as defining a spec belongs to a primary agent that can ask me questions. Batch analysis such as a quality review belongs to a subagent with a fresh context and a narrow output contract. The distinction is not merely organizational. It changes what the runtime permits and how much conversational baggage reaches the task.

Token cost is architecture too

Workflow quality is not the only cost. Every instruction loaded into context competes with the code, specification, test output, and conversation the model actually needs.

A broad library has more opportunities to help, but it also creates more matching decisions and more process text. Automatic activation makes that cost easy to overlook because no invoice appears when another procedure enters the context. The bill arrives as latency, token usage, or an agent that remembers the workflow perfectly while becoming hazy about the file it was meant to change.

My smaller setup is not automatically efficient. I have produced spectacularly verbose agents too. At one point, an analysis repeated essentially the same progress update several times while checking adjacent files. The agent was not stuck. It was providing play-by-play coverage of an activity in which nothing new was happening, like a sports commentator assigned to a person looking through kitchen drawers.

I fixed that with a global rule: one kickoff update for a related exploration, then another only for materially new evidence, a blocker, a changed plan, or a decision. I also route exploration, titles, and summaries to a smaller model, while reserving stronger models for work that benefits from them. These are modest savings, but they are attached to actual behavior I observed rather than to a general hope that more automation will somehow use less automation.

What I kept from the comparison

Rejecting the installation did not mean rejecting the ideas. The comparison was useful precisely because it exposed gaps in my own setup.

I kept the emphasis on deterministic reproduction before debugging, fresh review contexts, spec compliance before quality review, and verification evidence before success claims. I also added bounded review loops after learning that an agent can rediscover one adjacent edge case per iteration with the steady efficiency of someone feeding coins into a parking meter that, after every coin, calmly asks for one more.

The result is not a universal alternative to Superpowers. It is a configuration for my work: part developer workflow, part architecture toolkit, part document pipeline. It includes commands that would be irrelevant to many developers and omits conveniences they would reasonably consider essential.

That is the point. A framework is most valuable when its defaults are close to the desired operating model. If I were starting from scratch, wanted an end-to-end methodology immediately, and preferred automatic enforcement of its skills, I would seriously consider Superpowers. With a mature custom setup, however, adopting it would mean reconciling two systems that agree on principles but compete over control.

I chose the smaller system I could inspect, fence, and change. Then I spent far more time documenting that decision than installing the plugin would have taken, which suggests that the configuration is working exactly as intended.

The whole setup, agents and skills and the increasingly ceremonial collection of guardrails, lives at github.com/Light2288/opencode-personal-skills-agents if you want to inspect it or calculate how many workflows it takes to avoid installing one plugin.