Last week I wrote about spec-driven development (SDD) as a new wave of frameworks for vibecoding. I tried a few of them. If you’re just exploring SDD, I’d suggest starting with OpenSpec.
Why?
For me, it felt the simplest and least overloaded.
To get started, you basically need 3 commands:
/opsx:propose
Here you describe what you want to build: bugfix, feature, design or something else (but using SDD for bugfix still feels like overkill).
What I liked:
- You get a structured design (
design.md)- It explains why decisions were made
- It adds open questions for clarification to think more
- You get
tasks.md with detailed steps what will be doneAt this stage I had to iterate a few times because some assumptions were wrong. But in the end I identified gaps in initial feature definition and got a clear plan of future changes. The good thing is that changes at this stage are cheap.
/opsx:apply
If you’re ok with the design, you can ask the agent to execute the plan. It's possible to execute all tasks at once, split them or run multiple agents for parallel execution. Implemented steps are marked as completed in tasks.md.
/opsx:validate
This is a control step. You can request the agent to validate that the implementation matches the design. Because… agents still drift and make mistakes.
Of course, OpenSpec contains other interesting commands, but you can add them later when you get used to SDD.
How is it different from Plan mode?
Plan mode mostly generates
tasks.md. No design. No real spec. SDD reframes the work into a design-first approach and adds additional prompts to do it well.
And honestly, I liked the preparation phase result much more.
I wouldn’t use it everywhere, but for refactoring or feature development it looks really good.
#engineering #ai #sdd