Claude Code Superpowers Complete Guide: v6's Multi-Harness Development Methodology [2026]

Hello, this is Hamamoto from TIMEWELL.

When I wrote the first version of this article six months ago, Superpowers was "one person's open-source plugin for bringing discipline back to Claude Code." Open the repository description today, in July 2026, and it reads: "An agentic skills framework & software development methodology that works."¹ Not a plugin, but a development methodology that works. That single change of wording captures exactly what has happened to Superpowers over the past half year.

As of this writing, GitHub stars have reached roughly 257,000 and forks about 23,000, and it has spread less as a Claude Code accessory and more as "a pattern for AI coding in general."¹ And it no longer targets only Claude Code. The same skills now run across multiple harnesses, including Cursor, Antigravity, and GitHub Copilot CLI. From an individual's handy tool to a development discipline that an organization can standardize. This rewrite verifies where it stands now against primary sources. If you want to first gauge whether your organization is ready to take on this kind of standardization, the free AI readiness check is a good place to start.

What Superpowers Is (From Plugin to "Development Methodology")

Superpowers is MIT-licensed open source developed by Jesse Vincent (GitHub handle obra) and the "Prime Radiant" team he works with¹. In the first version I described it as "a plugin published solo by a former Anthropic engineer," but it is now less an individual project and more a public asset maintained continuously by a team. That distinction looks minor but matters: it feeds directly into the continuity and reliability you need before folding it into a business.

The essence of the contents has not changed. It is a collection of "instruction books for the AI" written up as Markdown SKILL.md files. A meta-skill is injected at the start of a session so that Claude always consults a skill before acting. With test-driven development (TDD — the practice of writing a failing test before you implement) and systematic debugging at its core, it walks the AI through requirements refinement, design, planning, and implementation in sequence. The fact that it is designed as a set of composable skills is why Superpowers works as a "pattern."

The rename from "plugin" to "methodology" is, I feel, not merely wordplay. A plugin is a question of whether you install it; a methodology is a question of how a team works. To the field's familiar complaint that letting the AI write freely produces unstable quality, Superpowers responds not by adding a tool but by imposing discipline on the way development itself proceeds. That is exactly why the adoption debate shifts from "it's convenient, so let's add it" to the heavier decision of "do we bend our development flow to this pattern." I actually see that added weight as a change that is easier, not harder, for enterprises to handle, because the object of the decision moves from tool selection to development-process design.

"Then vs. Now": What Changed Over the Past Half Year

Between February 2026, when I wrote the first version, and now, the premises have almost entirely turned over. First, scope. Back then it was effectively Claude Code-only; now multi-harness support is its biggest selling point. Next, models. The earlier article was written assuming "Opus 4.7 (the presumed flagship at the time)" and "Sonnet 4.7," but the current lineup is Opus 4.8 at the frontier tier, Claude Sonnet 5 (released June 30, 2026) as the workhorse for agentic development, and Fable 5, the general-availability top model recently redeployed²³. GitHub stars have also moved an order of magnitude, from around 57,000 then to roughly 257,000 now¹.

The design philosophy was revised too. In the old version I strongly pushed the point that "passing procedures as a flowchart (a GraphViz digraph) raises compliance." But the full rewrite in v6.0.0 replaced the bootstrap diagrams with prose⁴. The reason is cost. Handing over steps as a diagram is easy to read, but it eats tokens. If you can achieve the same effect more cheaply in prose, that is the call they made. Because the old version's praise for GraphViz conflicts with the current implementation, I am retracting it.

One more correction, stated plainly. The old version claimed that "the Claude Security public beta was released on April 30, 2026, the same day as Opus 4.7." Revisiting Anthropic's official newsroom this time, I could not confirm that date or the same-day release in any primary source³. Claude Security itself exists in Anthropic's product line, but I am withdrawing the assertion about its release timing. Writing a date on secondary information alone was a lapse. Numbers and dates get verified against the originator's primary source. Drop that principle and the ground gives way under an article that talks about compliance.

What Changed in the v6 Line (~2x Faster, ~50% Fewer Tokens)

Trace the current lineage and v6.0.0, on June 16, 2026, was the turning point. This release, which fully rewrote the repository, is explicitly described in the project's own evaluation as "roughly 2x faster" in execution and "about 50% lower" in token consumption⁴. In agentic development, tokens are a direct cost. Halving them means you can run twice as much on the same budget. That bears directly on the break-even math for enterprise adoption.

