OpenSpec: fast and simple
Continuing our exploration of tools that implement SDD within our workflow, today we’ll talk about OpenSpec. Created by TabishB and first released in September 2025, it has about 3.4k forks and 48k stars on GitHub, making it one of the most relevant frameworks right now.
Its structure is much simpler than the GitHub spec-kit we saw earlier, aiming to be less bureaucratic, faster and with more deliverables. When initializing a spec with /opsx:propose, you can notice that all generated files are shorter and the information is organized across separate documents.
In a single step, the process up to implementation is basically created:
proposal.mddesign.mdtasks.md- folders with user stories
The proposal explains what will be changed or added and the impact of those changes. The design shows information such as state management, trade-offs, UI structure, models and architectural aspects. The tasks, as the name suggests, breaks the work into multiple tasks.
The folders are user stories that express what to solve given a specific situation. When X happens, Y should happen. This helps the agent better understand the context and what must occur during implementation.
After that, you can freely edit files directly or use /opsx:explore to instruct changes or fixes. If nothing else is needed, you can simply run /opsx:apply to implement everything that was documented. Extremely fast!
Once completed, use /archive to archive into an archive folder and keep the implementation documented. In the latest docs, this flow appears as /opsx:archive.
Issues
OpenSpec is one of my favorite kits and the one I use most. It’s very fast, easy to use and allows you to keep everything well-structured and documented. The problem starts when you need something larger.
Being less bureaucratic creates room for less documentation, more ambiguity and fewer explanations. For larger and more complex tasks, it may not be as suitable.
I believe it works best when requirements are simple, flexible and the project is small. The GitHub Spec Kit is more recommended for the opposite path.
