OpenSpec 1.0 is officially released.
In an earlier post, I wrote about how the OpenSpec workflow anchors development to specs as the source of truth, ensuring that what gets built stays aligned with what was intended. This spec-anchored approach has been central to OpenSpec from the beginning.
In this post, let us look at some of the major changes that come with the 1.0 release.
One of the most significant additions is the Explore Mode. Before diving into implementation, you can now use OpenSpec to think through ideas which require more clarity, investigate problems, and clarify requirements.
OpenSpec 1.0 introduces a more deliberate artifact creation process. Instead of generating everything at once, you can now step through each artifact such as proposal.md, design.md, etc. one at a time.
This step-by-step approach helps improve the review process as each artifact can be checked before the next one is generated.
Before archiving a completed change, OpenSpec now includes a verification step. This checks that the implementation actually matches what was specified in the change artifacts. It’s a final checkpoint that catches any intent alignment issues.
The config.yaml file in OpenSpec 1.0 looks really interesting.
OpenSpec’s config system makes it straightforward to integrate with external tools. For example, you can connect OpenSpec with Linear using MCP to automatically sync issues and track progress. I had earlier achieved this by forking and modifying OpenSpec, that may not be necessary anymore.
Beyond integrations, config.yaml lets you tailor the OpenSpec workflow to your team’s needs.
Originally published on https://intent-driven.dev/blog
No posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.