The internal improvements are practical too. The review stage, previously split across two prompts, was consolidated into a single task-reviewer-prompt.md, cutting redundant review round-trips. The brainstorming aid gained per-session authentication keys and sandboxed file delivery, raising safety around visualization. The location of worktrees was also moved from the user configuration directory into the project, so everything now stays self-contained per repository⁴. These look like small changes, but each is an adjustment toward "running safely inside an enterprise's repository."

Subsequent updates centered on stabilization and multi-platform support. v6.0.2 (June 17) separated out the evals submodule that had been breaking installation; v6.0.3 (June 18) adjusted where scratch files live. v6.1.0 (June 30) compressed the bootstrap further, trimming the redundant per-harness explanations to improve token efficiency while enabling Codex integration. The latest, v6.1.1 (July 2), mainly fixes the Codex hook configuration⁴. Viewed along the version axis, v6 is a single line running through "faster, cheaper, and safe across multiple environments." Given that the old version had effectively stopped at v5 or earlier, this whole section needed to be written afresh.

Multi-Harness Support and the Correct Install Commands

The biggest thing in v6 is, indeed, multi-harness support. Under the banner "one set of skills, every harness," the repository made a single set of skills usable in common across Claude Code, Cursor, Antigravity, GitHub Copilot CLI, Kimi Code, and Pi¹. Gemini CLI, which was once supported, was fully dropped from v6.0.0 onward following Google's end-of-life (EOL) for the service⁴. You can extend the same development discipline horizontally regardless of which tool a team uses. For anyone trying to lay down an organizational standard, that lands harder than you might expect.

The install command has changed from the old version, so get this right. The steps I wrote in the old version — /plugin marketplace add anthropic followed by /plugin install superpowers — are no longer correct. The current official marketplace name is claude-plugins-official.

Harness	Install command
Claude Code	/plugin install superpowers@claude-plugins-official
Cursor	/add-plugin superpowers
Antigravity	agy plugin install https://github.com/obra/superpowers
GitHub Copilot CLI	copilot plugin install superpowers@superpowers-marketplace
Kimi Code	/plugins install https://github.com/obra/superpowers
Pi	pi install git:github.com/obra/superpowers

When distributing internally, the quickest move is to paste this table straight into your onboarding materials. Even on teams with a mix of harnesses, the skill implementation is a single thing, so you can unify review criteria and operating rules. If you want to dig into how skill definitions themselves are written, or into designing your own in-house skills, the convention I laid out in the Claude Code Skills 4.5 complete guide — "put only trigger conditions in the description and keep the body focused on procedure" — applies directly here.

Where the 13 Skills Fit and Model Design (Opus 4.8 / Sonnet 5)

The current set is 13 skills. The old version's title and body said "14 or more," but the current repository's list is fixed at 13¹. In the spirit of not padding the count, let me correct that here too. Add a one-line note on how each is used in practice and it looks like this.

Category	Skill	Where it fits in practice
Testing	test-driven-development	The core discipline: write a failing test first, then make the implementation follow the test
Debugging	systematic-debugging	March from symptom to hypothesis to verification, preventing guesswork fixes
Debugging	verification-before-completion	Force the AI to actually run and confirm before saying "done," killing false completion reports
Collaboration	brainstorming	Have the AI ask about requirements and constraints, aligning premises before you start
Collaboration	writing-plans	Turn a spec into an implementation plan, broken into small task units
Collaboration	executing-plans	Execute the written plan in a separate session with review gates
Collaboration	dispatching-parallel-agents	Distribute independent tasks across parallel sub-agents
Collaboration	requesting-code-review	After implementation or before a merge, have it confirm spec compliance on its own
Collaboration	receiving-code-review	Verify the technical validity of review feedback before applying it, rather than swallowing it whole
Collaboration	using-git-worktrees	Isolate work from the current branch to prevent parallel-work accidents
Collaboration	finishing-a-development-branch	Wrap up merges, PRs, and cleanup after implementation, by the book
Collaboration	subagent-driven-development	One sub-agent per task, implementing independent tasks in sequence
Meta	writing-skills / using-superpowers	The foundation for creating new skills and invoking existing ones correctly

Skills are the vessel for discipline; the model is what actually writes the code. So decoupling model design from the picture is a mistake. My current recommendation is a setup that hands day-to-day agentic development to Claude Sonnet 5. Sonnet 5, released June 30, 2026, is positioned by Anthropic itself as "the most agentic Sonnet," with performance said to approach Opus 4.8². Pricing during the introductory period (through August 31, 2026) is USD 2 input / USD 10 output per million tokens, then the standard USD 3 / USD 15 thereafter². For the kind of Superpowers iteration that reads and rewrites the same files over and over — TDD, two-stage review — that cost efficiency pays off directly.

