In my experience, spec drift is the main reason why none of these tools work. Maybe they work for one shot greenfield feature generation but in a large, multi developer long lived code bases, specs rot and end up being more pain than they are worth.

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

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.

If you like this / SDD, I'd appreciate your feedback:

https://github.com/spekk-ai/spekk-cli

Similar iterative specs philosophy. Ours is a bit different because we focus on declarative specs and installable agent skills. We chose Go for simplicity and minimal requirements (single binary).

Also, this looks like something which leadership level folks need to adopt first and then somehow it needs to trickle down to PI planning and sprint planning. Would like to hear someone's experience on how this has got adopted in their org.

Last week, I gave a 471 line spec to implement a major feature and it didn’t flinch. I wrote about it here.

https://jaisenmathai.com/articles/sojourn-for-ios-was-45-one...

i find a small, human written spec to be much more effective than these large spec documents.

the idea is that you iterate with your agent to write the spec, you implement, then eventually that spec gets merged into a "spec corpus" that describes all the behavior of the repository. but i don't think that prose can ever enumerate all the behaviors required of code, nor should it. the spec almost immediately becomes out of date.

Concepts links here: https://github.com/Fission-AI/OpenSpec/blob/main/docs-lab/gu...

All the docs here are the templates rather than the actual file (I presume: https://github.com/Fission-AI/OpenSpec/blob/main/docs/concep...)

Somehow not very confidence inspiring...

Lately I've been using stock OMP and its close to the right balance but not quite enough of the brainstorming and spec maintenance built in. I've tried to layer some simple stuff on myself but with mixed results.

There seems to be a spectrum from fluid, iterative workflows like OpenSpec to more up-front alignment and control like Matt Pocock skills.

Curious what people have settled on.

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

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.

Why does it need to have an entire CLI?

Basically the flow proposal -> design -> specs -> tasks gives you and AI a method to build context on what you want to achieve. In a way you're just creating a plan/big prompt that is structured in such a way that they start stacking on each other.

The power is that you do a lot of upfront thinking. In my team we then share it with a colleague who will review it through a PR. After that implementation is usually hands off. At the end there is a skill to verify the change against specs. I do still review the code myself too.

I guess if you work in a task oriented environment this will not work as well, as you'd lack/don't care about the business context. I'd like to think that most software development does not happen like this, but is done by engineers who actually understand why something is needed and take that into account when designing and building the solution.