TL;DR: Faced with real, often unclear requirements, letting the AI participate in design and guide you through thinking and validation beats forcing yourself to write a complete spec first, then dumping execution onto the AI. The former is superpowers; the latter is spec-kit.
1. The Core Argument
spec-kit puts the “spec” at the center of the whole workflow: first /specify to write the requirements, then /plan for the technical approach, then /tasks to break it down, and finally /implement to let the AI execute step by step. It’s a textbook Spec-Driven Development (SDD) pipeline — think it through first, then hand it to the AI.
That approach has its merits, but it carries a strong hidden assumption: humans can (and should) figure out the requirements and design on their own, before touching any code.
superpowers takes a different path — the AI clarifies the requirements one question at a time, Socratic-style; you think and decide during the interaction; then you move into implementation. It encodes best practices as “mandatory” skills, not “suggested” templates.
Letting the AI participate in design and guide you through thinking and validation is more AI-native than forcing yourself to generate technical docs and blindly relying on the AI to execute.
superpowers is the poster child for the former. I genuinely can’t stop using it lately.
- Skills project: github.com/obra/superpowers
- For comparison: github.com/github/spec-kit
2. spec-kit’s Problems, In Practice
2.1 The Waterfall Vibe Is Hard to Stomach
Handle a moderately complex requirement the spec-driven way, and /specify spits out a thousand-line spec right away. Honestly, a few minutes in and I want to close the tab.
By the /plan stage the doc is even longer — even less appealing. By the time you reach /tasks and /implement, the direction has already drifted — and you never had the energy to review that giant spec word by word, so you never caught it early.
This is the classic waterfall problem: all the critical decisions get crammed into the very front, while feedback doesn’t show up until the very end. Software engineering figured out decades ago that “freeze requirements, then march linearly” is fragile under uncertainty. Swapping a human executor for an AI doesn’t fix that structural flaw.
spec-kit does offer /clarify as a patch. But here’s the thing: if you never really dug in from the start, what exactly are you clarifying? Clarification assumes you already know what needs clarifying — which is precisely what’s missing when requirements are vague.
2.2 With Fuzzy Requirements, Generating Docs Directly Invites Drift
In real life, requirements show up fuzzy more often than not: how many details in the local code need changing, which of several feasible approaches to pick — half the time I can’t even articulate it myself at the start.
Fire off /specify in that state and you get one of two outcomes: either it drifts, or it’s so long I don’t want to read it.
There’s a word for that feeling: TL;DR.
And a spec nobody actually reads carefully, no matter how “properly” formatted, isn’t really constraining the output quality.
2.3 Forcing “Human Designs First, AI Executes Later” Is Unrealistic for Fuzzy Requirements
There’s another argument behind spec-driven dev: write the plan to the point where “an intern could execute it directly,” and the AI will naturally produce stable output. Backend scenarios with lots of dependencies especially push this line.
But my actual experience is: the design process itself needs AI help too.
Demanding that a human independently nail the design before handing it to the AI is unrealistic when requirements are fuzzy. The idea in your head has huge entropy; expressing it in words is inherently lossy; writing everything down in exhaustive detail is exhausting and easy to get wrong. The sane move is to let the AI drag that fuzzy blob out of your head through questions and align it — not to demand a perfect spec up front.
The key difference: spec-kit assumes “the human can finish the design alone”; superpowers assumes “the design itself needs AI assistance.” The fuzzier the requirement, the more the latter shines.
3. A Real Head-to-Head
I ran the same moderately complex requirement through several approaches. The results speak for themselves:
| Approach | Result | Problem |
|---|---|---|
| Pure vibe coding (just let the AI write) | ❌ | Heavy hallucination, debugging is a nightmare |
| Weaker model + spec-driven | ❌ | Model isn’t smart enough; even a full spec can’t save it |
| Strong model + spec-kit (spec-driven) | ❌ | Waterfall syndrome: long, rigid flow, direction drifts early |
| Strong model + spec-kit + multi-agent parallel | ❌ | No real context — just a token flamethrower 💸 |
| Strong model + Superpowers | ✅ | Lots of interactive confirmation, high design quality |
Only the last one worked. Before logging off, I finished the design doc via brainstorming and loaded up the context, then ran writing-plan + exec-plan; after hours I let it run the impl; the next morning, local verification passed on the first try.
If you know, you know.
4. The Three Core Designs of Superpowers
superpowers is one of the most popular Claude Code plugins right now, with a huge following on GitHub. Author Jesse Vincent’s philosophy, in one line:
Mandatory workflows, not suggestions.
After using it, I think three designs stand out — and they’re the core differentiators from template-and-pipeline tools like spec-kit.
4.1 Interactive Brainstorming
brainstorming kicks in before any code is written: confirming one question at a time, instead of dumping 1000 lines of docs on you at once.
The experience gap this creates is night and day:
- I can actually follow along and participate in the thinking, instead of passively waiting for a possibly-drifted result.
- Often the requirement is fuzzy and I haven’t thought it through either — the Socratic questioning actually helps me figure out the problem.
- Every design point is confirmed with me; I can interrupt and split things at any point.
By contrast, spec-kit’s /specify compresses that whole “think it through” phase into a one-shot doc generation, turning clarification into an after-the-fact patch — humans can barely intervene at that node.
4.2 Worktree Multi-Branch Isolation
using-git-worktrees activates once the design is approved: each task runs in its own git worktree. The benefits are obvious:
- ✅ Main branch stays clean; you can switch back anytime.
- ✅ Multiple tasks run in parallel without interfering.
- ✅ If it fails, just delete the worktree — zero-cost rollback.
main (safe)
├── worktree/feature-a (AI messes around here)
├── worktree/feature-b (another AI messes around here)
└── worktree/refactor-x (broke it? just delete it)This is an engineering mindset: don’t let the AI rampage on main — give it a sandbox, merge only when it’s good. spec-kit stays mostly at the “produce documents” layer and has no built-in answer for “what if the AI breaks things, how do I roll back safely.”
4.3 Verification Loop First
superpowers emphasizes TDD, but I think its real value isn’t the “test-driven development” dogma — it’s building a feedback loop for the AI.
The AI doesn’t inherently know whether its output is correct. Without tests, it can only judge by “looks right.” But “looks right” and “is right” are very different things.
Set up the test framework and verification loop first, and the AI gets a reAct path — write code, run tests, red means fix, green means continue. It’s a closed loop; the AI can iterate and converge on its own.
The verification loop is a mindset that can land on any dimension: unit tests, e2e, type checking (tsc/lint), browser MCP for UI behavior… A project doesn’t have to be strict TDD, but it absolutely needs this loop.
AI development without a verification mechanism is like walking blindfolded. spec-kit focuses on “write the spec correctly” and leaves “how does the AI confirm it did things right” to the user.
5. Why It’s Better
superpowers encodes best practices into skills the AI must follow. This solves the “human linter” problem — best practices become system constraints instead of something you remind yourself about every time. That’s exactly what “Mandatory workflows, not suggestions” means.
More importantly, its design acknowledges the AI’s limitations and counters each one:
| AI limitation | Superpowers’ counter |
|---|---|
| Can’t truly understand the problem | brainstorming makes the human clarify and decide |
| Doesn’t know how to verify output | Verification loop first; red/green drives self-correction |
| Output is unstable | worktree isolation; zero-cost rollback when it breaks |
spec-kit’s underlying assumption is more optimistic — it presumes humans can write a good enough spec and the AI can execute it stably. That “assume the AI executes perfectly” design holds up when requirements are clear but breaks down when they’re fuzzy. superpowers is more pragmatic than assuming the AI executes perfectly.
6. Four Dimensions of R&D Effectiveness
From an architect’s view, boosting AI-assisted R&D isn’t a single-point problem — it’s systems engineering. I break it into four dimensions, which also clarifies where spec-kit and superpowers each sit.
6.1 Model Capability: Foundational, but Rarely the Bottleneck
Model capability is foundational but usually isn’t the bottleneck. The gap between strong and weak models is far smaller than the gap between “has good context” and “doesn’t.” Picking the right model and tuning prompts is entry-level stuff; the real differentiation is in the next three dimensions.
6.2 Architecture Optimization: AI-Friendly Code Structure
How well the AI handles code correlates strongly with how the code is organized. Worth noting: AI-friendly architecture is friendly to humans too — the two aren’t opposed.
AI-unfriendly architecture:
- A single file running thousands of lines, logic tangled together
- Circular dependencies between modules
- Business logic scattered everywhere
- Touch one spot, have to read ten files
AI-friendly architecture:
- Single responsibility; each module does one thing
- Clear, one-directional dependencies
- Cohesive business logic; blast radius of changes is contained
- The number of files a requirement touches is predictable
Architecture debt amplifies AI problems — code humans can’t untangle, the AI can’t either. On this dimension, neither spec-kit nor superpowers can save you; you have to lay the foundation yourself first.
6.3 Context Engineering: The Highest-ROI Direction
This is, in my view, the highest-ROI direction.
The AI’s hallucination problem is essentially insufficient or wrong context. It doesn’t know your business rules, technical constraints, or the traps you’ve stepped into. But note: context isn’t “the more the better” — what a strong model really needs is the “off-field info” that can’t be inferred from the code itself, not everything shoved in at once.
Layers of context engineering:
| Layer | Content | Form |
|---|---|---|
| Project | Tech stack, directory structure, coding conventions | CLAUDE.md / AGENTS.md |
| Module | Module responsibilities, core concepts, dependencies | Module README / Skills |
| Domain | Business rules, process definitions, glossary | Domain knowledge base / Skills |
| Task | Current requirement, acceptance criteria, edge cases | Brainstorming output |
superpowers’ skills system is essentially a context-engineering practice — encoding domain knowledge into AI-callable skills. spec-kit’s spec/plan/tasks are more like one-off task-level documents, lacking a mechanism to sediment knowledge into reusable, iterable skills.
6.4 Human-AI Interaction: The Overlooked Dimension
This one gets overlooked easily, but it hits the actual experience hard.
Cognitive load control. Human working memory is limited. Dumping 1000 lines of spec at once overwhelms people — they skim or skip, problems slip through, and rework piles up later. superpowers’ interactive confirmation is essentially controlling cognitive load per interaction — confirm one point at a time, so you can think it through. spec-kit’s one-shot giant doc does the opposite.
Feedback loop design. The AI needs feedback to converge; without it, it can only guess.
- ❌ No tests → the AI guesses right or wrong on pure luck
- ✅ With tests → the AI self-corrects via red/green
That’s why “verification loop first” matters so much.
A reflection on multi-agent parallelism. I buy the value of parallelism, but in practice: without sufficient context, multi-agent is pure token flamethrower 💸. Problems that need human intervention don’t auto-solve by stacking agents. The boundary and difference between AI and human still exist — you can’t brute-force it with compute, and you can’t fix it by bolting parallelism onto spec-kit either.
7. A Sober View
Any tech has limits, and superpowers is no exception. Some Hacker News critiques are worth chewing on.
On cognitive burden.
“I increasingly run into its limitations and find reverting to pre-LLM ways of working more robust, faster, mentally sustainable.”
Managing AI agents requires a new skill set. For simple tasks, the old way is probably faster. The key is recognizing which tasks suit AI collaboration.
On LLM’s fundamental limits.
“LLMs are incapable of stopping to ask clarifying questions… they do not have a true model of what is going on.”
Which is exactly why superpowers works — it turns “ask clarifying questions” into a mandatory flow via brainstorming, letting humans do the real understanding and deciding while the AI just executes. spec-kit bets this step on the human writing a good spec upfront, sidestepping the most critical dialogue in human-AI collaboration.
A pragmatic take.
“I’m using it as a tool, not using it to do my job for me. I use it to help me think, I don’t use it to think for me.”
The AI is a tool, not a replacement. Use it to help you think, not to think for you.
8. Summary
| Dimension | spec-kit | superpowers |
|---|---|---|
| Core assumption | Human can finish the design alone | Design needs AI assistance |
| Workflow | Waterfall (spec→plan→tasks→impl) | Interactive (brainstorm→plan→exec) |
| Human’s role | Doc writer | Decision maker |
| AI’s role | Executor | Guide + executor |
| Best practices | Templates and suggestions | Encoded as mandatory skills |
| Verification & rollback | Left to the user | Built-in verification loop + worktree isolation |
| Fit | Requirements are clear | Requirements are fuzzy (closer to reality) |
superpowers is more AI-native because it admits a reality — most of the time when we receive a requirement, we haven’t fully thought it through; we need the AI’s help to clarify it step by step. spec-kit’s spec-driven approach still has value when requirements are clear and dependencies are explicit, but it throws the hardest part — “thinking it through” — onto the human, and leaves the uncertainty of execution to the AI.
Use process to cover the AI’s gaps; use interaction to guide human thinking.
That’s where superpowers is genuinely better than spec-kit.
References
- GitHub: obra/superpowers — one of the most popular Claude Code plugins
- GitHub: github/spec-kit — Spec-Driven Development toolkit
- Jesse Vincent: Superpowers — author’s blog
- Cursor: Best practices for coding with agents
- Ethan Mollick: Claude Code and What Comes Next