Superpowers is not a smarter model. It is a gate your coding agent cannot talk its way around.
Left to default behavior, my coding agent skips the spec, skips the plan, and starts generating the moment I finish the prompt. That is not a personality flaw. Language models are trained to be immediately helpful. Helpful, in practice, means code on the screen before anyone agreed what we are building. Superpowers is an open-source skills framework for coding agents, built by Jesse Vincent and the team at Prime Radiant. It does not replace Claude, Codex, or Cursor. It sits on top of them and routes the session through the same gates a senior engineer uses before touching the tree: ask, design, isolate, plan, then write code under tests. I care about this because I maintain agent-skills : installable engineering skills for Cursor, Codex, Copilot, Claude Code, and OpenCode. The lesson is the same on both sides. If the process lives only in my head, the agent will not follow it. If it lives in a SKILL.md the agent is required to read, the process actually runs. The failure mode is not intelligence You ask for a feature. The agent picks a library you did not want, creates files in the wrong package, and misses two requirements because it never asked what you actually needed. By the time you notice, you are debugging output you did not specify. The root cause is default behavior. Models optimize for producing an answer fast. What gets skipped is the cheap work: clarifying questions, a short design, a written plan with verification. Superpowers intercepts that instinct at session start and sends it through structured gates instead. What Superpowers actually is A skill is a SKILL.md file: when to activate, what steps to follow, what to verify. The agent reads it and follows it. No custom weights. No private inference stack. The master skill, using-superpowers , is injected at the start of the session. The text is blunt on purpose. If a skill applies, the agent must use it. It cannot talk itself out. It checks for skills before any response, including before answering clarifying questions. Skills trigger from context, not from a slash command you remember to type. "Help me build X" should wake brainstorming. An approved design should wake an isolated git worktree. Platforms that support subagents then execute the plan with a fresh agent per task. User files still win. CLAUDE.md , AGENTS.md , and GEMINI.md take precedence over skills. If your project says do not use TDD, the TDD skill defers. Skills override default model behavior. They do not override your explicit project instructions. That split matters. Superpowers is a behavior layer. When a better model ships, the methodology still applies. The workflow: brainstorm, isolate, plan, execute Four phases, in order. Brainstorm. Before any code, the agent works the design with you in chunks you can actually read. It surfaces edge cases and alternatives. It produces a written design only after you sign off. This is the expensive-failure gate: do not start building the wrong thing. Isolated workspace. Once the design is approved, a git worktree skill creates a branch in an isolated directory. Main stays untouched. Project setup runs. Tests should be green before the first feature line. Plan. The writing-plans skill produces micro-tasks written as if the executor has poor taste, no project context, and an aversion to testing. Each task is a few minutes of work, with exact file paths, expected code, and a verification step. The over-specification is the point. Ambiguities get resolved in text, while they are still cheap. Execute with TDD. On Claude Code and Codex, each task can go to a fresh subagent so context does not drift. Red, then green, then refactor. Two review passes: spec compliance, then code quality. On Cursor and similar tools without native subagents, execution is sequential through an executing-plans skill. This is not a new tool. It is a methodology you can remove. Superpowers does not change how the underlying model reasons. You are adopting a development process encoded as structured prompts. If it stops serving the team, you uninstall the plugin. Nothing in your infrastructure has to move. It also slows you down on purpose. The brainstorm-to-plan pipeline can cost 10 to 20 minutes of dialogue before code starts. For a two-line fix, that is the wrong tax. For exploratory prototyping with no committed direction, forced design fights the work. Vincent has been explicit: skills should stay out of the way when they do not apply. Use it when: the feature is large enough that a wrong first assumption is expensive to unwind you have watched agents drift from the original requirement mid-session you want TDD without reminding the agent on every task you are handing an agent a long autonomous stretch and you need the plan to hold Skip the full pipeline when the problem is already specified and small, or when you are deliberately trying things without a spec. How I map this to agent-skills Superpowers is the process layer: brainstorm, plan, TDD, review. My catalog is the domain layer: how to write Spring Boot 4 services, Java 26 style, React quality gates, RAG review, public API documentation. They compose. Superpowers decides when the agent is allowed to write. Domain skills decide what good looks like in a given stack. Project AGENTS.md still owns repo-specific rules. That is why I do not treat Superpowers as a replacement for a skills catalog, and I do not treat a catalog as a replacement for a session-level gate. One without the other is how you get a well-tested feature in the wrong package, or a nicely designed feature with no tests. Takeaways Default helpfulness is the bug. Intelligence is not the missing piece. Encode process as skills the agent must read, not as reminders you hope it remembers. Keep project files ( AGENTS.md ) above skills. Skills above default model behavior. Pay the planning cost on work where unstructured agents would create expensive rework. Do not pay it on a one-line fix. Pair a process framework with domain skills. Procedure without stack judgment still ships the wrong shape of code. If you already use coding agents in a real codebase, I am curious: where does yours skip first, the spec, the plan, or the tests?