Fission-AI/OpenSpec

→ fluid not rigid
→ iterative not waterfall
→ easy not complex
→ built for brownfield not just greenfield
→ scalable from personal projects to enterprises

Follow @0xTab on X for updates · Join the OpenSpec Discord for help and questions.

See it in action

You: /opsx:explore
AI:  What would you like to explore?
You: I want dark mode but I'm not sure how to do it cleanly.
AI:  Let me look at your styling setup...
     Cleanest path here: CSS variables + a small theme context,
     with system-preference detection. No new dependencies. Scope it?
You: Yes, let's do it.
You: /opsx:propose add-dark-mode
AI:  Created openspec/changes/add-dark-mode/
     ✓ proposal.md — why we're doing this, what's changing
     ✓ specs/       — requirements and scenarios
     ✓ design.md    — technical approach
     ✓ tasks.md     — implementation checklist
     Ready for implementation!
You: /opsx:apply
AI:  Implementing tasks...
     ✓ 1.1 Add theme context provider
     ✓ 1.2 Create toggle component
     ✓ 2.1 Add CSS variables
     ✓ 2.2 Wire up localStorage
     All tasks complete!
You: /opsx:archive
AI:  Archived to openspec/changes/archive/2025-01-23-add-dark-mode/
     Specs updated. Ready for the next feature.

## ADDED Requirements
Requirement: Theme selection
The app SHALL let users switch between light and dark themes,
defaulting to the system preference.
Scenario: User toggles dark mode
WHEN the user clicks the theme toggle
THEN the app switches to dark mode and persists the choice

Why teams adopt OpenSpec

Solo, OpenSpec keeps you and your AI honest on a single repo. On a team, the hard part moves: a feature spans the API server, the web app, and a shared library; requirements are owned by one team and consumed by others; planning starts before any code exists.

Stores are the answer — planning in a repo of its own. The same openspec/ shape you already know (specs and changes), shared by git push like anything else. One source of truth your whole team and every coding agent can read, across every repo.

• Cross-repo features — one change, one plan, even when the code lands in three repos.
• Shared requirements — a platform team owns the specs; product teams reference them read-only, right where their coding agent can read them. No drifting wiki.
• Plan before code — capture the plan in the store now; the code repos catch up later.

Stores are in beta. Start with the Stores guide.

Quick Start

Install OpenSpec. On macOS or Linux, in your terminal:

curl -fsSL https://openspec.dev/cli/install.sh | sh

On Windows, in PowerShell:

irm https://openspec.dev/cli/install.ps1 | iex

Prefer a package manager? npm install -g @fission-ai/openspec@latest (needs Node.js 22.12.0 or higher) or the official Homebrew formula, brew install openspec.

Then navigate to your project directory and initialize:

cd your-project
openspec init

Want your AI to do it? Paste the setup prompt into your coding assistant — it installs the CLI, runs openspec init, and verifies the result.

Now talk to your AI:

• Not sure what to build yet? Start with /opsx:explore, a no-stakes thinking partner that reads your code, weighs options, and shapes a plan before any code gets written. (Quickstart)
• Already know what you want? Go straight to /opsx:propose .

/opsx:propose is the canonical name; your tool may spell it /opsx-propose (Cursor, GitHub Copilot), @opsx-propose (Amazon Q) or $openspec-propose (Codex). openspec init prints the right form for the tools you picked — see Supported Tools.

[!NOTE]

Not sure if your tool is supported? View the full list – we support 30+ tools and growing.

> Also works with npm, Homebrew, pnpm, yarn, bun, and Nix. See installation options.

Docs

Full documentation lives at openspec.dev/docs.

→ Quickstart: your first change, start to finish
→ Set up your project: what openspec init installs
→ CLI: terminal reference
→ Supported Tools: tool integrations & install paths
→ Customize: profiles, project config, and schemas
→ Stores: plan in a separate repo, shared across your team (beta)
→ Community Showcase: projects and resources built with and for OpenSpec

Community schemas

Third-party schema bundles distributed via standalone repositories — these provide opinionated workflows that integrate OpenSpec with other tools, similar to how github/spec-kit's community extension catalog handles tool integrations.

→ Browse the catalog in the customization docs.

Why OpenSpec?

AI coding assistants are powerful but unpredictable when requirements live only in chat history. OpenSpec adds a lightweight spec layer so you agree on what to build before any code is written.

• Agree before you build — human and AI align on specs before code gets written
• Stay organized — each change gets its own folder with proposal, specs, design, and tasks
• Work fluidly — update any artifact anytime, no rigid phase gates
• Use your tools — works with 30+ AI assistants via slash commands

How we compare

vs. Spec Kit (GitHub) — Thorough but heavyweight. Rigid phase gates, lots of Markdown, Python setup. OpenSpec is lighter and lets you iterate freely.

vs. Kiro (AWS) — Powerful but you're locked into their IDE and limited to Claude models. OpenSpec works with the tools you already use.

vs. nothing — AI coding without specs means vague prompts and unpredictable results. OpenSpec brings predictability without the ceremony.

Updating OpenSpec

Upgrade the CLI

With the standalone install, run openspec install. If you installed with npm:

npm install -g @fission-ai/openspec@latest

If you installed OpenSpec with Homebrew:

brew upgrade openspec

Refresh agent instructions

Run this inside each project to regenerate AI guidance and ensure the latest slash commands are active:

openspec update

Usage Notes

Model selection: OpenSpec works best with high-reasoning models. We recommend Codex 5.5 and Opus 4.7 for both planning and implementation.

Context hygiene: OpenSpec benefits from a clean context window. Clear your context before starting implementation and maintain good context hygiene throughout your session.

Contributing

Every change starts as an issue. We discuss it there, and if we agree to pursue it, a maintainer implements the change or invites you to build it with us.

→ CONTRIBUTING.md: the full process, from first issue to merged PR

Other

License

MIT