Claude Superpowers: Skills, Setup and When to Use It

What Is Claude Superpowers?

Superpowers is Jesse Vincent's library of engineering skills and the instructions that encourage a coding agent to use them. In Anthropic's Claude Code, the coding assistant that works with your repository, it supplies workflows for understanding a request, planning changes, testing, debugging, delegating and finishing a branch. Think of it as a workshop's operating manual: the tools are already there; the manual determines the order of work and the checks before handover. Superpowers README

Verified on 18 October 2026: the source manifest identifies version 7.0.0, and the repository contains 15 top-level skill folders with a SKILL.md file. That describes the source inspected for this article; check the revision your chosen marketplace installs. Plugin manifest, skills directory

The practical attraction is a visible chain of decisions. Before changing a feature, Claude can establish its intended behavior. Before calling it finished, it can demand a fresh test result. Those instructions give you something concrete to inspect, but they do not establish that the requirements or tests are correct.

How to Install Superpowers in Claude

Use one of the installation routes in the project's README, inside Claude Code. The commands below are copied exactly from its Claude Code section; they are interactive slash commands, not commands to paste into a normal shell. README installation instructions

Claude Superpowers Plugin: Official Marketplace Command

/plugin install superpowers@claude-plugins-official

The maker also documents its own marketplace. To use that route instead, register it and then install:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Choose a source you can keep track of. There is no benefit in using both routes as setup steps for the same plugin.

After installation, start a fresh Claude Code session to exercise the startup hook. Give it a bounded feature request, such as adding a filter to an existing task list. The observable check is whether it announces an appropriate skill and follows that skill's behavior. An installation command completing is a different observation from a workflow behaving as expected.

What Changes in a Session After Installation?

The first change is context: a startup hook places Superpowers' usage instructions in the conversation. The configured SessionStart matcher covers startup, clear and compact. Its script reads using-superpowers, injects that text, and directs Claude to load other skills through the Skill tool. It does not paste every skill's full contents into the startup message. Hook configuration, startup script

How a Claude Superpowers Skill Gets Selected

Claude matches the task to skill descriptions, then reads the relevant instructions. The plugin's authoring guide explains that descriptions should identify when a skill applies. The bootstrap tells the agent to check before responding or acting, announce the skill, and put process skills before implementation skills. Skill discovery guidance

That means a request to build something points toward brainstorming; a failing test points toward systematic-debugging. A domain skill can then guide the implementation. You can also explicitly request a skill by name, for example: “Use superpowers:systematic-debugging to investigate this failure before proposing a fix.” Usage instructions

Automatic selection is an instruction to the model, not a deterministic keyword switch. The hook supplies the bootstrap text; the agent still has to recognize the situation and follow the selected instructions. If it chooses the wrong workflow, correct the task scope or request the relevant skill directly.

Superpowers Skills and Their Triggers

The library covers the whole development cycle, but a session should load the skills that fit its work. These are the exact names in the inspected files. The trigger column paraphrases their descriptions and instructions; it is not a promise that a particular sentence always produces a particular invocation. Current skills directory

You do not need to memorize the inventory. For ordinary feature work, watch the transitions: understood request, concrete plan if needed, tested implementation, reviewed change, integration decision. For a bug, the useful starting point is investigation rather than a design conversation about a new feature.

How It Fits Beside Native Plan Mode and Your Skills

Superpowers imposes a workflow around planning; its writing-plans skill is a separate thing from Claude Code's native plan mode. The current bootstrap explicitly says to invoke brainstorming before entering plan mode if brainstorming has not already happened. It therefore establishes an order of operations rather than treating the native mode and its own plan-writing skill as interchangeable. Current planning instruction

writing-plans produces a repository document, normally under docs/superpowers/plans/, with implementation decisions and checks. At handoff, it asks the user to review that plan and choose an execution approach unless one was already supplied. A mode selection alone does not provide that document or those task instructions. For the host's controls and behavior, use the separate Claude Code plan mode guide.

