Superpowers turns coding agents into a process layer
Superpowers shows how the coding-agent race is shifting from model quality alone to repeatable skills, TDD, reviews, worktrees, and verification.
- What happened:
obra/superpowersis back in the spotlight as a skill and methodology layer for coding agents.- As checked through the GitHub API on May 17, 2026, the repository had 194,953 stars, 17,332 forks, and a latest release of
v5.1.0.
- As checked through the GitHub API on May 17, 2026, the repository had 194,953 stars, 17,332 forks, and a latest release of
- Why it matters: The coding-agent race is moving from raw model capability toward repeatable engineering process.
- The project turns brainstorming, planning, worktrees, TDD, subagent review, and verification into mandatory workflows rather than loose prompt advice.
- Watch: As skill ecosystems grow, the issue becomes supply chain trust, quality control, and verification, not just better
prompts.
AI coding news usually starts with a new model, a new IDE, a new CLI, or a new benchmark. Claude Code can run longer tasks. Codex moves into mobile workflows. Cursor adds cloud agents. GitHub puts coding agents into pull requests. This story points at a different layer. It is not a new model or a new editor. It is a repository that packages the way coding agents should work.
The project is Jesse Vincent's open-source repository obra/superpowers. Its README describes it as a "complete software development methodology" for coding agents. The core idea is simple: do not just ask an agent to "do a good job." Give it reusable skills that make it clarify intent, separate design from implementation, write a concrete plan, use TDD, request review, and refuse to call work complete before verification.
As checked through the GitHub API on May 17, 2026, Superpowers had 194,953 stars and 17,332 forks. Its latest release was v5.1.0, published on May 4, 2026. Those numbers can be read as another overheated GitHub-star story. The more interesting signal is structural. Coding agents are moving from "which model writes better code" to "which process can make that model behave like a reliable engineer."
Superpowers is a process, not just a tool
The default Superpowers workflow is explicit. brainstorming first helps the agent understand what the user is trying to build. using-git-worktrees then prepares an isolated workspace. writing-plans breaks approved designs into small, verifiable tasks. Implementation can run through subagent-driven-development or executing-plans, while test-driven-development enforces the RED-GREEN-REFACTOR loop. requesting-code-review adds a review gate, and finishing-a-development-branch handles verification and integration choices.
That is different from a collection of prompt tips. The README says the agent checks for relevant skills before any task and treats them as mandatory workflows, not suggestions. In other words, the skill is not an optional reminder hidden inside a long instruction file. It is a procedural unit the agent is supposed to discover and follow.
This distinction matters in day-to-day agent use. Many teams start by adding natural-language instructions: write tests, make small commits, plan first, explain tradeoffs. Those instructions help, but long tasks erode discipline. The agent may stop asking clarifying questions, jump straight into code, misread a failing test, or declare victory before actually running the checks. Superpowers tries to move that failure pattern out of one-off prompting and into reusable process.
Why this matters now
The coding-agent market has been expanding quickly. OpenAI Codex now spans CLI, app, web, IDE, and remote-control surfaces. Anthropic connects Claude Code and Cowork to enterprise deployment. GitHub is embedding Copilot coding agents into issue and PR workflows. Cursor is blending the IDE with cloud agent execution. xAI has entered the terminal-based coding-agent race with Grok Build.
Model quality still matters in that competition. But model quality alone is not enough. Real software work rarely ends after one prompt. A useful agent has to understand requirements, read the existing codebase, define a test target, make a small change, debug failures, pass review, and clean up the branch. That is difficult for human developers. It is harder for agents because even capable models often skip process when they feel confident.
Superpowers' answer is not to give agents more freedom. It adds more engineering discipline on top of flexible models. Brainstorming narrows the problem. Planning turns intent into an implementable sequence. TDD makes progress observable. Review skills create a quality gate. Verification prevents a polished status message from substituting for evidence. The point is not that this exact workflow will fit every team. The point is that workflow itself is becoming a competitive layer.
What v5.1.0 tells us
The v5.1.0 release looks less like a feature dump and more like operational maturation. The notable changes include removal of legacy slash commands, a rewrite of the worktree skill, AI-agent contributor guidelines, Codex plugin mirror tooling, OpenCode bootstrap caching, and code-review consolidation.
The slash-command cleanup is especially telling. Older commands such as /brainstorm, /execute-plan, and /write-plan had become thin stubs pointing users toward the corresponding skills. The release moves the center of gravity toward named skills such as superpowers:brainstorming, superpowers:executing-plans, and superpowers:writing-plans. Superpowers is becoming less a command bundle and more a skill system.
The worktree changes are also important. using-git-worktrees and finishing-a-development-branch now account for whether the agent is already running inside an isolated worktree and prefer native harness behavior when available. In environments such as the Codex app, the harness may already manage worktrees. Blindly running git worktree add can create confusion or data-loss risk. The release notes go into details such as submodule guards, cleanup provenance, and detached-HEAD handling.
That shows where the category is heading. Skills can no longer assume one local Claude setup. They need to run across Codex CLI, Codex app, Cursor, Gemini CLI, OpenCode, GitHub Copilot CLI, and other harnesses with different workspace and permission models. A skill is starting to look like a cross-platform runtime layer for agent behavior.
A contribution guide for AI-generated slop
The most revealing part of v5.1.0 is the AI-agent contributor guidance. The release notes say an audit of the last 100 closed pull requests found a 94% rejection rate because of AI-generated slop. The failure modes were familiar: agents did not read the PR template, opened duplicate PRs, invented problem statements, or pushed changes that only made sense for a specific fork into the core project.
Superpowers responded by adding guidance for AI agents near the top of CLAUDE.md. The checklist tells agents to read the PR template, search for existing pull requests, verify that the problem is real, confirm that the change belongs in core, and show the full diff to the human partner before submission. For a new harness integration, the project also expects an acceptance test: in a clean session, when asked to build a React todo list, brainstorming should trigger automatically. A full transcript is required as evidence.
This is the open-source maintainer problem in miniature. AI coding tools make it cheap to generate pull requests, so maintainers receive more low-quality submissions. Superpowers is a project about teaching coding agents good development discipline, and it is also a project forced to defend itself against undisciplined agent contributions.
That irony is useful. It suggests what many open-source projects will face next. AI contributions cannot simply be wished away, but they need stronger entry gates. The maintainer's scarce resource is not code generation. It is review attention. If agent-generated work consumes that attention without carrying evidence, tests, or a clear problem statement, it becomes a tax on the project.
Why the Codex plugin mirror matters
Another small-looking change is Codex plugin mirror tooling. The release notes describe a sync-to-codex-plugin script that mirrors Superpowers into a repository shape suitable for OpenAI's Codex plugin marketplace. The README also explains that users can install Superpowers in Codex CLI and the Codex app through the official Codex plugin marketplace.
This is more than packaging convenience. It points at the market structure around coding agents. Today, users maintain tool-specific instruction files, rule systems, plugins, extensions, and marketplaces. Claude Code has a plugin marketplace. Codex has a plugin marketplace. Cursor and Gemini CLI have their own installation patterns. Superpowers supporting several harnesses is an attempt to make skills portable across agent runtimes rather than tied to one tool.
That portability matters for development teams. A team might use Claude Code today, Codex tomorrow, Cursor for one project, and OpenCode inside automation. If the team's engineering principles are scattered across tool-specific prompts, they are hard to govern. If a skill becomes the common unit, the rule can travel: no matter which agent we use, it should clarify intent, plan, test first, request review, and verify before declaring completion.
The bottleneck may be procedure, not intelligence
Superpowers raises a blunt question. When coding agents fail, is the model really not smart enough, or did the process collapse? Sometimes the model is the problem. It may hallucinate an API, misread a code path, or lose track of long context. But many agent failures are more mundane. The agent does not ask enough questions. It writes code without a test. It guesses at the cause of a failure. It says the work is done without running lint or build. It applies review feedback superficially.
Those failures are not solved only by larger models. Human developers make the same mistakes, which is why teams use code review, CI, tests, release checklists, ADRs, issue templates, and PR templates. Superpowers translates those old software-engineering devices into instructions an agent can understand and execute.
The TDD emphasis is particularly interesting. Many users ask coding tools to "also write tests." But tests written after implementation can easily rationalize the code the model just produced. The test-driven-development skill pushes the opposite order: write a failing test, confirm the failure, implement the minimal change, then refactor. As models become more capable, this kind of discipline may become more important, not less. A smarter model can be more convincing when it is wrong.
The darker side of skill ecosystems
Skills are not a magic safety layer. A skill file is still a set of instructions that an agent reads and follows. That can be useful, but it can also be malicious. The February 2026 arXiv paper "SoK: Agentic Skills" frames the risks around skill-based agents: supply-chain compromise, prompt injection through skill payloads, and trust-tiered execution.
Superpowers indirectly illustrates the same concern. It supports multiple marketplaces and harnesses, maintains a Codex plugin mirror, and adds stricter contributor rules. Skill distribution is not just copying files. A skill can influence local files, Git state, terminal commands, browsers, tests, and deployment workflows. That makes the skill ecosystem closer to a package-manager problem than a prompt-snippet problem.
In practice, teams need a few rules. Pin skill versions. Review skill updates like code changes. Document the tools and permissions a skill expects. Keep project-specific custom skills separate from core workflow skills. Preserve logs or transcripts that show whether the agent actually followed the skill. Superpowers' transcript requirement for new harness integrations is part of that accountability pattern.
The practical signal for developers
Whether or not a team installs Superpowers immediately, the lesson is clear. Choosing a model is not enough when bringing coding agents into a team. The team also has to decide what work agents may perform, what questions they must ask first, which test standard applies, what commands require approval, when review happens, and what verification is required before a task can be called finished.
That is stronger than an "agent usage guide." Human developers can often interpret a broad guideline. Agents need more explicit structure: triggers, steps, failure behavior, forbidden patterns, verification commands, and expected artifacts. In that sense, a skill sits between a prompt and a runbook. It is readable by humans but operational enough for an agent to execute.
There is another practical signal: task size matters. Superpowers' planning flow pushes work into small units. That is critical for agents. A large, vague request lets the model lose intermediate goals. A smaller task with clear file paths, expected tests, and review criteria exposes failure early. If teams want to benefit from agent speed, they also need to reshape work into units that agents can complete and verify.
The next layer of the coding-agent market
The AI coding market is becoming layered. At the bottom are models. Above them are execution surfaces: CLIs, IDEs, desktop apps, cloud agents. Above that are integrations with GitHub PRs, issues, CI, Slack, Linear, MCP servers, browsers, and deployment platforms. Now another layer is appearing: the methodology layer.
Superpowers is a representative example of that layer. It is not a product from OpenAI or Anthropic, but it tries to standardize agent behavior across several models and harnesses. That is what usually happens when a tool category matures. Once the model is capable enough, the next bottleneck becomes how reliably the model works.
Enterprises will probably demand this layer even more strongly than individual developers. An individual can undo a bad agent change. An organization needs to know which process an agent followed, which tests it ran, which review it received, and which approval allowed a file to change. Superpowers is still rooted in individual and open-source workflows, but its core concern overlaps with enterprise AI development governance.
The real story is repeatability
The rise of Superpowers is too interesting to reduce to "another popular tool." The deeper shift is that expectations around coding agents are changing. Users are no longer satisfied with agents that merely write code. They want agents that ask first, plan, test, accept review, verify, and integrate safely.
That expectation is not new to software engineering. Good teams have been doing it for years. The change is that the same discipline now has to apply to agents. Superpowers packages that discipline as skills. Its 194,953 stars are a useful signal, but not the main one. The main signal is that the next advantage in coding agents may come less from one brilliant answer and more from a repeatable development process.
The evaluation question should therefore become more concrete. Which model does this tool use? Which IDE or terminal does it run in? And now, one more question: what development process can this agent actually be made to follow? Superpowers is important because it makes that question hard to avoid.