A lightweight spec-driven framework
Universal
Open Source
No API Keys
No MCP
Discord
https://discord.gg/YctCnvvshC
Supported Tools
Native support
Claude Code
Cursor
Codex
GitHub Copilot
Features
Review intent, not just code
Catch misalignment before it becomes code.
openspec/specs/auth-session/spec.md
### Requirement: Session Duration
- The system SHALL expire sessions after a fixed period.
+ The system SHALL support configurable session expiration.
#### Scenario: Default session timeout
- **GIVEN** user has logged in
- - **WHEN** 24 hours have passed
+ - **WHEN** 24 hours pass without "Remember me"
- **THEN** session expires
+ #### Scenario: Extended session with remember me
+ - **GIVEN** user checks "Remember me" at login
+ - **WHEN** 30 days have passed
+ - **THEN** session expires
+ - **AND** token stored in HTTP-only cookie
Context that persists
Specs for everyone: humans, agents, future you.
$ tree openspec/specs/
openspec/specs/
├── auth-login/
│ └── spec.md
├── auth-session/
│ └── spec.md
├── checkout-cart/
│ └── spec.md
├── checkout-payment/
│ └── spec.md
└── notifications-email/
└── spec.md
5 specs • 3 capabilities
Something to review in seconds
One prompt. Proposal, tasks, design, deltas—ready for your input.
agent
> /openspec:proposal Add remember me checkbox with 30-day sessions
Searching existing specs for authentication requirements...
Read(openspec/specs/auth-session/spec.md)
Creating proposal and breaking down implementation tasks...
Write(openspec/changes/add-remember-me/proposal.md)
Write(openspec/changes/add-remember-me/tasks.md)
Created change proposal <add-remember-me>
openspec/changes/add-remember-me/
├── proposal.md ← describe the change
├── design.md ← technical decisions
├── tasks.md ← implementation tasks
└── specs/ ← spec deltas
└── auth-session/
└── spec.md
This change affects 1 spec • 3 phases • 8 tasks
Coming Soon
Workspaces
In DevelopmentOpenSpec has become the go-to planning layer for many developers. Now we're building for teams.
We're tackling the following problems:
- Large codebases
- Multi-repo planning
- Customization and integrations
- Better collaboration
We're looking for ambitious engineering teams to build this with us. Direct access, roadmap influence, and early access to everything we ship.
If this is you, reach out below.
Frequently Asked Questions
Plan mode is great for a single chat session. We focus on plans that extend over multiple sessions, or that you want to share with others. A workspace for feature planning lets you plan better and refine as you go. It's something you bring through the entire development lifecycle, not just one conversation.
1 — Lightweight. Minimal steps, minimal process. We want to get you building as quickly as possible.
2 — Brownfield-first. Most tools assume you're starting fresh. We focus on mature codebases where the real struggle is figuring out how the current system works.
3 — Specs live in your code. Other tools only use requirements during planning, then throw them away. We preserve the functional requirements behind your code as living documentation, so you always know what the code is supposed to do, not just what it currently does.
2 — Brownfield-first. Most tools assume you're starting fresh. We focus on mature codebases where the real struggle is figuring out how the current system works.
3 — Specs live in your code. Other tools only use requirements during planning, then throw them away. We preserve the functional requirements behind your code as living documentation, so you always know what the code is supposed to do, not just what it currently does.
Specs serve as alignment. A way to structure your thinking in a single space before a single line of code is written. Better clarity on what you're building, and better context for your agent when executing your plan. You wouldn't ask an architect to build a house without a plan. Same idea here.
Yep! Specs get created as you build. We're exploring generating specs for existing codebases, but our view is that trying to generate all your specs upfront is a waste of time. Create specs as you need them and build your way through.
Our goal is to be a universal planning layer you can bring with you anywhere, no matter what coding agent you use. Coding agents are improving rapidly. What's popular this month might not be next month. Your specs shouldn't care. We want to make OpenSpec work no matter what coding agent you use.
In your codebase. Our view is they should be checked in - they provide visibility into how the system works and the intent it was built with.
Specs and changes live in your code, so we recommend teams collaborate through git - PRs, reviews, the usual workflow. We're building deeper team features for complex cases: large codebases, multi-repo systems, microservices. If that's you, reach out.
Waterfall fails because of rigid plans and months of upfront planning. This is neither. We want you to get to a good enough plan and start coding - minimal effort, lightweight process. You'll never have a perfect plan. There will always be unknowns. But that doesn't mean you shouldn't spend 10 minutes thinking things through. And when things change? Update the spec and keep going.
Honestly? It depends. If you're looking for a magic tool that plans everything for you without any effort on your part, this isn't it. Specs only work if you actually read them, think through them, and engage with them. This is a tool to help you build the right thing - but it works best when you meet it halfway.
Thanks for your interest
Help us understand your needs better