I've been using this, or more pointedly, I built an agent fleet (bespoke harness) where the planner agent uses OpenSpec to generate the plan. Then turns the tasks into a ticket graph.

It works fairly well, and it is definitely less heavy than SpecKit.

Checkout SpecKit and SpecDD too. There is a significant variety of spec-driven development approaches.

I think they might be in the process of re-designing the site and/or moving docs because it all used to work not that long ago, but the site design was completely different last time I checked.

Hey, maintainer here, the other reply got it right. We recently re-wrote the entire docs from scratch and we added some placeholders for other pieces of documentation we wanted to fill in, but it seems like some of the placeholder links stayed. Will update this!

I've also been building something like this, and browsing spekk-cli, it's interesting to see that we ended up with similar roles. Might be fun to compare and contrast a couple of these systems. :)

Thanks for having a look!

On removing cruft: one of the key features of spekk is an "observer" agent role that is tasked with finding drift. On a production codebase, I run this daily in a sandbox. It pulls the latest changes and looks for specs that are mismatched from the implementation, preferring to look at specs and code that changed recently and prioritizing "major" drift events. The observer agent then opens a PR wkth its observations (markdown with YAML like the specs). It also posts a summary to Slack, but that's optional. The sandbox agent code is part of the spekk-cli codebase.

I use the cli tool outside of the agent session. e.g. `openspec view` to see all the specs and what's pending.

Yeah - I'm sure folks have pushed it further than I have. But this is what I've seen with my own eyes as opposed to read from others. And even at 471, I'm impressed.

Symlink the global MD files to a single file I control that is versioned. Define my own general spec and workflow terminology using markdown files in this universal MD.

```

~/.config/opencode/AGENTS.md

~/.claude/CLAUDE.md

~/.codex/AGENTS.md

~/.copilot/copilot-instructions.md

~/.gemini/GEMINI.md

```

Define it as a graph and iterate. I use more tokens, but I can also use more tools without disruption. Delegating markdown to folders/smaller repos can solve the tokens/context issue.

I settled on lat.md [1] at the beginning of this year and never looked back.

Its design offers a compellingly simple surface for weaving natural-language intent into the codebase itself, without overcomplicating things:

---

Key Ideas

* Plain markdown: readable by humans, parseable by agents

* Wiki links connect concepts into a navigable graph

* // @lat: and # @lat: comments tie source code to specs

* lat check ensures nothing drifts out of sync

* lat search for semantic vector search across all sections

---

For me it strikes the right balance between structure and flexibility. It gives agents enough context-efficient grounding to reduce functional and architectural drift [2], while remaining malleable enough to evolve with new requirements.

Admittedly I haven't run any evals, and I'm sure there are even better systems out there... but if I still had the problem I was trying to solve when I found it, I wouldn't be talking about it right now.

Of course it's likely that my problem has only migrated to a higher order of complexity, but surfacing it again through building increasingly complex things is an interesting enough challenge in itself.

[1] https://github.com/vercel-labs/lat.md

[2] 100% auto-eliminating drift is an unrealistic goal -- that's where you come in.

LOVE. LOVE. LOVE. Openspec.

Easily my favorite spec driven development framework.

It scored really well in our internal evals as well.

I think it has the most sane ceremony and its model fits my mental model really well.

I've also been working on a TUI that will automatically generate "phases" with each one being a openspec spec.

I would highly recommend trying out SpecDriven development. I found it to be the most productive way to work with LLMs for larger tasks, and I have found that it improves performance on larger tasks.

To me, this is where LLMs should go. Collaborating on shared documents that serve as a contract that then gets evaluated post-implementation

I've made multiple attempts to write domain-specific languages for LLMs to use to guide software architecture so that I can have higher-quality software architecture and also so that it can communicate ideas to me in a more terse way.

One thing that I think LLMs are lacking right now is information density. I'm a guitarist, and I like this game called Rocksmith, but I think that its user interface kind of sucks. It's fun to play along with the songs, and it's fun that it scores me on the songs and gamifies playing guitar. For dense notes, the user interface just isn't very good.