Your own skills remain part of the picture. The plugin's writing-skills file identifies ~/.claude/skills/ as Claude Code's personal skills directory, and its bootstrap explicitly places user instructions, including CLAUDE.md and direct requests, above skill instructions. A project-specific skill can therefore carry your conventions while Superpowers supplies the development process. Define that division clearly if both prescribe how testing or review should work. Skill authoring file, instruction priority

For the underlying instruction-file concept, see agent skills. Superpowers is one opinionated collection built with that mechanism.

Claude Code Superpowers: One Feature From Idea to Merge

A “Hide completed” toggle is enough to show the full workflow. The following is a worked illustration derived from the skill files, not a recorded test session. The filenames, acceptance cases and outcome are hypothetical.

Assume an existing task-list app already has tests. The user asks for a toggle that hides completed items without deleting them. For this walkthrough, the user explicitly requests a written plan and subagent task reviews. A change this small would otherwise be a candidate for the shorter, chat-sized route.

Establish the Behavior: brainstorming

The important question is whether “hide” affects only the current view or changes stored tasks. In this example, the agreed behavior is a view-only filter: the toggle starts off, completed items reappear when it is switched off, and the filtered empty state says there are no active tasks.

Claude plays back that scope and obtains approval. Because the user chose the written route, the design goes into a document under docs/superpowers/specs/, with a builder check before handoff. The skill's normal small-change route allows the description and agreement to stay in chat. Brainstorming rules

The artifact you should inspect is the behavioral agreement. If it quietly adds saved preferences or changes task storage, the feature has already expanded before any implementation begins.

Make the Work Checkable: writing-plans

The plan divides the feature into independently checkable deliverables. One implements a filtering function in an illustrative src/tasks/filterTasks.ts, with tests for mixed, empty and fully completed lists. Another connects an accessible toggle in src/tasks/TaskList.tsx, using the agreed function interface and testing the visible result.

The plan names the files, interfaces, test assertions, project test commands and expected outcomes. It also records that filtering must leave the underlying task collection intact. The user reviews the plan and confirms the subagent route. This is where a vague instruction becomes something an implementer and a reviewer can disagree about precisely. Plan-writing instructions

Establish the Workspace: using-git-worktrees

At execution setup, Claude checks whether the work is already isolated. A Git worktree is another working directory for the repository, typically on its own branch. The skill prefers the host's native worktree mechanism and honors an existing user preference; otherwise, it asks before creating one.

For this illustration, the user agrees to a feature worktree. Claude runs the existing project tests there before changing the application. A failing baseline needs attention before later failures can be attributed to the new toggle. Workspace instructions

Implement the Tasks: subagent-driven-development and test-driven-development

The controller dispatches a fresh implementer for the filtering task, then arranges its task review. It proceeds to the UI task after that checkpoint. The current subagent skill checks specification compliance and code quality in the task review, then requires a broader review of the completed branch. It also records progress and decisions in a plan-specific ledger. Subagent workflow

Within implementation, test-driven-development supplies the red-green-refactor cycle. Here, a test first demonstrates that requesting the filtered view still returns a completed task. Only after observing that failure does the implementer add the filtering behavior, rerun the test and clean up the code while keeping tests passing. TDD instructions

For the UI deliverable, the useful assertion concerns what a user sees after operating the toggle. A test that merely checks whether a function was called would not establish the feature's visible behavior.

The alternative is executing-plans: Claude implements the plan itself in the current session, with a fresh whole-branch reviewer at the end when subagents are available. Choose that route when per-task handoffs are not the review structure you need. Inline execution instructions

Handle Findings: Review Skills and systematic-debugging

At the final branch review, requesting-code-review supplies the reviewer handoff. Suppose the reviewer finds that switching the toggle off does not restore completed tasks. receiving-code-review calls for checking that finding against the code and intended behavior before changing anything. Requesting review, receiving feedback

