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.
This looks like exactly what I've been thinking I needed. I've tried Superpowers, GSD and oh-my-claude/openagent and mostly they burn more tokens.
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.
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.
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).
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. :)
The CLI is actually useful. It gives the skills a way to deterministically interact with the spec. For example, it can validate the shape without having to spend tokens reading the files.
I am sorry but 471 lines is nothing in 2026. Come back when it has executed a 5000-10,000 line spec flawlessly, although the threshold keeps getting higher as the models get better. You're right though about a simple spec based workflow going far.
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.
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.
Haven’t we moved on from these things? Most recent LLMs have been trained on enough long context tasks to have become pretty good at planning. Perhaps with contributions from the harness. In either case, I wouldn’t bother if I were using Codex or Claude Code.
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
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
Well, they are absolutely pretty good at faking being good at long-horizon planning which is enough to fool a lot of people till things start breaking lol.
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.
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.
I just have it write a checklist file in /tmp (or a todo folder if I want to keep it), and check off items as it finishes them. Seems to work fine. Is this really needed?
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.
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.
This looks like exactly what I've been thinking I needed. I've tried Superpowers, GSD and oh-my-claude/openagent and mostly they burn more tokens.
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.
This section https://openspec.dev/docs/setup links to "Concepts"
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...
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.
This is my first time seeing openspec, and it seems to share a similar philosophy to what I've been working on this year.
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).
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. :)
It's just a bundle of skills and md files...
Why does it need to have an entire CLI?
The CLI is actually useful. It gives the skills a way to deterministically interact with the spec. For example, it can validate the shape without having to spend tokens reading the files.
Compared to including shell scripts with the skills?
Not trying to say that it's not useful, but it seems excessive and potentially bloated.
I use the cli tool outside of the agent session. e.g. `openspec view` to see all the specs and what's pending.
I have a super simple spec-based workflow. It works amazingly well. I’m amazed how well coding agents can work through what I consider large features.
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 am sorry but 471 lines is nothing in 2026. Come back when it has executed a 5000-10,000 line spec flawlessly, although the threshold keeps getting higher as the models get better. You're right though about a simple spec based workflow going far.
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.
What are people using for this nowadays?
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.
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.
Haven’t we moved on from these things? Most recent LLMs have been trained on enough long context tasks to have become pretty good at planning. Perhaps with contributions from the harness. In either case, I wouldn’t bother if I were using Codex or Claude Code.
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.
This is absolutely not true
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
Well, they are absolutely pretty good at faking being good at long-horizon planning which is enough to fool a lot of people till things start breaking lol.
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.
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.
I just have it write a checklist file in /tmp (or a todo folder if I want to keep it), and check off items as it finishes them. Seems to work fine. Is this really needed?
/tmp? What happens when you reboot?
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.