Spec-driven development for AI coding assistants.
Follow @0xTab on X for updates · Join the OpenSpec Discord for help and questions.
🧪 New: OPSX Workflow — schema-driven, hackable, fluid. Iterate on workflows without code changes.
OpenSpec aligns humans and AI coding assistants with spec-driven development so you agree on what to build before any code is written. No API keys required.
AI coding assistants are powerful but unpredictable when requirements live in chat history. OpenSpec adds a lightweight specification workflow that locks intent before implementation, giving you deterministic, reviewable outputs.
Key outcomes:
openspec/specs/ (current truth) and openspec/changes/ (proposed updates). This keeps diffs explicit and manageable across features.See the full comparison in How OpenSpec Compares.
┌────────────────────┐ │ Draft Change │ │ Proposal │ └────────┬───────────┘ │ share intent with your AI ▼ ┌────────────────────┐ │ Review & Align │ │ (edit specs/tasks) │◀──── feedback loop ──────┐ └────────┬───────────┘ │ │ approved plan │ ▼ │ ┌────────────────────┐ │ │ Implement Tasks │──────────────────────────┘ │ (AI writes code) │ └────────┬───────────┘ │ ship the change ▼ ┌────────────────────┐ │ Archive & Update │ │ Specs (source) │ └────────────────────┘ 1. Draft a change proposal that captures the spec updates you want. 2. Review the proposal with your AI assistant until everyone agrees. 3. Implement tasks that reference the agreed specs. 4. Archive the change to merge the approved updates back into the source-of-truth specs.
These tools have built-in OpenSpec commands. Select the OpenSpec integration when prompted.
| Tool | Commands |
|---|---|
| Amazon Q Developer | @openspec-proposal, @openspec-apply, @openspec-archive (.amazonq/prompts/) |
| Antigravity | /openspec-proposal, /openspec-apply, /openspec-archive (.agent/workflows/) |
| Auggie (Augment CLI) | /openspec-proposal, /openspec-apply, /openspec-archive (.augment/commands/) |
| Claude Code | /openspec:proposal, /openspec:apply, /openspec:archive |
| Cline | Workflows in .clinerules/workflows/ directory (.clinerules/workflows/openspec-*.md) |
| CodeBuddy Code (CLI) | /openspec:proposal, /openspec:apply, /openspec:archive (.codebuddy/commands/) — see docs |
| Codex | /openspec-proposal, /openspec-apply, /openspec-archive (global: ~/.codex/prompts, auto-installed) |
| Continue | /openspec-proposal, /openspec-apply, /openspec-archive (.continue/prompts/) |
| CoStrict | /openspec-proposal, /openspec-apply, /openspec-archive (.cospec/openspec/commands/) — see docs |
| Crush | /openspec-proposal, /openspec-apply, /openspec-archive (.crush/commands/openspec/) |
| Cursor | /openspec-proposal, /openspec-apply, /openspec-archive |
| Factory Droid | /openspec-proposal, /openspec-apply, /openspec-archive (.factory/commands/) |
| Gemini CLI | /openspec:proposal, /openspec:apply, /openspec:archive (.gemini/commands/openspec/) |
| GitHub Copilot | /openspec-proposal, /openspec-apply, /openspec-archive (.github/prompts/) |
| iFlow (iflow-cli) | /openspec-proposal, /openspec-apply, /openspec-archive (.iflow/commands/) |
| Kilo Code | /openspec-proposal.md, /openspec-apply.md, /openspec-archive.md (.kilocode/workflows/) |
| OpenCode | /openspec-proposal, /openspec-apply, /openspec-archive |
| Qoder | /openspec:proposal, /openspec:apply, /openspec:archive (.qoder/commands/openspec/) — see docs |
| Qwen Code | /openspec-proposal, /openspec-apply, /openspec-archive (.qwen/commands/) |
| RooCode | /openspec-proposal, /openspec-apply, /openspec-archive (.roo/commands/) |
| Windsurf | /openspec-proposal, /openspec-apply, /openspec-archive (.windsurf/workflows/) |
Kilo Code discovers team workflows automatically. Save the generated files under .kilocode/workflows/ and trigger them from the command palette with /openspec-proposal.md, /openspec-apply.md, or /openspec-archive.md.
These tools automatically read workflow instructions from openspec/AGENTS.md. Ask them to follow the OpenSpec workflow if they need a reminder. Learn more about the AGENTS.md convention.
| Tools |
|---|
| Amp • Jules • Others |
node --versionOption A: Using npm
npm install -g @fission-ai/openspec@latest
Verify installation:
openspec --version
Option B: Using Nix (NixOS and Nix package manager)
Run OpenSpec directly without installation:
nix run github:Fission-AI/OpenSpec -- init
Or install to your profile:
nix profile install github:Fission-AI/OpenSpec
Or add to your development environment in flake.nix:
{ inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; openspec.url = "github:Fission-AI/OpenSpec"; }; outputs = { nixpkgs, openspec, ... }: { devShells.x86_64-linux.default = nixpkgs.legacyPackages.x86_64-linux.mkShell { buildInputs = [ openspec.packages.x86_64-linux.default ]; }; }; }
Verify installation:
openspec --version
Navigate to your project directory:
cd my-project
Run the initialization:
openspec init
What happens during initialization:
AGENTS.md stubAGENTS.md hand-off at the project rootopenspec/ directory structure is created in your projectAfter setup:
/openspec workflows without additional configurationopenspec list to verify the setup and view any active changesAfter openspec init completes, you'll receive a suggested prompt to help populate your project context:
Populate your project context: "Please read openspec/project.md and help me fill it out with details about my project, tech stack, and conventions"
Use openspec/project.md to define project-level conventions, standards, architectural patterns, and other guidelines that should be followed across all changes.
Here's a real example showing the complete OpenSpec workflow. This works with any AI tool. Those with native slash commands will recognize the shortcuts automatically.
Start by asking your AI to create a change proposal:
You: Create an OpenSpec change proposal for adding profile search filters by role and team (Shortcut for tools with slash commands: /openspec:proposal Add profile search filters) AI: I'll create an OpenSpec change proposal for profile filters. *Scaffolds openspec/changes/add-profile-filters/ with proposal.md, tasks.md, spec deltas.*
Check that the change was created correctly and review the proposal:
$ openspec list # Confirm the change folder exists
$ openspec validate add-profile-filters # Validate spec formatting
$ openspec show add-profile-filters # Review proposal, tasks, and spec delta
Iterate on the specifications until they match your needs:
You: Can you add acceptance criteria for the role and team filters? AI: I'll update the spec delta with scenarios for role and team filters. *Edits openspec/changes/add-profile-filters/specs/profile/spec.md and tasks.md.*
Once specs look good, start implementation:
You: The specs look good. Let's implement this change. (Shortcut for tools with slash commands: /openspec:apply add-profile-filters) AI: I'll work through the tasks in the add-profile-filters change. *Implements tasks from openspec/changes/add-profile-filters/tasks.md* *Marks tasks complete: Task 1.1 ✓, Task 1.2 ✓, Task 2.1 ✓...*
After implementation is complete, archive the change:
AI: All tasks are complete. The implementation is ready. You: Please archive the change (Shortcut for tools with slash commands: /openspec:archive add-profile-filters) AI: I'll archive the add-profile-filters change. *Runs: openspec archive add-profile-filters --yes* ✓ Change archived successfully. Specs updated. Ready for the next feature!
Or run the command yourself in terminal:
$ openspec archive add-profile-filters --yes # Archive the completed change without prompts
Note: Tools with native slash commands (Claude Code, CodeBuddy, Cursor, Codex, Qoder, RooCode) can use the shortcuts shown. All other tools work with natural language requests to "create an OpenSpec proposal", "apply the OpenSpec change", or "archive the change".
openspec list # View active change folders
openspec view # Interactive dashboard of specs and changes
openspec show <change> # Display change details (proposal, tasks, spec updates)
openspec validate <change> # Check spec formatting and structure
openspec archive <change> [--yes|-y] # Move a completed change into archive/ (non-interactive with --yes)
When you ask your AI assistant to "add two-factor authentication", it creates:
openspec/ ├── specs/ │ └── auth/ │ └── spec.md # Current auth spec (if exists) └── changes/ └── add-2fa/ # AI creates this entire structure ├── proposal.md # Why and what changes ├── tasks.md # Implementation checklist ├── design.md # Technical decisions (optional) └── specs/ └── auth/ └── spec.md # Delta showing additions
# Auth Specification
## Purpose
Authentication and session management.
## Requirements
### Requirement: User Authentication
The system SHALL issue a JWT on successful login.
#### Scenario: Valid credentials
- WHEN a user submits valid credentials
- THEN a JWT is returned
# Delta for Auth
## ADDED Requirements
### Requirement: Two-Factor Authentication
The system MUST require a second factor during login.
#### Scenario: OTP required
- WHEN a user submits valid credentials
- THEN an OTP challenge is required
## 1. Database Setup
- [ ] 1.1 Add OTP secret column to users table
- [ ] 1.2 Create OTP verification logs table
## 2. Backend Implementation
- [ ] 2.1 Add OTP generation endpoint
- [ ] 2.2 Modify login flow to require OTP
- [ ] 2.3 Add OTP verification endpoint
## 3. Frontend Updates
- [ ] 3.1 Create OTP input component
- [ ] 3.2 Update login flow UI
Important: You don't create these files manually. Your AI assistant generates them based on your requirements and the existing codebase.
Deltas are "patches" that show how specs change:
## ADDED Requirements - New capabilities## MODIFIED Requirements - Changed behavior (include complete updated text)## REMOVED Requirements - Deprecated featuresFormat requirements:
### Requirement: <name> for headers#### Scenario: blockOpenSpec’s two-folder model (openspec/specs/ for the current truth, openspec/changes/ for proposed updates) keeps state and diffs separate. This scales when you modify existing features or touch multiple specs. spec-kit is strong for greenfield/0→1 but provides less structure for cross-spec updates and evolving features.
OpenSpec groups every change for a feature in one folder (openspec/changes/feature-name/), making it easy to track related specs, tasks, and designs together. Kiro spreads updates across multiple spec folders, which can make feature tracking harder.
Without specs, AI coding assistants generate code from vague prompts, often missing requirements or adding unwanted features. OpenSpec brings predictability by agreeing on the desired behavior before any code is written.
openspec init in your repo.Run openspec update whenever someone switches tools so your agents pick up the latest instructions and slash-command bindings.
npm install -g @fission-ai/openspec@latest
openspec update inside each project to regenerate AI guidance and ensure the latest slash commands are active.Why this exists:
What's different:
You can always go back: proposal ──→ specs ──→ design ──→ tasks ──→ implement ▲ ▲ ▲ │ └───────────┴──────────┴────────────────────┘
| Command | What it does |
|---|---|
/opsx:new | Start a new change |
/opsx:continue | Create the next artifact (based on what's ready) |
/opsx:ff | Fast-forward (all planning artifacts at once) |
/opsx:apply | Implement tasks, updating artifacts as needed |
/opsx:archive | Archive when done |
Setup: openspec experimental
OPENSPEC_TELEMETRY=0)We collect only command names and version to understand usage patterns. No arguments, paths, content, or PII. Automatically disabled in CI.
Opt-out: export OPENSPEC_TELEMETRY=0 or export DO_NOT_TRACK=1
pnpm installpnpm run buildpnpm testpnpm run dev or pnpm run dev:clitype(scope): subjectSee MAINTAINERS.md for the list of core maintainers and advisors who help guide the project.
MIT