If the failure reproduces, systematic-debugging guides the investigation. Its phases move through root-cause investigation, pattern analysis, hypothesis testing and implementation. In the example, the hypothesis might be that the code replaced the original collection with the filtered one. Inspect that data flow, reproduce the loss, and fix the cause with a regression test. Do not simply force the toggle's visual state to look right. Debugging instructions

Prove Completion and Choose the Merge

verification-before-completion requires fresh command output before a success claim. For this feature, that means evidence for the filter behavior, toggle interaction and the relevant project checks, with unresolved failures stated plainly. Verification instructions

Then finishing-a-development-branch verifies the full suite and presents integration choices. On an ordinary named branch, the current file offers a local merge, pushing and creating a pull request, or keeping the branch. It waits for the user's decision; a review passing does not silently authorize a merge.

To complete this illustration, the user chooses a local merge into the confirmed base branch. Claude merges, tests the merged result, and cleans up the feature worktree and branch only after that result passes. Creating a pull request would instead leave the work awaiting the repository's merge process. Finishing instructions

When a Small Task Needs Less Process

The process becomes overhead when it keeps asking for decisions the request has already settled. Renaming a visible label with exact replacement text should not require the same preparation as changing how task state is stored. This is a judgment about the work the workflow adds, not a measured claim about elapsed time.

The current brainstorming file distinguishes three sizes:

• Quick, clear task: the request itself contains the necessary description; do it.
• Small change: agree on the description in chat, then build through the normal workflow.
• Project: approve a written design, then produce a full software implementation plan.

The same file lets the user explicitly opt out of the questions, ending that brainstorming gate. That opt-out does not automatically cancel the remaining testing or verification instructions. Task-sizing and opt-out rules

A useful instruction is: “This is a small change. Keep the description in chat, use the existing test setup, and do not expand the feature.” For an already settled wording correction, state the exact text and scope. These are task constraints the plugin's instruction hierarchy recognizes, not secret bypass commands.

The named limit is process overhead: extra conversations, plan artifacts, dispatches and reviews can be disproportionate to the remaining uncertainty. The source documents those steps; it does not tell you how many minutes your particular change will take. If the session repeatedly ignores its scope, the repository provides diagnosing-superpowers to inspect what happened using transcript evidence. Session-diagnosis skill

What's Overhyped About Superpowers?

A prescribed workflow is not proof of correct software or a speed improvement. A failing test can encode the wrong requirement, a plan can miss an integration constraint, and an agent reviewer can overlook a defect. Evaluate the assertions and diff, not the confidence of the completion message.

Subagent-driven work also does not mean every implementation task runs simultaneously. The current skill explicitly forbids parallel implementation subagents in that workflow to avoid conflicts. dispatching-parallel-agents is a separate skill for independent problems. Implementation dispatch rules

Nor does installation remove your responsibility for task scope or integration. The plugin's own finishing procedure keeps the merge decision with the user. Its strongest promise is procedural: it tells Claude what to check and what evidence to present. Whether that is useful depends on the work and on the agent following those instructions.

Who Should Install It, and What to Try Next

Install it when the recurring problem is skipped engineering decisions. For a solo builder whose agent rushes past requirements, start with a bounded feature that has a meaningful failure case. Inspect whether the session establishes behavior before implementation and supplies evidence afterward.

For an established development team, first reconcile its plan, testing and review conventions with the plugin's instructions. If your existing skills already encode the desired process, an additional general workflow may duplicate it. For mostly tiny, fully specified edits, there is less reason to adopt the entire method just to complete those tasks.

On Monday, choose one contained change and write down its acceptance criteria. Use Superpowers, inspect the selected skills, review the final diff and decide whether each additional artifact helped you make a decision. Keep the workflow because its checks were useful, not because it produced a long plan.

For adjacent tools that solve different problems, see the best Claude Code plugins.

Questions About Claude Superpowers

For practical guidance on building with AI, join the newsletter.