Superpowers 6.0 vs spec‑kit: Is spec a Scaffold or the Sole Truth?

1. What Superpowers 6.0 Became

Superpowers is not a CLI tool but a collection of markdown‑based skills plus a bootstrap snippet injected at session start. Its official README describes it as a "complete software development methodology for your coding agents". The rewrite released on 2026‑06‑16 (v6.0.0, latest v6.0.3) is framed as a subagent-driven-development overhaul that makes review cheaper, stricter, and harder to game .

Old mechanism : each task was reviewed by two reviewers (spec compliance and code quality) under a controller that arbitrarily chose the model and severity, which the release notes called "expensive and easy to game".

New mechanism : the controller’s discretionary power is removed. Reviewers are reduced to one, but the reviewer must provide evidence (file + line number) and cannot be overruled by a controller. Diff data is passed via files ( task-brief → task‑N‑report.md) instead of being embedded in the prompt, saving context cost. A .superpowers/sdd/ progress ledger replaces the previous .git/ location to survive context loss.

Efficiency numbers from the project’s own evals claim Claude Code and Codex produce comparable quality at roughly 2× speed and 50 % fewer tokens , with the disclaimer that this does not hold for every harness or workload.

2. spec‑kit: Making Spec the Sole Truth

spec‑kit is an official GitHub‑maintained project (115 k stars, v0.11.6 as of 2026‑06‑24) heavily influenced by John Lam. Its manifesto in spec‑driven.md introduces the concept of Power Inversion : "Specifications don’t serve code—code serves specifications." The spec is treated as an executable artifact , eliminating the gap between spec and implementation.

The methodology redefines software activities:

Maintaining software = evolving the spec

Debugging = fixing the spec that generated faulty code

Refactoring = improving the spec for clarity

Spec‑kit enforces discipline through a nine‑article constitution (e.g., Article I Library‑First, Article III Test‑First Imperative, Article VII Simplicity, Article VIII Anti‑Abstraction, Article IX Integration‑First Testing) and a series of slash commands ( /speckit.constitution, /speckit.specify, /speckit.clarify, /speckit.plan, /speckit.tasks, /speckit.implement, /speckit.converge) that gate each phase.

3. Core Ontological Divergence

Both projects share surface traits (anti‑vibe coding, spec‑first, TDD, multi‑agent collaboration, evidence‑based decisions), yet they differ fundamentally on what a spec is:

Superpowers : spec = design document (markdown) that guides implementation; the final deliverable remains code.

spec‑kit : spec = executable artifact; code is merely a projection of the spec.

This ontological split drives distinct disciplinary injection points: Superpowers embeds rules in runtime skill commands; spec‑kit embeds rules in templates and document gatekeeping.

4. Can They Be Combined?

Source‑level analysis suggests theoretical complementarity but also three concrete tensions:

Format incompatibility : spec‑kit’s tasks.md follows its own template, while Superpowers expects a Global Constraints block and per‑task interfaces.

Trigger conflict : Superpowers forces skill execution via a bootstrap hook; spec‑kit requires explicit slash commands.

Execution overlap : Both provide an implement phase ( /speckit.implement vs subagent-driven-development) that cannot run concurrently.

Two plausible integration patterns emerge:

Pattern A : Use spec‑kit to generate structured specs ( spec.md, plan.md, tasks.md), then adapt them to Superpowers’ plan format and run the subagent-driven-development executor.

Pattern B : Run the entire workflow in Superpowers but manually inject spec‑kit’s constitution into the bootstrap to constrain brainstorming.

Both remain untested; practical adoption would likely hit format‑adaptation and trigger‑ordering hurdles.

5. Does Spec Still Matter as LLMs Get Stronger?

The projects’ own narratives argue that stronger models make spec‑driven development feasible: spec‑kit claims AI can reliably generate code from natural‑language specs, while Superpowers emphasizes "Process over guessing". Community sentiment (e.g., a 2026‑04 Chinese survey) echoes a "Process over Prompt" mantra.

The author’s personal analysis, however, treats these claims as project‑side positions, not industry consensus. He argues that the value of spec shifts from preventing model errors to preventing human ambiguity—spec becomes a tool for precise expression, which grows more valuable as models become capable enough to faithfully execute well‑defined specifications.

6. Summary

1) Superpowers 6.0 deepens execution‑time discipline by removing controller discretion, enforcing evidence‑backed reviews, and managing context cost via file‑based diff and a progress ledger.

2) The fundamental split with spec‑kit lies in the ontological status of spec: design input vs. executable product, leading to different enforcement mechanisms and making naïve combination non‑trivial.

3) As large models improve, spec‑driven methods are unlikely to disappear; their role migrates from guarding model output to aligning human intent, especially for complex systems where precise articulation is the primary bottleneck.