The problem OpenSpec is built around is one I’d bet most people reading this have hit personally: you describe a feature to a coding agent, it goes off and builds something, and only once you’re reading the diff do you realize it built the wrong thing — not broken, just not what you actually meant. By then you’ve burned the time it took to generate 400 lines of code to find out.
OpenSpec’s fix is almost deliberately unglamorous: make the agent write a short plan first, in plain text you both look at, before any code gets touched. The workflow has four steps, each run as a slash command inside your AI assistant’s own chat, not the terminal: /opsx:propose has the agent draft a spec and task list for the change you described; you read it and catch a wrong assumption while it’s one paragraph, not hundreds of lines; /opsx:apply has the agent actually build it against that agreed plan; /opsx:archive merges the result into a permanent spec file and files the change away with its history intact. There’s also /opsx:explore, a lower-stakes mode for when you’re not sure what you want yet — it reads your existing code and thinks through options with you before anything gets proposed at all.
The specific mechanic that makes this scale past a single change is what the project calls delta specs: instead of restating an entire feature’s requirements every time, a change only describes what’s actually different — “add two-factor authentication,” not the whole auth system rewritten in prose. That keeps specs from becoming unwieldy on any codebase old enough to have accumulated real complexity, which is exactly where hand-wavy prompting tends to fall apart the hardest.
It’s built to sit underneath whatever agent you’re already using rather than replace it — over 30 supported tools as of the latest release, including Claude Code, Codex, Cursor, Hermes Agent, and Kimi Code, each getting setup files written in whatever format that specific tool expects. There’s also a newer, still-beta “Stores” feature for teams: specs living in their own shared repo, so a platform team can own the requirements and product teams can reference them read-only from whatever repo their own agent is working in, instead of the requirements drifting into a wiki nobody keeps current.
None of this is a new idea in software engineering generally — “write the spec before you write the code” predates AI agents by decades. What’s genuinely new is applying it specifically to the failure mode agents introduce: not that requirements are hard to write, but that an agent will confidently build the wrong thing fast enough that you don’t notice until it’s already done. Making that agreement a required, lightweight step rather than something you only do if you remember to is a small process change with an outsized effect on how much rework you end up doing.
npm install -g @fission-ai/openspec@latest
cd your-project && openspec init
