Superpowers (obra): The Skills Framework That Makes Coding Agents Plan, Test and Review

Superpowers is a software development methodology packaged as agent skills, and it is back on GitHub's trending list with roughly 299,000 stars. Created by Jesse Vincent and the team at Prime Radiant, it is MIT-licensed and installs on fifteen different coding agents. Instead of giving an agent more tools, it changes how the agent works: ask questions first, get a design approved, isolate the work in a git worktree, break the plan into tiny tasks, write tests before code, and review between tasks. The README calls these "mandatory workflows, not suggestions."

For background, see our agent skills guide and the loop engineering guide. For a competing mega-collection, see our ECC guide.

TL;DR: questions answered

The seven-stage workflow

The README describes a pipeline that the agent follows automatically:

1. Brainstorming. Before building, the agent asks questions to clarify intent, then restates its understanding so you can correct it. Small changes are settled in chat; larger projects get a written design document.
2. Git worktrees. After you approve the design, the agent creates an isolated branch workspace, runs project setup and verifies a clean test baseline. This is the same isolation idea as in our guide to parallel Claude Code sessions with worktrees.
3. Writing plans. The design is split into tasks of about two to five minutes each, with exact file paths, complete code and verification steps.
4. Execution. Two modes: subagent-driven-development spawns a fresh subagent per task with review after each, described as the most thorough; executing-plans runs inline in one session with a single final review, described as the cheapest.
5. Test-driven development. Enforces red, green, refactor. Per the README, code written before its tests gets deleted.
6. Code review. Between tasks, work is checked against the plan and issues are reported by severity. Critical issues block progress.
7. Finishing the branch. Once tests pass, the agent offers merge, pull request, keep or discard, and cleans up the worktree.

The skills library

The README groups the skills into four buckets:

• Testing: test-driven-development
• Debugging: systematic-debugging, verification-before-completion, diagnosing-superpowers
• Collaboration: brainstorming, writing-plans, executing-plans, dispatching-parallel-agents, requesting-code-review, receiving-code-review, using-git-worktrees, finishing-a-development-branch, subagent-driven-development
• Meta: writing-skills, using-superpowers

The meta skill using-superpowers is what makes the rest work: it instructs the agent to check for relevant skills before any task. The stated philosophy is test-first development, systematic over ad-hoc work, complexity reduction, YAGNI and DRY, and "evidence over claims". If you remember nothing else, remember the last one: the verification-before-completion skill exists to stop an agent from announcing success without running the check.

How to install it

Install separately for each harness you use. The README's commands:

It also lists Antigravity, the Codex app and CLI, Factory Droid, Grok Build CLI, Kimi Code, OpenCode (the agent fetches an INSTALL.md) and Muse. The Claude Code route through the official marketplace is the one most readers want, and our Claude plugin directory guide explains how that directory works. After installing, start a new session and ask for a feature; if the skills are active, the agent will begin with clarifying questions rather than code.

Honest limitations from the README

• Hermes lacks a post-compaction hook. In long sessions that compact, the bootstrap instructions can be lost and a fresh session may be needed. See our Hermes Agent v0.22 post for the harness itself.
• Muse requires hook approval on first install. Pi's subagent and task-list tools are optional companion packages.
• No new skills accepted, generally. Changes must work across every supported agent, which keeps the core small but limits community extension.
• Updates depend on your agent and are often automatic, so behavior can change under you. Pin where your harness allows it.
• Autonomy claim. The "couple of hours" figure is the project's own description of typical sessions, not a benchmark. Test it on your codebase.

Telemetry and trust

The README discloses one telemetry-like behavior: the brainstorming visual companion loads a Prime Radiant logo from the project's website, and the request includes the Superpowers version. Set SUPERPOWERS_DISABLE_TELEMETRY to turn it off; Claude Code's DISABLE_TELEMETRY and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC settings are honored too. The diagnosing-superpowers skill can read session transcripts and export a scrubbed bundle for bug reports, so read the output before you attach it anywhere. The project also offers enterprise support and managed spending through its commercial arm.

Any skills framework is code and instructions that your agent follows with your permissions. Review the repository before you install, and use a runtime guard for agents with shell access: AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions.

What people are asking

Does the agent really delete code written before tests? That is what the README says the TDD skill enforces: code written before its tests gets deleted. In practice it means the agent restarts a task from the failing test. If that sounds wasteful, remember the premise: a test written after the code tends to describe the code, not the requirement.

Why does it keep asking me questions? That is stage one by design. The brainstorming skill asks clarifying questions and restates its understanding before any file changes. For a small change it settles in chat; for a larger project it writes a design document for your approval. If you want speed, give a precise request up front and the questions shrink.

What does "subagent-driven" cost? A fresh subagent per task, with a review after each, uses more tokens than one long session, because each subagent re-reads the context it needs. The README describes the inline alternative as the cheapest. A reasonable default is inline for routine work and subagent-driven for risky changes.

Can I run it with a cheap or local model? The README lists harnesses such as OpenCode, Qwen Code, Hermes and Pi, which can point at many models. Strict workflows depend on the model following long instructions reliably, so weaker models may skip steps. Test with the model you intend to use, and see our OpenCode guide for the model-switching side.

Can I add my own skills? The writing-skills meta skill is there for that. Note the README's contribution policy: new skills are generally not accepted into the main repository, and updates must work across all supported agents, so keep your own skills in your own plugin or project folder.

A practical first session

Try this on a small feature in a repository with working tests:

1. Start a fresh session and describe the feature in two sentences.
2. Answer the clarifying questions, and correct the restated understanding if it is off.
3. Approve the design, then watch for the worktree creation and the clean-baseline test run. If the baseline fails, the agent should stop and tell you rather than proceed.
4. Read the plan before execution starts. Tasks should be small, with file paths and verification steps; if a task reads like "implement the backend", send it back.
5. Let it run, then read the review notes between tasks. Critical issues should block progress, so a run that never reports any is a signal to check whether the review skill is firing.
6. At the end, choose merge, pull request, keep or discard. Keep the branch until you have read the diff yourself.

This sequence also shows you quickly whether your agent harness triggers skills properly, which is the most common failure mode with any skills framework.

Is it right for you?

Good fit: feature work in a codebase with tests, where wrong turns are expensive and you would rather approve a design than review a 2,000-line diff. The two-to-five-minute task size makes failures cheap to spot.

Poor fit: quick one-off scripts, exploratory data work, and repositories with no tests. The ceremony costs time and tokens, and the TDD rule assumes a test harness exists.

A fair experiment: run the same three tasks with and without Superpowers, using both execution modes, and record wall-clock time, tokens, number of corrections you had to make, and test coverage. Skills frameworks tend to win on correctness and lose on speed; whether that trade is worth it depends on your cost of a bug.

How it compares

The takeaway: Superpowers is less a tool than an opinion about how agents should work, and a widely adopted one. If you have been burned by agents that start coding before understanding, that opinion is worth an afternoon of testing.

Related reading

• What are agent skills? A complete guide
• Loop engineering for coding agents
• ECC: 71 agents and 311 skills
• AI-DLC steering rules
• Parallel Claude Code sessions and worktrees
• Top 25 Claude plugins

Details are from the Superpowers repository README on October 15, 2026 and change frequently.