OpenSpec
The spec framework for building the right thing and building it right
About OpenSpec
OpenSpec is a lightweight, configurable framework for writing and managing software specifications so that coding agents build what you meant rather than what you typed. It installs as a single npm package and adds a set of slash commands to the agent you already use. Instead of prompting an agent straight into your codebase, you run it through an explicit sequence: explore the problem, propose a change, apply it, verify it against the spec, then archive the record. The point is to keep you, your team and the agent aligned as a piece of work evolves, and to leave behind specs that describe the system as it actually is. Fission, the company behind it, claims more than 265,000 developers use it monthly and that a new spec is created every two seconds; those are the vendor's own figures, but the GitHub repository is past 69,000 stars, so the adoption is not imaginary.
The framework is deliberately agent-agnostic. The compatibility list on the homepage names Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI and OpenCode and then adds "33 more". Everything it produces is plain markdown in your repository: a proposal, a specs directory, a design document and a task list per change. There is no server, no account and no hosted service; the CLI is MIT licensed and the site publishes no paid tier. The natural comparison is spec-kit from GitHub, which this directory also lists. OpenSpec is now the larger of the two by stars and is vendor-neutral, but the two overlap heavily and the site does not make a case for one over the other, so try both on a small change before adopting either.
You install the CLI globally with npm, pnpm, bun, yarn or nix and then work through the five stages from inside your agent, using the /opsx slash commands the site documents. The explore stage maps the problem and reads the codebase. Propose drafts proposal.md, the specs, design.md and tasks.md for the change, which is where you and the agent argue about requirements before any code is written. Apply has the agent implement the tasks from that specification. Verify checks the implementation back against the spec and reports drift. Archive closes the change and files its record, so the spec directory becomes a history of what was decided and why. Because the artefacts are markdown in git, they are reviewed in pull requests alongside the code and survive a change of agent or model.
- •Five-Stage Workflow - explore, propose, apply, verify and archive as slash commands, so the discipline is a command rather than a memory
- •Works With Nearly Every Agent - Claude Code, Codex, Cursor, Copilot, Gemini CLI, OpenCode and 33 more listed by the vendor
- •Specs as Files - Proposals, specs, designs and task lists are markdown in the repository, reviewable in a PR and portable between tools
- •Verification Against the Spec - A dedicated verify step compares what was built with what was specified and surfaces drift
- •Nothing to Host - No server, no account, no telemetry dashboard; the whole thing is a CLI and a directory
- •MIT Licensed - Free, forkable and inspectable, with the changelog and roadmap on the site
Developers and teams who have noticed that agent output is only as good as the brief and want a repeatable way to write the brief, especially for changes that touch several files or several people. It fits teams that already review in pull requests and want the requirements in the same place as the diff. It is a poor fit for quick one-line fixes, where five stages are ceremony, and for anyone who wants a graphical tool; OpenSpec is text all the way down. If your organisation is standardised on GitHub tooling, spec-kit covers similar ground and may integrate more naturally, so weigh the two rather than assuming the larger star count settles it.
