I was predisposed to like OpenSpec before I installed it, and I want to disclose that bias upfront, because it's the most useful thing in this review. My Claude Code workflow has enforced a plan-implement-verify discipline for a long time: every non-trivial task starts by naming the domain it touches, the existing pattern it copies, and the exact commands that will verify it. OpenSpec is that discipline turned into files and tooling. So my verdict isn't "this framework taught me spec-driven development." It's sharper: OpenSpec is what happens when the planning discipline you should already have stops living in your head and starts living in your repo, and the difference that makes is bigger than I expected.
What OpenSpec is, concretely
OpenSpec is an open-source spec-driven development framework from Fission-AI, shipped as the npm package @fission-ai/openspec. Install it globally, run openspec init in a project, pick your AI assistant, and it wires slash commands into your tool of choice; Claude Code, Cursor, Codex, Copilot, and a long list of others are supported. The core loop runs through /opsx commands in your assistant's chat: /opsx:explore to surface unknowns before committing to a direction, /opsx:propose to generate the change's proposal, design, spec, and task files, /opsx:apply to implement against them, and /opsx:archive to fold the shipped change back into the living spec. An expanded command set adds finer control: /opsx:new, /opsx:continue for slice-by-slice progress, /opsx:ff to fast-forward the remaining planning steps, /opsx:verify to validate implementation against spec, and /opsx:bulk-archive for end-of-sprint cleanup.
The idea underneath is blunt: the specification is the artifact, the code is the compile target. Every feature exists as reviewable markdown in an openspec/ folder before implementation starts, and that markdown is what your AI assistant executes against.
The two design decisions that earn the tool its slot
Plenty of frameworks make you write specs. Two choices make OpenSpec's version actually livable.
Specs are deltas, not documents. A proposal isn't a fresh spec; it's a change against the existing one, explicitly tagging additions, modifications, and removals. When the change ships, /opsx:archive merges the deltas into the master spec. This is the feature that makes the tool usable on brownfield codebases, which is to say, on real work. You never face the absurd task of speccing a mature application from scratch. You describe what's changing, and the living spec accretes.
The spec describes behavior, not implementation. OpenSpec specs are functional scenarios, what the user can see and do, not "the controller calls the repository." That shape is what lets a spec survive refactors. When persistence details change, the spec stays true, because it was never about persistence. Anyone who has watched a README rot in eighteen months understands why this matters: documentation drifts exactly as fast as it describes implementation.
The archive step deserves special emphasis because it's the one people skip and the one that carries the compounding value. A maintained master spec is context that loads itself. Point a fresh Claude Code session at the spec folder and it starts already knowing how the system behaves, without the ritual re-explanation that opens most sessions. Every team I've seen abandon spec-driven development abandoned it because specs drifted from code. Archive is the anti-drift mechanism. Treat it as part of "done."
How it fits a workflow that already plans
Here's the practitioner's detail I haven't seen other reviews cover: how OpenSpec interacts with planning discipline you already run. My existing setup uses skills that force brainstorming before creative work and written plans before implementation, and my project instructions demand a stated verify step per task. The overlap question is real: is OpenSpec redundant with that?
No, and the distinction is durability. My plan-mode sessions produce excellent plans that evaporate when the session ends. The plan lives in a context window, dies with it, and the next session reconstructs intent from code and memory files. OpenSpec's plans are files in git. They get diffed in PRs, survive sessions, and archive into a permanent behavioral record. The planning quality is similar; the half-life is completely different.
The layering with enforcement tools also matters. Spec-driven frameworks decide what to build; SDLC-discipline tools like the Superpowers plugin enforce how it gets built, tests-first and reviewed. They stack cleanly: OpenSpec writes the contract, the TDD layer makes the implementation honest against it, and git review catches the rest. Confusing these layers is how people end up comparing tools that were never alternatives, a mistake I flagged from the other side in my advanced workflow guide.
On my Laravel work, the fit is natural. A spec's functional scenarios map almost one-to-one onto feature tests, the task breakdown respects the conventions my instruction file already encodes, and the verify step gets a named home instead of relying on my remembering to demand it. The /opsx:explore phase has become the part I'd defend hardest: run before any change I can't explain in one unqualified sentence, it surfaces the hidden dependency or the ambiguous requirement while surfacing it is still cheap. Exploration before proposal is the same move as interviewing before implementing, and it prevents the most expensive class of AI-coding failure, a confident sprint in the wrong direction.
Where it's overhead, honestly
Trivial changes. A typo fix does not need a proposal folder. Fission-AI says as much, but newcomers ritualize every change through the flow anyway and end up with a graveyard of ceremony. My threshold: if the change wouldn't need a plan-mode session, it doesn't need a spec.
True exploration. When I genuinely don't know what I'm building, prototyping first and speccing retroactively works better than pretending to spec a design that doesn't exist yet. OpenSpec tolerates this flow fine; write the spec after the sketch, archive it as the founding proposal.
Brownfield onboarding costs real effort. Dropping OpenSpec onto a legacy codebase and expecting it to infer an accurate master spec will disappoint you. Inference from unprincipled code produces fuzzy specs. The workable path is writing the master spec for core flows by hand, with the assistant drafting and you correcting, then going delta-based for everything new. Budget genuine hours for it, the same way you'd budget for bringing continuity to multi-session work on any long-lived project.
The ecosystem is small. Docs are solid and the release cadence is healthy, but the tutorial-and-integration depth of bigger ecosystems isn't there yet. If you need something the framework doesn't do, you're building it.
Should you adopt it?
Three honest filter questions. Do your features take more than a couple of hours of focused work? Do you return to projects after weeks away and pay a context-reload tax? Does your AI assistant perform better with an explicit contract than with turn-by-turn steering? Three yeses and OpenSpec pays for itself by the second feature. Three noes and it's ceremony you don't need.
The deeper shift it drove in my own work is about where the bottleneck lives. Once specs are explicit and the apply phase is reliable, execution stops being the constraint; spec quality becomes the constraint. That moves your time to the part of the work that genuinely requires human judgment, which is precisely the promise of the whole plan-first school of AI coding. Frameworks come and go. The bottleneck relocation is permanent.
Spec-driven development is one of the workflows I teach hands-on, alongside the rest of the agent-era engineering stack, in my AI School. If you'd rather learn the discipline once, properly, than reverse-engineer it from a dozen tool READMEs, that's where to start.