That kind of made me think more about information density. A sheet of notes is very dense, but it takes a little more time to process. Guitar tablature is slightly less dense, but I think it strikes a better balance between treble clef and Rocksmith. Really, I'd rather have all three of those presented to me.

This is really where I'd like to go with how I'm writing software now. LLMs: I'd love to be able to just create a specification that is very dense and describes domain-driven design concepts to the LLM, and then have a workflow that will do adversarial review to evaluate those concepts after implementing a phase.

This also kind of solves part of the problem with design decisions and artifact storage and all those things that we kind of see LLMs scatter around a codebase. If it exists in the spec, then it can be referenced later, and you can document changes, etc. Also, if you do the spec right, it could be language-agnostic.

Tired of wrestling JIRA for AI project specs. If this actually streamlines things, I'm definitely giving it a look.

They can plan, but no guarantee it will produce what you want. Sometimes most of the work is aligning on what to build. And I'm not handing over technical planning to it yet.

I use this skill and it makes the specing process progressive. Human driven for the "what", 50/50 for higher level technical planning, only where it has questions in the low level details: https://github.com/scosman/vibe-crafting

specifying is not planning

I bother because Claude Code does wacky nonsense unless I use OpenSpec (or something similar) to explicitly research, scope, persist, then implement in a brand-new context. Even Opus will do ridiculous nonsense like throw its hands up when asked to start a Docker container, ignore explicit architectural instructions, write verbose make-work documentation riddled with inaccuracies, etc. Using OpenSpec keeps things as constrained as possible with the side effect of recording what your system does.

OpenCode and various open models do not exhibit this tendency nearly as much in my experience. My recent experiences with GPT-5.6 were also very positive in this regard. Alas for regulatory reasons this stack is a non-starter at $DAYJOB so I'm stuck working around Anthropic's capacity optimizing shenanigans.

if anything in the latest batch, they have been trained to try everything and anything to get a task done, hence their hacking abilities, but also how they go way off the rails when they don't get sufficient context on our human intent for the task

feels less like planning and more like throwing spaghetti at the wall the moment ambiguity emerges, I really hope the next batch dials it back

At least for my personal projects, it's enough that they're better than me at long-horizon planning.

Do you save the plans from plan mode alongside of the feature? I use specs to save the artifact but hadn't thought of using plan mode as the spec generator itself.

For teams its very helpful too, as you entire team standardizes around a common set of artifact for planning and executing work (with explicit semantics). Avoids snowflake agent sessions and artifacts for planning, proposing and executing work.

I just rely on a log of user messages, all messages the user typed in a project as raw data and do a pass with agents to synthesize intent. Then use this for planning and validation of code. I think the user messages are the most valuable data in a project for this reason. Doing this reflection pass on messages takes just a few minutes even for thousands of messages. It keeps global perspective which is often lost in local work.

I agree but your taste in making solutions, or that of your organisation may be very different from what an LLM does by default. I personally use specs to capture this taste; an example shared by most LLMs is that they like to document not only what they have built but also what they have not built. Especially after changing solutions or small migrations. Specifications can resolve most if not all of that behaviour.

Spec-driven workflows really seem to be where agent tooling is heading

how are people currently evaluating between the different spec writing frameworks out there?

I use this to produce the task list which I then feed into a Ralph loop using a bash script. I save a lot of tokens since each tasks context is so small.

You know

If you're writing design documentation to /tmp you're not the target audience for this kind of thing

Even OpenSpec is too heavy for me. I do similar things but in one file, which I generate with a skill after a planning session. The important thing is to have a file reviewers can audit the code against.

Trying to impose this kind of structure on the agent workflow creates more work and decreases quality. It's an illusion of control.

Yeah I agree that if no thought or effort is put into the spec, it can turn into unreadable slop. We see a wide spectrum of specs, some more thought out than others. While quality(and readability!) of spec will still largely be on humans, there's things we want to do to improve this experience. We'll be updating the experience not too far away to make things a lot more succinct and iterative.

