Trying OpenSpec: A Lighter Approach to Specification-Driven Development

After recently experimenting with specification-driven development (specifically SpecKit), a colleague of mine mentioned OpenSpec as another option worth trying. Ever curious, I decided to build a few real features with it to see how it felt in practice.

I don’t want to cover any ground I already touched on in the SpecKit post, so I’ll try to keep this focused and share my view on how OpenSpec works, what it encourages you to think about, and how it feels to use it.

A Quick Pause: What These Tools Are Really Doing

First, time for a little self-reflection. After spending time with more than one SDD tool, I started to think about what they actually provide.

I kept thinking “Yeh, but the model is still doing everything, so what’s the benefit?”

And it’s true, under the hood, tools like OpenSpec and SpecKit aren’t really introducing new intelligence. The underlying model still does most of the heavy lifting. These frameworks don’t make the AI smarter, but they shape how you interact with it.

At a high level, SDD tools tend to do three things:

• They extract your intent into files instead of short-lived chat history
• They deliberately slow your interaction with AI (this is a good thing IMO!)
• They give the model a clear role at each stage of the process

Once you see them this way, the differences between tools become less about capability and more about things such as:

• What do they ship with by default? You can bend the commands/prompts of these tools to your will, should you wish, but many of them come with different presets, and you might be better served picking the best tool for the job
• How much structure do they impose?
• Where do the constraints live?
• How many artefacts does it generate?
• How permanent is each artefact supposed to be?

That reframing made it easier to appreciate what OpenSpec is optimising for.

So, What OpenSpec Is Optimising For?

OpenSpec still guides you through a sequence of stages:

1. Proposal
2. Validation
3. Application
4. Archiving

What stood out to me wasn’t the existence of these stages - that idea isn’t new or novel - but what they optimise for.

OpenSpec seems to prioritise momentum and clarity. Each stage exists to slow you down just enough to make you think about your intent, clear up any unknowns but it doesn’t force you to produce large or long-lived artefacts at every step.

The workflow feels designed to keep you moving forward while still maintaining alignment with the model. You’re encouraged to think, review, and validate - but you’re not constantly stopping to read huge Markdown files all the time.

In practice, that meant fewer documents, lighter content, and less friction between stages (noted above), while still benefiting from a clear structure around how changes progress.

For clarity, I didn’t customise anything here - I followed the “Getting Started” guide and defaults verbatim. The lighter feel wasn’t something I engineered; it seems to be an intentional part of how OpenSpec is designed in my opinion.

specs/ vs changes/: Keeping The Current State and Proposals Separate

One of the most useful ideas in OpenSpec is its two-folder model:

• openspec/specs/ represents the current state of the system
• openspec/changes/ contains proposed changes you’re working on

Rather than editing an existing spec directly, OpenSpec encourages you to work on changes alongside the current state which remains intentionally unchanged, until a specific point in the flow. That makes it very clear what already exists versus what you’re modifying.

This way, you’re never mixing “what is” with “what will be”, and it helps keep specs upto date.

Smaller, focused specs

Another thing I liked was how one proposal can be broken down into multiple smaller specs rather than a single huge one. For some of the features I built, OpenSpec seemed to encourage multiple focused specs with clear scope. That made the specs, design and tasks easier to read and follow.

Token Usage and Workflow Shape

One very practical observation was around token usage.

With OpenSpec, I was able to complete a non-trivial feature within a single Claude Code session, without hitting any limits (although by the end, I was near 100% usage for my session). The change itself wasn’t small - 54 file changes and 5,409 lines of code. I personally never managed to achieve this with SpecKit. I don’t know exactly why this was the case, but it may have been the result of fewer steps or less repeated context being sent to the model.

Regardless of the reason, this alone makes OpenSpec an attractive option if I was looking for an SDD option for side projects.

Archiving as a First-Class Concept

In OpenSpec, archiving marks a clear transition point for your specs.

Changes seem to be temporary by design. They live in openspec/changes/ while a proposal is being explored, validated, and implemented. When that work is complete, archiving is the explicit step that turns a proposal into part of the system’s baseline.

Archiving a change does two things:

• It applies the change to the relevant spec, updating the current truth
• It moves the change itself into a dated archive under openspec/changes/archive/

That means archiving is more than just housekeeping. It’s the moment you decide that a change is no longer a proposal, but something future work should build on. It’s then part of the system.

I found this distinction useful because it gives changes a clear lifecycle. Specs remain focused on the present, while archived changes form a historical record of how the system evolved without cluttering the active workspace.

Closing Thoughts

Using OpenSpec reinforced something I’ve been thinking for a while: specification-driven development isn’t TOO MUCH about tools - it’s about shaping your interaction with AI.

OpenSpec offers a staged workflow, but keeps the artefacts lightweight and the rules local to the change you’re making. That makes it easy to adopt incrementally, especially in projects that already exist.

Rather than trying to decide which approach is “best”, I find it more useful to understand which problems benefit from which level of structure and OpenSpec sits at the lighter end of that spectrum, and for my side project, I really liked working with it.