That said, running everything on Sonnet 5 is risky. High-difficulty design judgment and security-sensitive code that touches vulnerabilities should be routed to the frontier-tier Opus 4.8. Anthropic states that Sonnet 5 is clearly inferior to models such as Opus 4.8 on cybersecurity evaluations². Rather than covering the whole range with the cheap model, switch to the higher-tier model only for high-risk moments. Deciding this line as a team policy in advance keeps the balance of cost and quality from breaking. For vulnerability detection in AI-generated code itself, the cleaner framing is to hand that off to Anthropic's security product; I have summarized the operating patterns in the Anthropic Claude Security public beta implementation guide. Credentials and environment variables should not be entrusted to Superpowers but protected via the harness's own hooks and environment isolation — for that, see the Claude Code environment variables and security complete guide. If you want to lay the same discipline over company-wide knowledge work rather than just the engineering team, an enterprise AI platform like ZEROCK — with domestic AWS hosting, audit logs, and knowledge control — is one option worth considering.

Enterprise Adoption Pitfalls and Running an Organizational Standard with WARP

Superpowers is powerful, but distribute it company-wide as-is and problems are guaranteed. Across WARP-based engagements I have seen four pitfalls repeatedly. First, permission bloat. Some skills assume bash execution, worktree operations, and file deletion. Roll them out without checking against your IT policy and unintended operations can run against production repositories. It is safer to separate the skills you allow from those you forbid per business unit, and to bind permission scopes from the harness-side configuration.

Second, TDD enforcement becoming a hollow formality. The test-driven-development skill carries an iron rule: "you must not write implementation code without first writing a failing test." Teams that prioritize speed are tempted to downgrade this to a guideline, but doing so reverts to AI-driven implementation and quality degrades. Enforcing it or explicitly removing it — that binary choice causes less confusion for the team. Third, skipping the human approval gates. The requirements-refinement and design phases are, by design, gates for humans to agree on direction. Leaving those to the AI's internal reviewers alone usually means implementation proceeds on a wrong premise, producing large rework at the verification stage. At a minimum, keep a senior engineer's approval authority on the design and verify phases.

Fourth, managing the cost of review round-trips and sub-agents. subagent-driven-development spins up a sub-agent per task, so defaulting to the higher-tier model makes inference cost run hotter than expected. You need to set a cap on task size and route light fixes to Sonnet 5 — in other words, agree on a per-model cost policy up front. I dug into this point in the Claude Code agent teams operations guide as well. If you want to port Superpowers' sub-agent structure into your own workflows, the Claude Agent SDK implementation guide is also a useful starting point.

Making sure this design is not just "installed and distributed" is where WARP comes in. In TIMEWELL's AI implementation consulting service WARP, assuming the v6 line of Superpowers, we build an "organizational-standard operating design" together with you, fitted to your repository structure and IT requirements. Concretely: auditing existing repositories and development flows (permissions, TDD enforcement, review structure); distributing via the official marketplace and preparing internal guidelines; per-model cost and responsibility design across Opus 4.8 and Sonnet 5; embedding human approval into design and verification; and half-day to full-day workshops for engineering teams. Lately we hear especially often from companies that have thrown Superpowers in-house but are vague on who owns it and how far automation should go. Let us spend a 30-minute online session hearing your situation and mapping the next step. Reach out through a consultation to get started.

Unlike six months ago, when I was chasing Superpowers as a tool, what I am now facing is the question of "how do you root a development pattern into an organization." Precisely because it has matured as a methodology, the skill of adoption is now what makes the difference. Before you rush to company-wide deployment, first run the pattern all the way through with a single team. That, I believe, is the fastest road even though it looks like the long way around.

---

TIMEWELL Co., Ltd. — Ryuta Hamamoto

Footnotes

1. obra/superpowers, GitHub repository (current description, skill list, install commands, star count, license, author). https://github.com/obra/superpowers ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Anthropic, "Introducing Claude Sonnet 5" (2026-06-30; positioning, pricing, comparison with Opus 4.8). https://www.anthropic.com/news/claude-sonnet-5 ↩ ↩² ↩³ ↩⁴

3. Anthropic, Newsroom (primary index for Sonnet 5, Fable 5, Claude Science, Claude for Teachers, etc. The Claude Security public beta date is unconfirmed as of this writing). https://www.anthropic.com/news ↩ ↩²

4. obra/superpowers, Releases (changelog from v6.0.0 to v6.1.1, performance improvements, harness additions, prose conversion). https://github.com/obra/superpowers/releases ↩ ↩² ↩³ ↩⁴ ↩⁵