For as long as coding agents have been able to edit files, the same complaint keeps surfacing: tell them what you want and they'll confidently build something adjacent to it, inventing features, ignoring scope, and leaving the actual requirement behind. An Ask HN from August put it plainly: "coding agents still improvise code that doesn't fall under the user's requirements all the time. Did we all just collectively decide that /plan mode was enough?"
OpenSpec is Fission AI's answer to that question: a lightweight, MIT-licensed spec layer that sits on top of whatever coding assistant you already use. It's having a moment. The repo sits at about 69.5k stars and was still on GitHub's trending page when I checked. A Hacker News thread posted two days ago pulled 197 points and 98 comments in that span, with people calling OpenSpec both the most productive way they've worked with LLMs and a pile of ceremony. Both camps are worth taking seriously.
What it is
OpenSpec is not another agent harness or IDE. It's a CLI plus a set of agent skills that teach your existing assistant (Claude Code, Cursor, Codex, Copilot, and 30+ tools in all, per the README) to produce a small set of planning documents before touching code. Setup is two terminal commands:
npm install -g @fission-ai/openspec@latest # requires Node.js 20.19.0+
cd your-project && openspec initnpm install -g @fission-ai/openspec@latest # requires Node.js 20.19.0+
cd your-project && openspec initopenspec init drops skills into .claude/skills/ (or the equivalent for your tool) that the assistant auto-detects. After that you mostly live in chat. The driving commands are slash commands like /opsx:propose, though the exact spelling varies by editor: /opsx-propose in Cursor and GitHub Copilot, @opsx-propose in Amazon Q, $openspec-propose in Codex.
The loop
The core flow, from the getting-started docs:
/opsx:explore optional thinking partner, reads your code and sharpens the idea
/opsx:propose AI drafts the plan; you review it before any code exists
/opsx:apply AI implements against the tasks, checking them off
/opsx:sync merge the change's delta specs into the main specs (optional)
/opsx:archive file the change away in openspec/changes/archive//opsx:explore optional thinking partner, reads your code and sharpens the idea
/opsx:propose AI drafts the plan; you review it before any code exists
/opsx:apply AI implements against the tasks, checking them off
/opsx:sync merge the change's delta specs into the main specs (optional)
/opsx:archive file the change away in openspec/changes/archive/Each change gets its own folder under openspec/changes/ with four artifacts: proposal.md (the why and what), design.md (the how), tasks.md (a checkbox checklist), and specs/, the delta specs. The delta spec is the interesting design idea. Instead of maintaining one enormous document, each change states only what differs, under ## ADDED, ## MODIFIED, and ## REMOVED requirement headings: small "The system MUST/SHALL ..." statements, each with concrete GIVEN/WHEN/THEN scenarios. On archive, ADDED requirements are appended to the main corpus in openspec/specs/, MODIFIED ones replace their predecessors, and REMOVED ones disappear. The spec corpus is supposed to stay honest about what the system actually does, and the change history stays in openspec/changes/archive/.
On positioning, the README compares itself against GitHub's Spec Kit (heavyweight, rigid phase gates, Python setup) and AWS's Kiro (which locks you into its IDE and Claude models). OpenSpec's pitch is that it works with the tools you already have and adds no vendor lock-in.
What's new: actions, not phases
The recent rebuild is why OpenSpec is worth another look right now. The OPSX workflow doc describes the old flow as locked down: planning instructions hardcoded in TypeScript, one big command creating everything at once, no way to go back. The new workflow is schema-driven. A schema.yaml plus markdown templates you can edit, with artifacts arranged as a dependency graph where each dependency is an enabler rather than a phase gate. You can create artifacts one at a time, revise the design mid-implementation, and let /opsx:apply pick up where you left off. Don't like the default schema? openspec schema init and openspec schema fork spec-driven my-workflow let you define your own.
There's also a beta called Stores: keep the openspec/ directory in its own repo, shared by git push, so a plan for a feature that spans three codebases lives in one place every coding agent can read. The README's framing: cross-repo features, shared requirements owned by a platform team, plan-before-code on shared infrastructure.
The debate it's kicked off
The HN thread is where this gets interesting, because the disagreement is informative. On the pro side, a user running a custom agent fleet said their "planner agent uses OpenSpec to generate the plan. Then turns the tasks into a ticket graph. It works fairly well, and it is definitely less heavy than SpecKit." Another called it "easily my favorite spec driven development framework" and said it was "the most productive way to work with LLMs for larger tasks."
The criticism is about drift and ceremony:
I've used OpenSpec extensively on two large pieces of software... Recently, I've completely ditched the specification part. I found they just weren't useful over the longer term. I used an LLM to assess in both directions whether the code matched the specs... On both software projects this came out with huge divergence from spec to code.
That user kept the process, proposal, review, implement, review, and dropped the long-lived specs, a split that showed up again and again. Others objected to the paperwork ("always slop, filled with the all the tells of AI writing"), made the obvious 90s comparison ("how this stuff is any different from the 90's let's use UML for code gen"), and asked for evidence that it works at all ("ideally backed by some benchmarks"). A maintainer replied in-thread, conceding the experience needs to get "a lot more succinct and iterative."
The verdict
OpenSpec is a discipline layer, not a magic wand. What it does well is front-load alignment: you and the agent agree on the shape of a change before it writes anything, and the artifacts give the agent something stable to work from across context resets. Even the skeptics tended to keep that part. What's contested is the idea of a long-lived spec corpus; teams that try to keep one perfect spec forever will fight drift, while teams that treat each change as a short-lived contract (propose, review, implement, review, archive) seem to get real mileage.
The schema-driven rebuild and 30+ tool support are why it could outlast the last round of spec tooling. Whether the ceremony pays for itself is a per-team question; the thread's skeptics asked for benchmarks, and none were linked in the discussion. But if your current agent flow is one giant prompt and a prayer, an afternoon with /opsx:explore is a cheap experiment.