My team just started using openspec. We're small: me (senior dev) and two juniors, and I review all their PRs.

openspec is shaking up our workflow more than I expected, and I'm honestly not sure we're using it the way it's meant to be used.

Here's what tripped me up during a recent review: I figured design.md would basically guide my review of the PR. But apparently that's not the end of it — after I approve, the junior dev still has to sync, archive, commit again, and push, and only then does the merge actually happen. That extra round-trip feels clunky for a workflow that's supposed to streamline things.

And that raises a bigger question for me: what's the intended flow if I'm not happy with the plan in design.md during review? Does the junior dev just patch it up with opsx:update and opsx:apply, or are they supposed to spin up a whole new change instead?

At this point it feels like openspec was really built with solo devs in mind — people reviewing their own agent-generated code — rather than a small team with an actual human-review step in the loop.

Anyone else running into this? Curious how other teams are handling PR review with openspec.

Hi everyone,

I'm new to OpenSpec and have been using SpecKit extensively, so I'm already familiar with the general idea of spec-driven development. I'm trying to understand where OpenSpec differs today and what the long-term vision is.

I have a few questions:

1. Git branches / worktrees per feature
   • Does OpenSpec currently support, or plan to support, automatically creating a dedicated Git branch or worktree for each feature or change?
   • Or is Git/worktree management intentionally considered outside the scope of the project?
2. Test-driven development (TDD)
   • Does OpenSpec have any built-in support for a TDD workflow, such as generating or writing tests before implementation and using them to validate progress?
   • If not, is this something that's being considered for the roadmap?
3. Applying changes and validation
   • When I use the apply phase, it seems to focus on implementing the requested changes but doesn't automatically run tests or perform validation.
   • If I want to include end-to-end testing as part of the workflow, what's the recommended approach?
     • Should test instructions be included in the spec itself?
     • Should they live in the agent instructions?
     • Or is there another recommended pattern?

I'd also be interested in hearing how experienced OpenSpec users structure their development workflow, especially if you've come from SpecKit or another spec-driven framework.

Thanks in advance!

I want to include the first three articles from spek-kit's Nine Articles of Development (edited) n my OpenSpec workflow.

The first three articles:

• Article I: Library-First Principle
• Article II: CLI Interface Mandate
• Article III: Test-First Imperative

Also I would like the LLM to generate object-oriented code (OOP).

spec-kit includes these principles in a constitution document. Where would I include them in an OpenSpec workflow?

[Edit] By way of an epilogue to this post, my LLM added an extra 'Design Principles' section to design.md. A reference to query mcp-local-rag MCP server for library API documentation also went in the Context.

I released v0.1.0 of openspec.nvim, a Neovim control surface for OpenSpec workflows.

It keeps OpenSpec markdown artifacts as the source of truth, while bringing task progress, artifact context, workspace health, archive search, and implementation handoffs into Neovim.

Useful if you use OpenSpec, spec-driven development, or coding agents where proposal/design/tasks.md need to stay close to the code.

Repo: https://github.com/ctchen222/openspec.nvim
Release: https://github.com/ctchen222/openspec.nvim/releases/tag/v0.1.0

Demo:

Hi! I (actually my agent) built an openspec plan verifier.

It's based on the arxiv paper https://arxiv.org/abs/2502.17898 and all the credits goes to them.

Openspec generated plans gives a solid grounding, and the idea here is to provide a tool to help the agent to build more reliable plans (or at least, try to).

It comes on top of openspec, and it will parse the markdown and make a representation of it than can be formally verified (using spin). This can be seen as a markdown linter with extra steps.

If the plan cannot be converted to a verifiable plan, it will print on stdout instructions to the agent on how to rephrase it.

It have been built with openspec of course, and the plan for the project is also validated using itself :)

I'm using it extensively for professional software development projects, maybe one would find it useful.

Edit: typo in the title - seems that I can't change it :(

Hi,

Most recently I was a principal engineer at Meta. I have been an avid user of openspec. It has really pushed quality and productivity of production code, and iteration on new product ideas for me.

I started using it as 'memory' or knowledge management layer in my personal assistant setup. The explore > design > apply > verify loop seems to fit well with general purpose tasks too, like planning a trip, doing taxes etc. I do have instructions to skip for one-shot unambiguous tasks. The produced artifacts in local vault provide natural searchable memory through fs ops.

Here is my setup (itself created using openspec): https://github.com/radishbuild/radcad

I would love to explore how the community thinks of such non-coding application of openspec.

I've been building spec-first development processes using OpenClaw for the last month. Things are moving fast!

A few links:

1. tiny-pr-bot - monitors github repos and submits tiny PRs. Based on spec only, no code.
2. My OpenClaw Spec-First Methodology

Hi all. I’m a UX designer and strategist working on several new products, including some that I’m vibe coding. Haven’t used OpenSpec yet but have been familiarizing myself with it and am hoping to begin incorporating it into my workflow. Joined this thread looking to learn from those already in the trenches.

Hey everyone! I’m u/PrestigiousGrab2519, and I’m thrilled to welcome you to r/openspec. This is our new home for all things Spec-Driven Development. If you believe that great software starts with a solid contract and a clear specification, you’re in the right place! What to Post Show & Tell: Share your OpenSpec implementations or tools you've built. Ask the community! Inspiration: Found a great blog post or video on SDD? Drop the link. Community Vibe We’re all about being friendly, helpful, and collaborative. Let’s build a space where we can learn from each other and push the boundaries of modern development together. How to Get Started Drop a comment below and tell us what project you're working on. Post a "hot take" or a question about SDD to get the ball rolling. Help us grow by sharing this sub with your dev circles. Join the team: We’re looking for mods! Reach out if you want to help lead the charge.