Superpowers: How AI Agents Learn to Work Like Real Teams

Superpowers teaches Claude Code to work like a small team: design first, then a plan, then isolated implementation and a review that doesn't come from the author. What the skills really do, what the pattern caught in a real release, and when it is overkill.

Most mistakes a coding agent makes are process failures, not intelligence failures. It starts coding before the goal is clear. It checks its work in the same context it built it in. And it reports "done" without having run anything. A team catches exactly this with roles: someone clarifies, someone plans, someone builds, someone else reviews.

The open-source framework Superpowers by Jesse Vincent brings these roles to Claude Code. It is listed in the official Claude plugin marketplace; the plugin page counts more than a million installs (as of October 2026). I have been using it since February 2026, currently version 6.4.1.

What the Skills Really Do

Superpowers is made of skills: Markdown files that Claude loads automatically when the situation fits. Five of them form the core workflow, as written in their SKILL.md files:

A Real Run: the waiser.dev SEO Release

On 6 October 2026 I ran this pattern on my own website. The trigger was Google Search Console: indexed pages had dropped from 60 to 40, "Crawled – currently not indexed" had risen from 9 to 29, and there were 404 errors on odd /blog/blog/ URLs.

For context: I didn't run the Superpowers plugin itself but Claude Code's workflow orchestration, which I had already used in earlier runs with several parallel agents. The pattern was the same: plan, review the plan, implement in isolation, review the changes. 13 agent runs:

1. Plan team (3 + 1): three specialists for technical SEO, on-page hygiene and static-site engineering proposed 22 tasks and checked their claims against the code and in a browser. A lead agent turned them into one release with two workstreams and ten tasks.
2. Plan review (2): one reviewer for engineering risk, one as an SEO skeptic. Both: "approve with changes".
3. Revision (1): of 16 review points, the lead accepted 13, one partly, and rejected two with reasons.
4. Implementation (2): two implementers on strictly separate files, so no conflicts.
5. Change review (3): plan conformance, SEO verification, function in the browser.
6. Fix (1): one fixer for the valid findings.

Everything went live as a single release commit.

What the Reviewers Found (Selection)

• A generator that leaves half the work done. A new script writes the post links statically into the three blog index pages. Both plan reviewers reproduced it independently: if one file was missing a marker, the script still wrote the other two and only reported the error afterwards. Now it is all or nothing. Found before the script was in the repository.
• A release script in the wrong order. The generator only ran after a post had already been marked "published". Had it failed, the release would have been left half done. Order swapped, failure case tested.
• An incomplete fix. The cause of the /blog/blog/ 404s, a missing base-path case for the Chinese pages, I had found in the main session with Claude; two planners arrived at the same cause in parallel. The plan reviewers then showed that 404 pages under nested paths still linked to /blog/blog/. <base href="/"> closed the gap.
• An old mobile bug. At 390 px width the footer links ran out to x = 626 px. GitHub, LinkedIn and email were cut off and unreachable. The bug predated the release; only the functional reviewer noticed it.
• A forgotten side effect. The release script regenerates the index pages but never bumped their lastmod in the sitemap. Fixed, with a "never backwards" rule.

The most valuable finding was uncomfortable. The SEO skeptic contradicted the plan's core assumption: static links would not bring indexing back. 18 of the 28 non-indexed post URLs already had three or more static links; the pattern followed post age, not linking. The real lever, it argued, was a content review of the thin older articles. This one was on its list, at roughly 500 words back then. The lead accepted the correction but rejected the content review as an agent task: whether an article gets rewritten or retired is an editorial decision. The question came to me. This rewrite is my answer.

The fixer knew its limits, too. It deliberately left two valid findings alone: a text change in another article that the approved plan had ruled out, and a change to the project's instructions for agents that only I can approve. Both came to me with reasons.

What Actually Changes

1. A separate context is a real second opinion. A reviewer who never saw the implementer's reasoning doesn't share its blind spots either.
2. Review before code is cheapest. Three of the five bugs above were found in the plan and in a reference script, not in production code.
3. Roles beat numbers. The risk reviewer, the skeptic and the functional tester found different things. The same idea as multi-agent teams with CrewAI.
4. Proof instead of success reports. Implementers, reviewers and the fixer delivered their verification commands: exit codes, checksums, measurements in the browser.
5. The human stays the owner of goal and wording. Agents deliver findings and options. I decide what gets published.

"Evidence before claims, always." – core principle of verification-before-completion

What It Costs

According to the Claude Code documentation, every subagent (except a fork) starts with a fresh context, needs time to gather it, and its requests count toward the same usage limits as the main session. 13 agent runs means reading the code 13 times. Superpowers says so itself: subagent-driven costs a fresh context per task and per review; native is cheaper and faster.

Then there is review noise. Two points were rejected, several were nits. Someone has to evaluate every finding instead of applying it blindly. That is what the receiving-code-review skill is for: check against the code first, then implement, and push back with technical reasons instead of polite agreement. And reviewers mostly find what they are pointed at. Only the reviewer who measured in the browser at mobile width found the footer bug.

When It Pays Off – and When It Doesn't

It pays off when a mistake is expensive and public. My website goes live straight from main; a half-written script reaches every visitor immediately. The same goes for scripts that will later run unattended and for changes across many files.

It is overkill:

• for a one-file fix or a copy edit. Superpowers itself has the bounded path for that: a short design in chat, no spec, no plan.
• for feasibility questions. The spike path delivers an answer, not code you keep.
• for tightly coupled tasks. The skill recommends subagents only for largely independent tasks.
• when latency matters. For a quick question, the main session is better.
• for editorial decisions. Those belong to a human.

How I Use It

# Install from the official Claude marketplace
/plugin install superpowers@claude-plugins-official

# Alternatively: the Superpowers marketplace
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

1. Check the classification. At the start, Claude says whether it sees a spike, bounded or architectural task. If that's wrong, correct it right away.
2. Actually read the spec and the plan. The approval gates are where I contribute the most. Wave them through and you get wrong requirements, cleanly implemented.
3. Choose the execution mode deliberately. Many independent tasks and expensive mistakes: subagent-driven. Few, coupled tasks: native, with a review at the end.
4. Give reviewers different roles. At least one is allowed to attack the core assumption.
5. Demand verification commands. How to phrase such completion conditions is something I covered with /goal in Loops, Not Prompts.

I now use the pattern in other projects as well.

Writing Your Own Skills

writing-skills treats new skills as test-driven development: first a subagent works without the skill, and you note the excuses it uses to get around the rule. Then you write the skill against exactly those excuses and test again. I cover how skills are structured in Anthropic's Skills Blueprint.

Conclusion

Superpowers doesn't make a model smarter. It takes away its shortcuts: no code before the design, no review in its own context, no "done" without proof. In my SEO release, separate roles found the five bugs above, three of them already in the plan, and exposed a wrong core assumption. The price is time, tokens and the duty to evaluate every finding yourself. For a typo, it isn't worth it. For anything that runs unattended or goes live directly, it is.

Tools used:

Interested in AI-powered development workflows for your team? Get in touch. I help with implementing tailored solutions.