Either ways, we're open to feedback and I'm happy to have a conversation. Feel free to email me at tabish@openspec.dev to set something up.

I too felt the need for some structure around AI coding, and created a spec-based tool earlier this year: https://www.shipsmooth.net/. I'm happy using it. I think of it as "light-weight" and encouraging iterative development over specs+code. It creates just one spec file and one "tasks" file for each unit of work. Available as a plugin for Claude, Codex etc.

> The power is that you do a lot of upfront thinking

This is the best part of this spec, but we have found from our experience that though upfront thinking changes has a lot of merits and adds clarity and alignment upfront, but it changes bit by bit in every meeting and before you know your specs are not aligned with general consensus in the team. If your team is large enough, then it gets very difficult to own the task of constructing alignment between your principal-artifacts and your evolved under-current of understanding.

If you check my submissions (https://news.ycombinator.com/submitted?id=gps372), I have written whole set of articles on the myths of how easy it is keep the understanding consistent.

I would still say that if you are working on a platform and if your engg team size if anything more than 25-30, then this spec must be adopted from top-down and not bottoms up. Bottom level engineers usually don't have the level of consistent exposures (as and when they socialize and evangelize their platform) which top level engineers have.

Thanks for taking time to respond here. Would love to know from your experience the scale of function-points, team size, client-requirement variance, etc. different teams would have worked with and maintained over a period of time via this open-spec.

Please note that I can already see that github repo has 68k+ stars. So popularity is not in question, just the viability and consistency of adoption across different scenarios.

It's interesting to see the divergence of opinions on these frameworks and also at least anecdotally how many people roll their own custom implementations of workflow management on top of their favourite SDD framework.

I also ended up doing my own thing mainly to address several omissions in the existing frameworks (for SDD I prefer to use Superpowers and/or Matt Pocock's skills):

1. Artifact staleness and tracking - if you have a structure around starting with something like an ADR, common patterns for the whole repo etc., it's super hard to keep track of and actually keep it up to date. You make a strong early decision in an ADR and realize that you have to change it later on, or diverge. These changes get rarely properly recorded.

2. Review loop - Same model review isn't enough, I want bunch of models bouncing off each other, whilst still using my subscription and not API.

3. Feature creep and deferral tracking - it happens a lot that you encounter either during review or one of the validation phases that you also need to implement x, which is not covered by the original spec. There are several options to handle that, with the key that all those decisions need to be tracked and at some point decided by a human.

4. Custom workflow with governance - I have my own preferred SDLC if you can call it that, which includes rounds of agentic review of spec, before manual approval gate, review loop with certain specification depending on the codebase, feature size, deferral rules.

5. Ceremony based on context - Because it would happen that some of the ceremony would get in the way at some points (like producing a 100+ loc spec for 10loc change) I ended up basically developing a flow to decide whether a feature actually needs the full ceremony (full lane) or we can simply use the native plan feature (fast lane), so that I don't have to go through the whole ordeal of steps, when I need a tiny change.

I forked this code and added bits that matched my flow and it works out pretty well https://github.com/nutthouse/tutti

Would love to see a standalone binary, global Node installation is annoying

Until LLM context sizes explode by two orders of magnitude, I cannot envision significant agent programming without leaning heavily on spec-driven workflows.

It's also worth noting that SDD is such a wide variety of approaches that the term on its own says very little. For example, SpecKit and SpecDD are both very capable SDD frameworks, yet they have only minimal overlap: SpecDD describes system components (with emphasis on boundaries), while SpecKit is a fairly advanced process for changing specs.

Been using it for a bit. I think its a matter of time until we dont look at code anymore and only look at specs, plans, design docs. I didnt like the doc organization (or lack of it) using a standard reader or editor, so I built one specifically for OpenSpec. Hope you find it useful https://specks.nicotejera.com

I think the premise is that when agent modifies the code with human instruction explicitly saying spec has changed, the agent goes to the spec and updates it. But maybe giving it too much of credit and projecting what I think it should do.

The project evolution tracking argument does apply here, but another benefit is provides a standardized structure for planning and executing work that you can build your agentic code flows/loops around.