Superpowers vs. OpenSpec and Spec Kit: method or specification
Superpowers changes how your agent works. OpenSpec or Spec Kit change what ends up written in the repo. The real difference, and which one you need.
Superpowers and a specs framework like OpenSpec or Spec Kit aren’t alternatives to each other. Superpowers installs a method that changes how the agent works during the session. OpenSpec or Spec Kit change what artifacts end up written and versioned in your repository. You can use both at once.
Superpowers vs OpenSpec or Spec Kit: the difference in one table
The confusion comes from both starting the same way: both force you to write something before touching code.
| Superpowers (skills package) | OpenSpec, Spec Kit, BMAD (specs framework) | |
|---|---|---|
| What it installs | Skills the agent consults before each task [1] | Commands and templates that generate specification files |
| What it leaves written in the repo | A plan at docs/plans/YYYY-MM-DD-<feature-name>.md [2], code, and tests | Specs of the system’s behavior, organized by capability |
| When the session ends | The plan stays as a record; the discipline repeats because the plugin is still installed | The spec still describes what the system does |
| Who reviews it | You, when the agent presents the design to you section by section | The team, in the pull request |
That’s the row people overlook: a plan says what we’ll do this week; a spec says what the system does, and that question stays alive afterward.
What is Superpowers?
Superpowers is a plugin by Jesse Vincent that describes itself as “a complete software development methodology for your coding agents, built on top of a set of composable skills…” [1]. In Claude Code, it installs with one command:
/plugin install superpowers@claude-plugins-officialWhat you install is an ordered flow: brainstorming, which refines the idea down to questions and presents you the design section by section so you can validate it; using-git-worktrees, which isolates the work in a new branch with a clean test baseline; writing-plans, which splits the work into two-to-five-minute tasks with exact file paths; and execution via test-driven-development plus a code review before closing the branch [1].
The README makes it explicit: “Mandatory workflows, not suggestions” [1]. The agent looks for a relevant skill before each task and, if one exists, follows it. The guide on when to use skills in Claude Code explains when a skill kicks in and when it doesn’t.
Can you use both at once?
Yes, and it’s the most common setup: they govern different layers. Superpowers rules the conversation — the order the agent works in and what must be approved before the first line of code. The specs framework rules the repository — which files describe the system and how they get approved in the pull request.
Which one do I need?
Decide based on the symptom you have. It doesn’t matter whether the framework is OpenSpec, Spec Kit, or BMAD: all three sit on the same side of this decision.
The agent jumps straight into coding without thinking. You ask for a change and it’s rewriting four files nobody mentioned. A method package like Superpowers fixes that: it puts a design phase up front and makes it mandatory. Before installing anything, try Claude Code’s plan mode, which is free. You turn it on with claude --permission-mode plan or with Shift+Tab until you see ⏸ plan mode on; the agent reads files and proposes a plan without touching disk until you approve it [3].
Nobody knows why a decision was made three weeks ago. The code is fine and the tests pass, but the reason the discount gets applied before tax only lives in a Slack thread. A specs framework fixes that; which one, in the comparison of OpenSpec, Spec Kit, and BMAD.
Both problems at once. Start with whichever one hurts more today, and add the other once the first is already a habit.
That pattern, separating the thinking phase from the executing phase with an approval gate in between, is practiced in the course AI Agent Design Patterns.
Sources
- obra/superpowers — README — definition, installation, and “The Basic Workflow” (2026-09-21).
- obra/superpowers-skills — writing-plans — plan path (2026-09-21).
- Claude Code — Common workflows, “Plan before editing” — plan mode (2026-09-21).
- open-gsd/gsd-core — README — installation and GSD phases (2026-09-21).
Frequently Asked Questions
Does Superpowers replace OpenSpec?
No: Superpowers governs how the agent works during the session, and OpenSpec maintains system specs that stay valid after the merge.
What if I already use Spec Kit?
Spec Kit sits on the same side as OpenSpec: it settles what ends up written in the repository. What you still have to decide is whether you’re also missing a method — that is, whether your agent codes before it designs.
How is Superpowers different from GSD?
GSD overlaps more with the specs frameworks: it installs with npx @opengsd/gsd-core@latest, organizes the work into five phases (discuss, plan, execute, verify, and ship the PR), and keeps its state in STATE.md and CONTEXT.md [4]. It sits in both categories at once; Superpowers stays on the method side.
Does Superpowers work outside Claude Code?
Yes, the repository documents more than a dozen agents [1]. In the GitHub Copilot CLI, it’s two steps:
copilot plugin marketplace add obra/superpowers-marketplace
copilot plugin install superpowers@superpowers-marketplaceRelated articles
OpenSpec vs Spec Kit vs BMAD: Which Spec Framework Should You Pick?
A comparison of three spec-driven development tools (OpenSpec, GitHub Spec Kit, and BMAD Method): what each one does, how much ceremony it imposes, and which to choose for your project.
What is OpenSpec? The specs-before-code workflow
OpenSpec turns every change into a written proposal you approve before coding. What it is, how propose, apply and archive work, and when it pays off.
What Is Spec-Driven Development? Definition and Example
Spec-driven development (SDD) means writing a versioned spec that the agent reads before it codes. Definition, example, and when to use it.