Superpowers: A Disciplined Development Workflow for Coding Agents
Superpowers is an opinionated software-development workflow for coding agents. It makes an agent clarify the problem, agree on a design, isolate the work, write an executable plan, implement with tests, request review, and produce fresh verification evidence before saying that the work is complete.
That distinction matters. Superpowers is not a model, an MCP server, or merely a directory of prompts. Its 14 skills are reusable Markdown instructions, but the plugin’s bootstrap and harness adapters are what make the agent check and apply those instructions at the right time. Installing only the skill files is therefore not always equivalent to installing the complete plugin.
The short version
Section titled “The short version”- Superpowers is strongest on ambiguous, multi-file, testable work where building the wrong thing is expensive.
- Its default path is: brainstorm → approved design → isolated worktree → detailed plan → task-by-task implementation with TDD and review → final verification → merge or PR.
- The current stable release contains 14 skills and documents ten installation targets: Claude Code, Codex App, Codex CLI, Cursor, and six other hosts.
- It shapes probabilistic model behavior; it does not create a hard policy boundary. Agents can still skip a test, misunderstand a rule, or behave differently after a model or harness update.
- Public evidence is promising for workflow compliance, especially verification, but there is no large independent benchmark proving that the complete bundle always improves code quality or cost.
- The full workflow has real overhead. Adopt it deliberately, measure it on your own work, and keep human approval, CI, and code review in place.
What Superpowers actually is
Section titled “What Superpowers actually is”Superpowers was published by Jesse Vincent and Prime Radiant in October 2025. The repository is MIT-licensed. At the July 11, 2026 snapshot it had approximately 252,000 GitHub stars and 22,500 forks. Those numbers show extraordinary interest, not verified active usage or effectiveness.
The system has three layers:
- Skills define reusable procedures such as brainstorming, TDD, systematic debugging, and verification.
using-superpowersis the bootstrap. It tells the agent to check for a relevant skill before answering, asking questions, inspecting the repository, or taking action.- Harness adapters map abstract actions such as reading files, dispatching agents, or starting a session onto Claude Code, Codex, Cursor, and other hosts.
The upstream porting guide is explicit about why the second and third layers matter: skill files sitting on disk are inert unless the host discovers them and the agent invokes them at the right moment.
Superpowers uses a strict precedence model:
- direct user instructions;
- repository and project instructions;
- applicable Superpowers skills;
- the agent’s default behavior.
Within the skill layer, process skills come before implementation skills. If there is even a small chance that a skill applies, the bootstrap tells the agent to load it first. This is why the plugin feels more like a development operating procedure than an optional prompt library.
Current version and distribution drift
Section titled “Current version and distribution drift”The upstream main branch matched v6.1.1 at commit d884ae0 when this guide was checked. Distribution channels were not all on that version:
| Channel | Observed state on July 11, 2026 | What it means |
|---|---|---|
| Upstream repository | 6.1.1 | Reference implementation used by this guide |
| Claude official marketplace | Pinned to the v6.1.1 commit | Current stable upstream content |
| OpenAI Codex plugin repository | Manifest reported 5.1.3 | Codex Marketplace could install older behavior |
| Cursor Marketplace page | Still displayed removed commands and a named reviewer agent | Its listing or package was older than current upstream |
skills.sh | Indexed 14 individual skill files | Useful for skill discovery and rough adoption, not proof of full plugin integration |
Check the OpenAI plugin manifest, the Claude marketplace manifest, and your locally installed manifest before diagnosing behavior. A marketplace’s marketing page can be older than its package—or the reverse.
This also explains conflicting documentation on the web. The Claude plugin page and the Cursor listing still mention slash commands such as /brainstorming or a named code-reviewer. Upstream removed the legacy commands and named reviewer in v5.1.0. Current skills should trigger from the task and workflow, not from those retired commands.
Installation
Section titled “Installation”Prefer the native plugin mechanism for your harness. It installs the bootstrap and adapter in addition to the shared skills.
Use the official Claude marketplace:
/plugin install superpowers@claude-plugins-officialOr add the upstream marketplace and install from it:
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplaceOpen Plugins in the sidebar, find Superpowers, and select the plus button. Then inspect the installed version because the OpenAI marketplace can lag upstream.
Open the plugin browser:
/pluginsSearch for superpowers and install it. Current upstream Codex integration intentionally relies on native skill discovery and declares an empty hook set; v6.1.1 fixed accidental discovery of Claude’s session hook.
Install from Cursor’s plugin interface:
/add-plugin superpowersAfter installation, compare the local manifest and available skills with upstream. The public marketplace listing was stale at the research snapshot.
Stable v6.1.1 also documents these hosts:
| Harness | Upstream installation path |
|---|---|
| Antigravity | agy plugin install https://github.com/obra/superpowers |
| Factory Droid | Add the Superpowers marketplace, then install superpowers@superpowers |
| GitHub Copilot CLI | Add obra/superpowers-marketplace, then install the plugin |
| Kimi Code | Plugin UI or /plugins install https://github.com/obra/superpowers |
| OpenCode | Follow the repository’s OpenCode installer |
| Pi | pi install git:github.com/obra/superpowers |
See the current upstream installation matrix before copying a command.
Why npx skills add is not always equivalent
Section titled “Why npx skills add is not always equivalent”The generic command below can copy the 14 portable skills into a host that understands the Agent Skills format:
npx skills add obra/superpowersThat can be useful when you want selected skill files, but it may omit the plugin manifest, session bootstrap, hooks, tool mapping, or re-bootstrap behavior after context compaction. The exact gap varies by harness. Use the native plugin when you want the complete Superpowers workflow; use a skills installer knowingly when you only want portable instructions.
The default lifecycle
Section titled “The default lifecycle”- Discover and design with
brainstorming. The agent inspects context, asks one question at a time, presents two or three approaches with trade-offs, and gets approval section by section. It writes the approved design todocs/superpowers/specs/YYYY-MM-DD-<topic>-design.mdand reviews the document before moving on. - Isolate the work with
using-git-worktrees. The agent first detects whether the harness already created an isolated workspace. Otherwise it follows repository preferences, asks before creating a new worktree, verifies the worktree directory is ignored, installs dependencies, and runs baseline tests. - Write an executable plan with
writing-plans. The plan records global constraints, interfaces, exact file paths, complete test and implementation snippets, commands, expected results, and small two-to-five-minute tasks. It is saved underdocs/superpowers/plans/. - Choose an execution mode.
subagent-driven-developmentstays in the current session when the harness can create subagents. A fresh implementer handles each task sequentially, followed by a read-only reviewer.executing-plansruns the saved plan in a separate session with review checkpoints. - Apply strict TDD. For behavior changes,
test-driven-developmentrequires the agent to observe a test fail for the right reason, make the smallest change that passes it, and refactor while green. Production code written before the test should be discarded unless the human explicitly authorizes an exception. - Review each task and the complete branch. Current
v6uses one task reviewer that returns two verdicts—specification compliance and code quality—then performs a final review of the whole branch. Important findings must be fixed and reviewed again. - Produce fresh evidence.
verification-before-completionrequires the actual output of the relevant test, build, type-check, or lint command before any success statement. - Finish deliberately.
finishing-a-development-branchreruns tests, detects whether the work is in a worktree, and offers explicit choices: merge locally, push and open a PR, keep the branch, or discard it. Destructive cleanup requires confirmation.
The lifecycle is intentionally front-loaded. It spends time reducing ambiguity before code exists, then uses test and review loops to reduce false confidence after code exists.
A concrete example: from vague request to PR
Section titled “A concrete example: from vague request to PR”Suppose the initial request is:
Add organization-level API keys with rotation and audit history.
A well-functioning Superpowers session should produce observable artifacts and checkpoints:
| Stage | Expected output | Human checkpoint |
|---|---|---|
| Brainstorm | Questions about ownership, key visibility, revocation, permissions, retention, and migration; two or three design options | Approve the behavior and threat model |
| Design | docs/superpowers/specs/2026-07-11-organization-api-keys-design.md | Review the durable specification |
| Isolation | A clean worktree with a passing baseline | Decide whether to accept a pre-existing test failure |
| Plan | Exact schema, API, UI, test, migration, and documentation tasks in docs/superpowers/plans/… | Approve scope and implementation strategy |
| Execution | A failing test, minimal implementation, passing test, commit, and reviewer report for each task | Resolve product questions and important findings |
| Final review | Whole-branch compliance and quality verdicts | Decide whether the branch is ready |
| Verification | Fresh migration, test, type-check, lint, and build output | Confirm release evidence |
| Finish | Merge, PR, keep, or discard | Choose the integration path |
The useful property is not that the agent “made a plan.” It is that the design, plan, test evidence, and review findings remain inspectable when the conversation is compacted or handed to another person.
The 14 skills
Section titled “The 14 skills”| Skill | Trigger and responsibility |
|---|---|
using-superpowers | Session bootstrap; checks relevant skills before any substantive response or action |
brainstorming | New behavior or creative work; turns an idea into an approved design |
using-git-worktrees | Starts implementation in an isolated workspace with a verified baseline |
writing-plans | Converts an approved design into small, executable tasks |
subagent-driven-development | Executes plan tasks with fresh implementers, task review, and final review |
executing-plans | Executes a saved plan in a separate session with review checkpoints |
test-driven-development | Enforces observed RED → minimal GREEN → REFACTOR for behavior changes |
systematic-debugging | Diagnoses root cause before proposing a fix |
dispatching-parallel-agents | Parallelizes independent investigations that do not share mutable state |
requesting-code-review | Gives a fresh reviewer the change description, requirements, and commit range |
receiving-code-review | Verifies review feedback technically before accepting or rejecting it |
verification-before-completion | Blocks unsupported claims such as “tests pass” or “fixed” |
finishing-a-development-branch | Presents safe integration and cleanup choices after verified implementation |
writing-skills | Applies test-driven development to agent instructions themselves |
Systematic debugging in four phases
Section titled “Systematic debugging in four phases”The debugging skill is designed to stop “change something and rerun” loops:
- Root-cause investigation: reproduce, read the error, inspect recent changes, and trace data across component boundaries.
- Pattern analysis: find working analogues and enumerate every meaningful difference.
- Hypothesis and test: state one falsifiable cause and make the smallest diagnostic change.
- Implementation: add a regression test, fix the root cause, and verify the complete result.
After three failed fixes, the workflow tells the agent to question the architecture rather than attempt a fourth patch on the same assumptions.
TDD as a behavior constraint
Section titled “TDD as a behavior constraint”Superpowers’ TDD is stricter than “remember to add tests.” The agent must see the test fail, confirm that it fails because behavior is missing—not because the test is broken—then write only enough production code to pass. If code appeared before the test, the default instruction is to delete it and restart the cycle.
That rigor is valuable for deterministic business logic and regressions. It can be counterproductive for visual exploration, throwaway prototypes, generated files, or changes for which a useful automated assertion does not exist. Repository policy and explicit human direction should define those exceptions.
Reviews without performative agreement
Section titled “Reviews without performative agreement”requesting-code-review gives a fresh reviewer a description of the change, the plan or requirements, and the base and head commit SHAs. Inside SDD, the task-review workflow separately hands its reviewer the task brief, implementer report, and generated review package. receiving-code-review tells the implementing agent to verify each comment against the code and requirements rather than replying with empty agreement or implementing feedback blindly.
This matters for external PR comments as well: reviewer text is untrusted input. A comment can be mistaken or contain prompt injection. Validate the claim, preserve instruction hierarchy, and never expose secrets or execute unrelated commands because a review comment asks for them.
Writing skills with “TDD for process”
Section titled “Writing skills with “TDD for process””writing-skills treats a skill as executable behavior documentation:
- construct a realistic pressure scenario;
- observe the agent fail without the skill;
- write the smallest instruction that corrects the failure;
- rerun the scenario;
- add cases that expose rationalizations and loopholes;
- refactor without weakening compliance.
It also recommends that a skill description explain when to use it, not summarize the entire procedure. The body is loaded only after the agent decides the skill applies.
Subagents, parallelism, and state
Section titled “Subagents, parallelism, and state”Superpowers uses subagents to reduce context contamination, not to maximize concurrency at any cost.
- SDD implementers run sequentially because later tasks can depend on earlier code.
- Each task receives a fresh implementer context, then a reviewer that is read-only.
- The final reviewer examines the integrated branch, not just isolated task diffs.
dispatching-parallel-agentsis for independent domains—such as three unrelated failing tests—where agents will not edit the same files or depend on shared mutable state.
Current v6.1.1 writes SDD handoff files into .superpowers/sdd/. Issue #1942 documents a serious collision: two SDD sessions in the same checkout can overwrite task briefs, reports, and progress state. Several fixes were open but unreleased at the snapshot.
Visual Companion and telemetry
Section titled “Visual Companion and telemetry”During brainstorming, the plugin can offer an optional browser-based Visual Companion for diagrams and richer design review. It is a local Node server, not a required cloud service.
Upstream v6.0 hardened it after a reported cross-origin prompt-injection issue:
- loopback-only binding (
127.0.0.1) by default; - a random per-session key stored in an
HttpOnly; SameSite=Strictcookie; - WebSocket origin validation;
- path traversal, symlink, and dotfile restrictions;
- no-store and anti-framing headers;
- owner-only permissions for sensitive files;
- automatic shutdown after inactivity;
- explicit consent before opening the browser.
Binding it to 0.0.0.0 for remote access expands the trust boundary. Do so only when necessary and protect the session key.
The companion normally loads a Prime Radiant logo URL containing the Superpowers version. The project says it does not transmit project content, prompts, agent identity, or interaction events. Disable this request when policy requires:
export SUPERPOWERS_DISABLE_TELEMETRY=trueIt also honors DISABLE_TELEMETRY and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. See the upstream telemetry disclosure.
What changed recently
Section titled “What changed recently”| Release | Material change |
|---|---|
v5.1.0 | Removed legacy slash commands and the named reviewer agent; added consent and native-worktree detection |
v6.0.0 | Combined two task reviewers into one reviewer with two verdicts; added final branch review, file-based handoffs, explicit model selection, new harnesses, and Visual Companion hardening |
v6.0.3 | Moved SDD handoffs from protected Git internals to .superpowers/sdd/, which later exposed the parallel-session collision |
v6.1.0 | Compressed bootstrap instructions, added the Codex marketplace manifest and native installation path, removed the Codex session hook, and removed Gemini from stable support |
v6.1.1 | Declared empty Codex hooks to prevent accidental Claude-hook discovery and made Codex packaging deterministic |
The v6 release claimed similar workflow quality at roughly twice the speed and close to half the tokens for Claude Code and Codex in the project’s own scenarios. The detailed cost experiment log warns that run-to-run variance is large, differences below roughly 20% can be noise in single runs, and fixture plans can distort absolute cost. Treat the headline as an upstream result for v6 versus earlier Superpowers—not a guarantee against vanilla agents.
Evidence: what we know and what we do not
Section titled “Evidence: what we know and what we do not”Project-run evaluations
Section titled “Project-run evaluations”Quorum / superpowers-evals runs real agent CLIs against scenarios for skill triggering, worktrees, TDD, subagents, review, verification, and cost. It is best understood as a workflow-compliance laboratory, not a general coding benchmark.
A five-agent full-suite experiment reported the following absolute pass rates on a development snapshot:
| Harness | Reported pass rate |
|---|---|
| Claude | 84% |
| Codex | 78% |
| Pi | 76% |
| Kimi | 74% |
| OpenCode | 71% |
Across the suite there were 189 passes, 57 failures, and 6 indeterminate results. Failures clustered around cost, over-triggering, and specification comprehension. There was no vanilla control group, so these figures compare harness compliance with the suite, not improvement caused by Superpowers.
Live evaluation commands use permissive or “dangerous” agent modes inside a throwaway HOME. The repository explicitly says that this is not a complete sandbox; public CI runs static checks and test infrastructure rather than every live-agent experiment.
Independent evaluations
Section titled “Independent evaluations”The most structured external evidence available at the snapshot came from Tessl:
verification-before-completionaveraged 1.22× its baseline score and 92% across three scenarios, mainly by supplying real command output and connecting claims to evidence.brainstormingaveraged only 1.05× across three scenarios; one improved strongly while two regressed, and the Visual Companion scenario scored zero. That page identifies commit896224c, a different development snapshot from stablev6.1.1.
Three scenarios per skill are a small sample, and Tessl did not publish behavioral impact tests for most of the other 12 skills. These results support targeted verification behavior more strongly than the complete workflow.
A small 12-run experiment by Nate Herk reported 9% lower cost, 14% fewer tokens, lower variance, and better structure with Superpowers, but also about 8% overhead on simple work and no improvement in domain knowledge or specification compliance. It tested three small tasks on a pre-v6 version; the author described it as directional, not conclusive.
Hands-on comparisons are mixed:
- AI Unleashed found similar applications after roughly 25 minutes with Superpowers versus 10 minutes vanilla; both missed a requirement, while the Superpowers reviewer found a real logic bug.
- Chase AI observed approximately 60 minutes and 250K tokens for Superpowers versus 20 minutes and 200K for vanilla in one app test, but the Superpowers result worked on its first attempt.
- The
chardet7 rewrite is an impressive real-world case: its maintainer used Superpowers and Opus over four days before a release reporting major performance improvements. It is not an A/B test, and the subsequent licensing and provenance dispute shows why human legal and maintainability review remains essential.
An independent academic benchmark, SWE-Skills-Bench, did not test Superpowers by name. Across 49 other software-engineering skills, the average gain was only 1.2%, 39 showed no pass-rate improvement, token overhead reached 451%, and version mismatches sometimes hurt performance. The valid inference is general: skills are model-, harness-, version-, and task-sensitive. It is not evidence for or against Superpowers specifically.
Community reports
Section titled “Community reports”Community experience repeats the same trade-off. Evan Schwartz praised incremental questions, explicit alternatives, durable design documents, and fresh reviewers. A large mixed Reddit discussion includes users who value consistency, users who retain only brainstorming, and users who find modern native plan modes sufficient. Hacker News discussion of v6 similarly combines praise for TDD and published evals with concern about overhead and limited independent evidence.
These are useful reports of failure modes and preferences, not representative measurements.
Costs and known limitations
Section titled “Costs and known limitations”Time, tokens, and artifact volume
Section titled “Time, tokens, and artifact volume”The workflow intentionally adds questions, design documents, plans, test cycles, subagent prompts, reviews, and verification commands. That investment can prevent expensive rework on a large feature. On a two-line fix it can dominate the task.
Plans are especially detailed: current writing-plans asks for complete code, tests, commands, and expected output. Issue #895 argues that this can make executors copy a solution instead of reason about it. The maintainer considers that detail intentional because it lets cheaper or weaker executors succeed. Which trade-off is right depends on your model mix and review process.
Harness and model drift
Section titled “Harness and model drift”The same Markdown instruction can trigger different tool choices or compliance levels across hosts and model releases. Native planning, subagents, worktree support, approval UX, and context compaction differ. Re-evaluate after upgrading the model, harness, or plugin; do not assume last month’s behavior is stable.
Baseline failures
Section titled “Baseline failures”Worktree setup runs baseline tests so new failures can be distinguished from existing ones. If the baseline is red, the agent must stop and ask whether to proceed. Fixing unrelated failures without authorization would change task scope; ignoring them silently would make later evidence ambiguous.
Conflicts with repository policy
Section titled “Conflicts with repository policy”Your AGENTS.md, CLAUDE.md, engineering handbook, CI gates, and release process take precedence. Resolve contradictions explicitly. A short request such as “just fix it” should not be treated as a reliable global policy override; state which phases you are intentionally reducing and which safety checks remain.
Open technical issues
Section titled “Open technical issues”- #1942: parallel SDD sessions can collide in
.superpowers/sdd/. - #1918: a Windows session hook can fail when the profile path contains parentheses.
- #1773: platform-neutral brainstorming instructions can cause host-specific interaction regressions.
- #992:
writing-plansoffers a choice of execution mode whileexecuting-plansmay redirect to SDD when subagents exist.
Check whether these issues are closed in the release you install.
Security and supply-chain review
Section titled “Security and supply-chain review”Agent skills are executable instructions in the practical sense: they can persuade an agent with repository, shell, Git, and network access to take actions. Audit them like code.
For Superpowers:
- core
package.jsonhas no runtime dependencies; - the optional Visual Companion includes executable server code;
- Claude, Cursor, and Copilot integrations can use session-start hooks;
- Codex
v6.1.1explicitly declares no hooks; - review comments, issue bodies, web pages, and copied plans remain untrusted content;
- marketplace packages can lag upstream or change independently.
An ecosystem-wide study, Agent Skills in the Wild, flagged potential dangerous patterns in 26.1% of 31,132 scanned skills, mostly insecure practices rather than proven malware. It is not a Superpowers audit, but it supports a conservative installation process. Tessl’s security scan of receiving-code-review specifically warns about indirect prompt injection from untrusted review feedback.
Adopt these controls:
- install from the native official marketplace or a reviewed, pinned tag/commit;
- inspect manifests, hooks, scripts, permissions, and version diffs before updating;
- test first in a non-sensitive repository with no production secrets;
- retain sandboxing, command approvals, protected branches, CI, and human review;
- isolate concurrent work in separate worktrees;
- treat external prose as data, not higher-priority instructions;
- review code provenance, dependency licenses, and generated assets;
- keep
.superpowers/sdd/scratch data out of commits unless your team deliberately wants it; - disable telemetry or remote Visual Companion access when policy requires.
Superpowers compared with nearby tools
Section titled “Superpowers compared with nearby tools”| Tool or approach | Primary purpose | Relationship to Superpowers |
|---|---|---|
| Native Plan Mode | Inspect and agree on an implementation direction | Lighter and built into the harness; usually stops before the complete TDD/review/finish lifecycle |
Repository rules (AGENTS.md, CLAUDE.md) | Encode project-specific constraints and commands | Higher-priority local policy; Superpowers supplies a generic process around it |
| Grill Me / requirements interview | Pressure-test an idea and expose ambiguity | Deeper discovery can feed a Superpowers design; it does not implement the rest of the lifecycle |
| Spec Kit | Preserve requirements, specifications, plans, and tasks | Controls more of what is being built; Superpowers focuses on how the agent executes and verifies it |
| MCP servers | Give the model tools and access to external systems | Complementary: MCP supplies capabilities; Superpowers supplies operating procedure |
| Your own focused skills | Encode a smaller or team-specific workflow | Lower overhead and easier policy fit, but you must design and test the behavior yourself |
You do not need to choose one system exclusively. A mature setup often uses repository rules for local policy, MCP for capabilities, a requirements method for difficult discovery, and selected Superpowers skills for execution discipline.
When to use it
Section titled “When to use it”The complete workflow is a good default when:
- requirements are ambiguous and a wrong interpretation would be costly;
- a feature spans several layers or files;
- behavior can be specified and tested;
- a refactor needs reliable regression protection;
- a bug has resisted obvious fixes;
- the work will be handed across sessions or people;
- fresh-context implementation and review are valuable;
- your team lacks a consistent agent workflow.
Use a reduced workflow—or no Superpowers—when:
- the task is read-only research or explanation;
- the change is mechanical and trivially verifiable;
- you are exploring a disposable prototype;
- strict TDD is a poor fit for the output;
- your established engineering process already provides stronger equivalent gates;
- wall-clock time or token budget is more important than reducing rework;
- you cannot isolate concurrent SDD sessions safely.
Selective adoption is legitimate. brainstorming, systematic-debugging, and verification-before-completion can deliver value independently. If you omit phases, make the decision explicit instead of depending on the agent to infer it from an impatient prompt.
A team adoption plan
Section titled “A team adoption plan”- Choose one representative pilot. Use a medium-sized feature with clear acceptance criteria, not a toy task or the highest-risk production migration.
- Record a baseline. Capture first-pass acceptance, wall-clock time, tokens or cost, number of human corrections, test failures, and review defects for comparable vanilla work.
- Pin and inspect the plugin. Record the upstream tag, marketplace package version, harness version, model, approval mode, and any disabled skills.
- Define policy boundaries. Decide which repository instructions take priority, when TDD exceptions are allowed, who approves design and plans, and which commands always require confirmation.
- Run isolated. Give each concurrent workflow a separate worktree and keep production secrets out of the environment.
- Review the artifacts. Judge whether the design and plan reduced ambiguity or merely added text. Check whether tests failed before implementation and whether review found real defects.
- Compare outcomes. Measure first-pass acceptance, escaped defects, iteration count, time, token cost, and maintainability—not just whether the agent finished.
- Keep, tune, or remove skills. Re-run the pilot after model or harness upgrades. A useful workflow is allowed to become lighter as native agents improve.
Troubleshooting checklist
Section titled “Troubleshooting checklist”| Symptom | What to inspect |
|---|---|
| The agent jumps straight to code | Confirm the complete plugin—not only copied skills—is installed; inspect bootstrap/hook activation and installed version |
| Old slash commands or named reviewer appear | You likely have a pre-v5.1 package or stale marketplace content |
| Codex runs a Claude session hook | Upgrade upstream integration to v6.1.1 or later |
| No subagents are created | Confirm the harness supports them; use executing-plans in a separate execution session |
| Worktree setup stops | Inspect repository worktree conventions, ignore rules, dependency setup, and baseline failures |
| The agent says tests pass without output | Invoke verification-before-completion and require the command plus fresh output |
| TDD is skipped | Treat this as a failed workflow run; add an external CI or review gate rather than trusting instruction wording alone |
| Two sessions receive the wrong task | Stop both; isolate them in separate worktrees and inspect .superpowers/sdd/ for #1942 collisions |
| Responses become slow or verbose | Compare a smaller skill subset, reduce unnecessary full-pipeline use, and measure tokens after each upgrade |
Sources and verification
Section titled “Sources and verification”This article uses a hierarchy of evidence:
- Source of truth: tagged upstream code,
v6.1.1release notes, individualSKILL.mdfiles, manifests, hooks, and tests. - Distribution state: Claude’s official manifest, OpenAI’s plugin manifest, Cursor’s marketplace listing, skills.sh, and the Claude plugin page.
- Project evaluation: Quorum / superpowers-evals and its experiment logs. These are first-party workflow evaluations.
- Independent evidence: Tessl behavioral and security evaluations, SWE-Skills-Bench, hands-on comparisons, the
chardetcase, and independent technical commentary. - Anecdotal evidence: issue reports, Reddit, and Hacker News. These identify plausible failure modes but do not establish prevalence.
Install counts also measure different things. At the snapshot, skills.sh showed roughly 2.2 million aggregate skill installs, while the Claude plugin page showed roughly 941,000 plugin installs. Do not add these numbers, compare them directly, or confuse either with active users. GitHub stars are a third, unrelated metric.