Who OpenSpec is for#
Solo developers using AI coding assistants on personal projects
OpenSpec keeps a solo developer and their AI aligned on a single repo. Instead of accumulating vague chat history, each feature gets a reviewable spec that the AI follows during implementation. The `/opsx:verify` step confirms the finished code matches what was planned.
Skip if:
If your projects are small scripts or one-off utilities where you interact with the AI only once per feature, the overhead of creating a spec folder outweighs the benefit. OpenSpec earns its place on projects with multiple iterations or significant scope.
Engineering teams building features across multiple repos
Stores (beta) let teams publish a shared planning repo that every coding agent in every affected codebase can read. One change plan covers the API server, web frontend, and shared library, with platform teams owning the specs and product teams referencing them without duplication.
Skip if:
If all your features live in a monorepo, the cross-repo benefit of Stores is minimal. The core change-folder workflow still applies, but you will not need the Stores setup.
Teams rolling out AI coding tools who need consistent output
When a team is adopting AI coding assistants, OpenSpec provides the shared contract that makes AI output reviewable before code is written. The proposal and spec review step creates a natural checkpoint that fits existing code-review culture without requiring new tooling beyond the CLI.
Skip if:
If your team already has a well-established spec process that coding agents can read directly, and you are satisfied with output consistency, adding another spec layer may create redundancy.
The problem it solves#
AI coding assistants are powerful but unreliable without a shared spec. When requirements live only in chat history, every conversation restarts from scratch, agents drift off-target mid-feature, and the final code often reflects what the AI guessed rather than what the team agreed. Code reviews become requirement debates rather than implementation checks.
The problem is especially sharp on multi-repo teams. A feature that touches an API server, a web frontend, and a shared library has no natural home for the plan. Requirements set in one repo's chat history are invisible to agents working in the others. By the time the code lands, each agent has made different assumptions, and reconciling them is expensive.
How it solves it#
Slash-command workflow for any AI coding assistant
OpenSpec ships slash commands (/opsx:explore, /opsx:propose, /opsx:apply, /opsx:verify, /opsx:archive) that work inside 30+ AI coding tools including Claude Code, Cursor, GitHub Copilot, and Gemini CLI. The same workflow runs in every tool; `openspec init` prints the correct invocation syntax for whatever assistant you use.
Structured change folders with proposal, specs, design, and tasks
Every change gets its own folder under `openspec/changes/` with four artifacts: `proposal.md` (why), `specs/` (requirements and test scenarios in plain markdown), `design.md` (technical approach), and `tasks.md` (implementation checklist). The AI drafts all four; you review the plan before any code is written.
Verify step that checks implementation against the spec
`/opsx:verify` runs after implementation to check whether the code matches what the spec described. This gives teams a way to confirm the AI delivered what was agreed, and surfaces drift early while changes are still cheap to fix.
Stores for cross-repo team planning (beta)
Stores host an `openspec/` planning folder in a dedicated repo, shared across every codebase in the feature. One change plan, one source of truth, accessible by git clone. Platform teams can publish specs; product teams reference them read-only right where their coding agent reads them. Stores are in beta as of the current release.
Plain-markdown spec format, no proprietary syntax
Specs are written in plain markdown using requirement and scenario blocks. No custom schema, no DSL to learn. Because specs are text files committed to the repo, they are searchable, diffable, and readable by any coding agent without tool-specific configuration.
Strengths and trade-offs#
Strengths
- Works with 30+ AI coding assistants, no vendor lock-inOpenSpec's slash commands run inside Claude Code, Cursor, GitHub Copilot, Gemini CLI, Amazon Q Developer, and 25+ more tools. Unlike Amazon Kiro, which is tied to AWS's IDE and limited to its supported models, OpenSpec integrates into whatever coding environment you already use and works with any model the assistant supports.
- MIT license, free to use and modify without restrictionsThe MIT license means you can run OpenSpec commercially, fork it, and modify it without paying licensing fees or asking permission. Specs are stored as files in your own repo, so there is no vendor to cut access, change pricing, or sunset the service.
- Brownfield-first design, works on existing codebasesOpenSpec is designed for existing projects. `openspec init` adds a lightweight `openspec/` folder to any codebase without touching existing code, and `/opsx:explore` reads your current code to build context before any spec is written. The README describes the philosophy as 'built for brownfield not just greenfield'.
- Scales from solo projects to multi-repo enterprise teamsThe core workflow (create change folder, review spec, implement, verify, archive) requires no configuration and works on any project size. Stores (beta) extend the same mental model to cross-repo team planning. OpenSpec was itself built using OpenSpec on a multi-repo codebase, demonstrating the workflow at production scale.
Trade-offs
- -Requires Node.js 20.19 or higherThe CLI requires Node.js 20.19.0 or higher, which rules out environments still on Node 18 LTS or earlier. Projects locked to older Node versions will need to upgrade their runtime before adopting OpenSpec.
- -Stores (cross-repo planning) is in betaThe Stores feature, which enables shared planning repos for multi-team, multi-repo features, is currently in beta. Beta status means the API surface may change between releases. Teams depending on Stores for production workflows should monitor the changelog and expect some adjustment during upgrades.
- -Telemetry is opt-out by defaultOpenSpec collects command names and version information by default to understand usage patterns. No arguments, paths, or content are sent, but the telemetry is opt-out rather than opt-in. Disable it with `openspec config set telemetry.enabled false` or the `OPENSPEC_TELEMETRY=0` environment variable.
OpenSpec vs alternatives#
OpenSpec vs Amazon Kiro
Both OpenSpec and Kiro add a spec layer to AI coding workflows, but they take opposite approaches to integration. Kiro is a proprietary AWS IDE with spec-driven development built in; OpenSpec is a CLI tool and file format that works inside the editors and AI assistants you already use.
| Feature | OpenSpec | Amazon Kiro |
|---|---|---|
| License | MIT | Proprietary |
| Self-hosting | Yes (files in your repo) | No (managed by AWS) |
| Editor integration | 30+ AI tools via slash commands | Kiro IDE only |
| Model flexibility | Any model your assistant supports | Limited to supported models |
| Spec storage | Plain markdown in your repo | Managed by Kiro |
| Pricing | Free | Proprietary pricing |
OpenSpec is the better choice when you want to keep using your current editor and AI assistant rather than switching to a new IDE. Because specs are plain markdown in your git repo, they are portable: switch tools, change teams, or stop using OpenSpec entirely, and the files stay.
Kiro is worth considering if you are already embedded in the AWS ecosystem and prefer a managed experience where the spec tooling, IDE, and AI are integrated by the same vendor. Teams that value a single vendor for their entire AI coding stack, and are comfortable with Kiro's supported model set, will find less friction with Kiro's approach.
Quick start#
Install OpenSpec globally with npm, then run init inside your project directory.
```bash
npm install -g @fission-ai/openspec@latest
openspec init
```What it's built on#
- Languages
- JavaScriptTypeScript
- Frameworks
- Next.jsReact
FAQ#
Is OpenSpec free to use?
Yes. OpenSpec is MIT licensed. The CLI, spec format, and all commands are free to run commercially and on any project without licensing fees. The only external dependency is Node.js 20.19 or higher.
Which AI coding assistants does OpenSpec support?
OpenSpec supports 30+ AI coding assistants including Claude Code, Cursor, GitHub Copilot, Gemini CLI, Amazon Q Developer, Codex, and Cline. Run openspec init in your project and it prints the correct slash-command syntax for the tools you selected.
What is spec-driven development (SDD)?
Spec-driven development is a workflow where you write and review the requirements, design, and implementation plan before any code is written. OpenSpec structures this with a change folder per feature, a review step where the developer approves the AI's plan, and a verify step after implementation confirms the code matches the spec.
How is OpenSpec different from Amazon Kiro?
Kiro is a proprietary AWS IDE with a built-in spec workflow, limited to its supported models and environments. OpenSpec is MIT licensed and works inside any of 30+ AI coding tools you already use. Kiro is a better fit for teams already inside the AWS ecosystem; OpenSpec is better for teams that want model and tool flexibility.
Does OpenSpec store spec files in the cloud?
No. Spec files are plain markdown stored in your repository under openspec/. They travel with your code via git, with no cloud account or server required. The Stores feature (beta) uses a separate git repository for cross-repo sharing, but this is still a standard git repo you control.
Similar open-source tools#
rakazo
AI teammates you own: your keys, your model, your machine.
tradingview-mcp
MCP bridge for AI-assisted TradingView chart analysis
cli
Official Lark/Feishu CLI with 200+ commands and AI Agent Skills
Multica
Assign GitHub issues to AI coding agents. They run on your machine.
opendisplay
Turn any iPhone, iPad, or spare Mac into a free second Mac monitor
Jean
A dev environment for running AI agents in isolated git worktrees