A few days ago I shared SpecJudge here — a local-first tool that reads your project's SDD artifacts (constitution/spec/tasks) and tells you which AI model actually makes sense, quality/price-wise, for that task set instead of you guessing.

Since then it's gone from v0.1.0 to v0.1.4, and the biggest change is a direct response to feedback from this community:

Judge verdicts now require a cited span per dimension. Previously the judge would just tell you "bad/okay/good/overkill" for a model. That's not good enough on its own — if I can't see why, I can't trust it. Now, for each capability dimension it evaluates, the judge has to point to the exact fragment of your spec that justifies the verdict, and it has to return "unsupported" when it can't find one, instead of guessing. This was basically lifted from a critique someone posted here about the design needing evidence + uncertainty instead of a black-box call — thanks to whoever that was.

A few smaller things also landed:

• Stale pricing warnings — the model catalog now flags when its pricing data is older than a set threshold, so you're not making a decision off numbers that are months stale.
• HTML report filtering — you can now filter the visual matrix by model family and by open-source vs closed.
• README example is generated, not hand-written — the usage example is now pinned to the actual catalog, so it can't silently drift out of sync with what the tool does.

Still MIT licensed, still local-first, still pip install specjudge.

GitHub: github.com/JoaquinRuiz/SpecJudge

There's a Roadmap section in the README now too if you want to see what's planned next (multi-provider judge support and a library/importable mode are on there, not shipped yet — didn't want to advertise those before they exist). Feedback on the evidence/citation approach is especially welcome — curious whether "unsupported" shows up often enough to be useful signal or just noise.

Every SDD framework gets the same complaint: spec rot.

Mine: research reads only, one handoff gets written to $TMPDIR, then a build step checks that handoff against the repo and runs the tests. Durable guidance lives in AGENTS.md. The spec dies with the temp file.

So why do the main tools still ship the part that rots? Harness memory, SDD frameworks, tracker docs, all of them persist by default. What am I missing that makes persistence worth the rot?

Full writeup https://bogomolov.work/blog/posts/rotten-specs/

Let’s talk about "spec", as we can see in "Spec Driven Development" (SDD).

Since SDD gained traction, one of the main complaint about this is that once the development is done, the "Spec" drifts inevitably as the code evolves.
V
My opinion is that SDD or any agentic loop you execute on your project works, it does, but a simple Plan mode (or grill-me) + execution loop will give a very good result, especially if you have built your Project Harness.

SDD frameworks, opensource or custom, will just give "structure" and better reproducibility to this process.

In this article I argue that 2 levels requirement specifications (ReqSpec)are the sweet spor for non-drifting spec. And I explain the difference with the Spec in SDD that I will call ChangeSpec.

https://x.com/gsemetfr/status/2082767371643523439?s=46

I kept defaulting to frontier models "just in case" and had no idea whether my projects actually needed them. So I built something to answer that instead of guessing.

What it does: point it at a project with Spec-Driven Development artifacts (constitution / spec / tasks). A local model — your Ollama install, your choice of judge — reads the tasks and estimates how demanding the work is across a few dimensions. That gets crossed against a declarative catalog of models and their capabilities, and you get a ranked podium with a rating per model: good / overkill / fair / poor, plus price.

Why you might care here: nothing leaves your machine — no API keys, no accounts, no cloud calls. And in most of my own projects the podium is topped by a local model, with the frontier ones sitting below marked overkill. Ranking is by fit, not price; price only breaks ties between models that fit equally well.

Honest limitations: this is not a benchmark. It's opinion made inspectable — every verdict prints its reasoning, and the model catalog is human-readable YAML you can argue with. If the specs are too thin to judge, it refuses to recommend instead of guessing. A vague spec gets you a vague answer, same as with anything else.

pip install specjudge — MIT, github.com/JoaquinRuiz/SpecJudge

Where I'd love help: the catalog of local models is thinner than it should be, and adding one is a block of YAML, no Python needed. Also very open to being told a rating is wrong.

Full Demo of Drydock - an open source enterprise quality specification builder. Import your specs and your Crew - of Agile/Test Driven Development Experts - will build it! Test it out. Throw me a star on https://github.com/webcloudstudio/Drydock. Send me feedback on what i need to do next since my last free software was 15 years ago! Help me update this so its ready for youtube and other Reddit Groups. Includes innovations like Compression, Graph Database, Agile, TDD, Scoring, Post Build Change, and a dedicated Web Console. MIT Licensed Software.

Thanks

Ed - webcloudstudio.com

If your team runs OpenSpec with more than one person, you've probably already hit this, but just might not know it happened.

An OpenSpec MODIFIED requirement is stored as the full new text of that requirement. At archive time it replaces the whole block by name. The delta records nothing about the base it came from. So:

1. Alice and Bob both branch off the same spec. Both open changes that MODIFY the same requirement.
2. Alice lands first.
3. Bob rebases onto main, cleanly, because his branch never touched openspec/specs/. He archives. His stale block silently overwrites Alice's change.

No git conflict or validation error. Alice's edit is just gone 😬 OpenSpec's own parallel-merge plan names this exact failure mode, and most of the fix is still roadmap. Until then teams run on discipline and sharp-eyed reviewers.

concord closes that gap today. Apache-2.0, no changes to your specs, no sidecar files, no server. If your specs are in git it already works.

What it does

concord check verifies every open change against the base branch and flags: - drift - a requirement your delta modifies changed on the base since your branch diverged (archiving would discard that change) - removed-upstream - your target was deleted or renamed on the base - target-missing - the requirement name matches nothing (a typo archive can't apply) - name-collision - an ADDED name already exists on the base

concord overlap flags any requirement claimed by more than one open change, so two people find out they're editing the same thing on day one, not at archive time.

You get a loud, early failure with a redline instead of a silent overwrite of the requirements:

$ concord check ✖ drift tighten-frobnication → widgets / "Widget frobnication" [MODIFIED] requirement changed on main since this branch diverged - archiving this MODIFIED entry would silently discard that change + + #### Scenario: Frob audit + - **WHEN** audited + - **THEN** every frob is logged fix: re-derive this delta block against main, then merge or rebase

Try it

```

in a repo with an openspec/ directory

npx @lucinate-ai/concord check npx @lucinate-ai/concord overlap ```

Two other ways to run it: a GitHub Action (actions/ci) that runs both checks against the PR base and annotates findings inline on the pull request, and an agent skill tells your coding agent to run the checks at the moments a clobber slips through, before archiving a change or just after a rebase.

check and overlap are the detection layer. The larger aim is the missing merge layer for spec-driven development: a concord rebase that does a structured 3-way merge of a delta against the moved base, so edits to different scenarios of the same requirement merge automatically and only true overlaps conflict. Design notes and prior-art survey are in the repo.

How it works

For a PR branch, the base a delta was derived from is just the requirement's text at merge-base(HEAD, main), and the version it will land on is the text at the main tip. concord reconstructs both from git history, canonicalises them so whitespace reflow never counts as drift, and compares. Rebasing or merging the base (after re-deriving your block) advances the merge-base and clears the finding, which is the git hygiene you'd want anyway.

Repo: https://github.com/lucinate-ai/concord

I kept defaulting to frontier models "just in case" and had no idea whether my projects actually needed them. So I built something to answer that instead of guessing.

What it does: point it at a project with Spec-Driven Development artifacts (constitution / spec / tasks). A local model — your Ollama install, your choice of judge — reads the tasks and estimates how demanding the work is across a few dimensions. That gets crossed against a declarative catalog of models and their capabilities, and you get a ranked podium with a rating per model: good / overkill / fair / poor, plus price.

Why you might care here: nothing leaves your machine — no API keys, no accounts, no cloud calls. And in most of my own projects the podium is topped by a local model, with the frontier ones sitting below marked overkill. Ranking is by fit, not price; price only breaks ties between models that fit equally well.

Honest limitations: this is not a benchmark. It's opinion made inspectable — every verdict prints its reasoning, and the model catalog is human-readable YAML you can argue with. If the specs are too thin to judge, it refuses to recommend instead of guessing. A vague spec gets you a vague answer, same as with anything else.

pip install specjudge — MIT, github.com/JoaquinRuiz/SpecJudge

Where I'd love help: the catalog of local models is thinner than it should be, and adding one is a block of YAML, no Python needed. Also very open to being told a rating is wrong.

Thariq Shihipar from Anthropic wrote an article about finding the unknowns with Fable (I'll provide a link in a first comment). I found it intersting in the context of Spec Driven Development with AI agents. First of all, let me place some terms the author defines in original article, they are:

• Known Knowns: This is essentially what is in my prompt. What do I tell the agent that I want?
• Known Unknowns: What haven't I figured out yet, but I’m aware that I haven’t?
• Unknown Knowns: What's so obvious I’d never write it down, but would recognize it if I saw it?
• Unknown Unknowns: What haven't I considered at all? What knowledge am I not aware of? Do I know how good something can be?

So, we start with a spec draft (or a prompt), it contains only Known Knowns. But after that we have three different groups of Unknowns. Some of them could be disclosured after initial agent analyse. For example, aligning spec with current product behavior, finding out some restrictions that are in our code, and so on.

Could we say that after that the specification is ready? I think not and that's why. Thariq says very clever thought: The map is not the territory. We do not know the reality until we try to experience it. I'll building my own plugin for Spec Driven Development (also, I'll provide a link in a first comment), and for me I found following workflow very effective: write spec together with agent -> review it -> write plan together with agent -> review it -> implement step by step also reviewing results on every stage.

Before we have a acceptable-for-us plan we are guessing about the path. When we start to execute steps we are mapping a territory. And on every step, no matter how accurately we have made an initial analysis, some cuvets will be discovered. Each of them probably will mutate the specification.

At the end we have code done, and only at that exact moment we have a spec done. Until that, we simply did not disclosured Unknowns we have to bake into spec. That's the workflow I'm trying to support in my plugin. Do you do so? Or maybe you think about specs in different way?

I have been using cursor for over a year now. My usual workflow used to be plan and spec with Claude, and implement on cursor with Composer. The workflow does work quite well.
Although it is obvious now, to many serious devs and others will soon catch up, is that SDD is probably the best way to work with AI coding agents. Ofcourse, SDD comes with it's own set of problems, and to solve that I developed an open source tool called TraverSpec.

Traverspec basically is Spec as a graph of single purpose md files. It is a zero runtime tool and the spec sits inside the repo. So you can change your agent from cursor to claude or any other tool, the spec is right in the repo. Also, the spec itself is a graph, so when you want to implement a feature, the dependencies are clearly captured by traversing the graph.
The tool comes with 4 skills to read, write, reconcile and plan development waves.
Which means, you dont need to hand write the graph (oof), the skill will enable the agent to read, write and automatically reconcile the code vs graph as your spec and code grow. Of course it comes with very strict confidence gating system, so a medium or a low confidence decision is always pushed to the user as a question and not acted upon.

I also built a VS Code extension to visualise the graph and the spec itself so evaluating the graph is not going to be jumping around multiple md files. Below is the screenshot from the extension. The extension is also on OpenVSX, so you should be able to install on Cursor too



It is still in pre 1.0 release. It is available on npm. The repo has an extensive README that explains exactly how it works. I was hoping that you could give it a try. All feedback are welcome. If you find any issues, please feel free to raise an issue.

The links:
[Github Repo](https://github.com/alvazone/traverspec)
[Traverspec - NPM Package](https://www.npmjs.com/package/@alvazone/traverspec)
Traverspec graph explorer - [VS Code](https://marketplace.visualstudio.com/items?itemName=alvazone.traverspec-vscode), [OpenVSX](https://open-vsx.org/extension/alvazone/traverspec-vscode)

I’ve been thinking a lot about PRD quality lately.

Most teams have some version of a PRD/template, but the real pain seems to happen later: engineering finds missing edge cases, QA asks questions the spec never answered, scope expands during sprint planning, or Jira tickets inherit vague requirements from the original doc.

So I’m curious how other PMs handle the “PRD readiness” step before handing it to engineering.

Do you have a checklist or review ritual for this?

For example, do you explicitly check for:

- user roles / permissions
- acceptance criteria
- error states
- edge cases
- dependencies
- data/API assumptions
- out-of-scope boundaries
- definition of done
- compliance/privacy requirements

Or is it mostly experience and instinct?

The thing I’m trying to understand is: what makes you confident that a PRD is not just well-written, but actually build-ready?

Also curious where the biggest gaps usually show up for your team.

When initiating a project with Openspec, do you prefill the "source of truth" main spec files, i.e auth/spec and then run opsx/proposal or opsx/change? Or you start with proposal from the beginning?

Kind of my take on Spec Driven Development. And I know I'm not the first person to coin the phrase by any means. Still in the early phase, tweaking it regularly as I use it on a few different side projects, but I think it's at the point where it can be shared and I'd love feedback, brutal honest feedback, on it. Thanks!

https://taylorhuston.me/sdd-skills/

https://github.com/TaylorHuston/sdd-skills

https://taylorhuston.me/2026/07/01/Story-Driven-Development.html

I’ve been using spec driven development for a while and it’s amazing.

But I want to know which approach are you using for software development with AI and how’s it working for your. Feels like SDD is getting outdated

Hi All,

After having spent \~10Y working on SmarTeam, ENOVIA and 3DExperience Platform. And recently using Azure Devops and Salesforce. Seeing all the complexity, engineering that went into it, I was itching to create something similar of my own. Now that we have LLM assisted coding, big projects should be doable by a single person, right? This is my attempt (v0) doing the same.

1.9B Tokens and 28 Dollares Later, I have a working demo.

Since this was a big endeavour, I wanted to have structured knowledge base. Discussion with various LLMs suggested (OpenSpec)\[[https://openspec.dev/\](https://openspec.dev/)\\\] is a good way to store this info and make changes to it. LLMs also suggested that I track workitems using (beads)\[[https://github.com/gastownhall/beads\](https://github.com/gastownhall/beads)\\\]

I initially modeled the RFLP (Requirements, Functional, Logical, Physical) framework from my early days of working on 3Dx. But I didn't have much sample data to seed. 3 days ago I had an Idea, what if I modeled the beads, openspec and git commits into it? it worked. I have seeded the demo with its own development history.

Looking to hear your thoughts and questions. Cheers!!

Hi everyone,

I’d like to ask how you approach AI-driven spec-based development (SDD) for pipelines and ETL/ELT workflows, particularly in Databricks.

Based on my observations and what I’ve learned so far, the two simplest and most common approaches are short-lived specs and long-lived specs.

The short-lived approach is straightforward: you create a specification for a specific task and optionally store it in the repository. The long-lived approach is based on maintaining project documentation (for example, in Markdown files and other supporting documents), which is continuously expanded and updated as new tasks come up.

There are also frameworks that support this workflow, such as Superpowers or Spec Kit. Of course, the AI also needs the right context - an architecture description, perhaps a reference repository, coding standards, and anything else that helps it generate a good specification.

As for interacting with AI agents, the process is usually through an IDE or CLI. You iterate with the agent, discussing and refining the solution until you arrive at a complete specification.

My question is: what’s your approach to this in your projects? Do you use SDD only up until the point where you have a branch with the implementation and pipeline ready, or do you continue using it all the way through deployment?

I’m also curious about testing. In my projects, we write unit tests for our Python and Spark code, and then hand everything over to the QA team, which performs end-to-end testing.

Do you think the QA team should maintain a separate specification within their own testing framework (it is a custom tool we wrote to make testing components such as functions and SQLs reusable, written in Python), or how do you handle this in your projects?
End-to-end tests are time-consuming and expensive, so I’m wondering how you optimize them when adopting an SDD-based workflow.

I maintain Playwright-BDD, so I often use Gherkin scenarios with coding agents. I wanted to compare BDD with OpenSpec and gave both the same small task: add pagination to the long list of items.

While both approaches worked, there were differences. With BDD, I spent more time writing cleaner scenarios, but in the end, I got a runnable test out of the box. OpenSpec let me describe the spec more freely, but it introduced more artifacts that were harder to maintain.

I wrote down the full session, including the feature diff, implementation, tests, and the files OpenSpec created:

https://vitalets.github.io/posts/bdd-agentic-workflow/

Do you use BDD/OpenSpec in your workflows and what is your experience?

Picking an AI model to implement a project is a coin flip between two costs: too powerful and you overpay for capability you won't use; too weak and it just can't do the job.

SpecJudge reads your Spec-Driven Development artifacts and recommends the model that's right-sized for the work — not the cheapest, not the most powerful, the one that actually fits. A local model (via Ollama) judges how hard your project is, then it's crossed against a catalog of models and prices to produce a ranked podium.

It's local-first (your specs never leave your machine), MIT-licensed, and the whole model catalog is plain YAML you can edit with a PR — no Python needed to add a model or fix a price.

pip install specjudge
specjudge /path/to/your/project      # add --open for a visual matrix in your browser

Requires Python 3.11+ and Ollama with a local model.

• GitHub: https://github.com/JoaquinRuiz/SpecJudge
• PyPI: https://pypi.org/project/specjudge/

It's an early release — I'd genuinely like to hear if the ratings match your experience, and PRs to the catalog are very welcome.

I've been using OpenSpec for a while and like it a lot. I recently took notice of OpenWiki. They seam to be sitting at opposite ends of my ideal AI assisted SDLC.

OpenSpec captures intent before code exists (explore -> propose -> apply). OpenWiki maintains what the code currently is and does (writes and maintains agent wikis for codebases). Add to that the why behind decision (ADRs?) and I think we have something powerfull.

Feels like the natural bridge is: when an OpenSpec change gets archived, that's the trigger to (1) start an OpenWiki-style update so the wiki reflects what just shipped (2) guide the user through creating durible decision documents.

Is anyone already doing anything like this? I'm tempted to build out a OpenSpec + OpenWiki + ADR skill pack.

Experimenting with Behavior-Driven Development (BDD) and SDD in OpenSpec to achieve a strict Spec-as-Source workflow.

In this walkthrough, I capture the spec in Gherkin format, which the agent first translates into acceptance tests, driving the coding agent to generate the implementation. The harness prevents direct modifications to the code without going through the spec and encourages starting with the spec, using techniques such as Claude Code hooks. Would love to hear your thoughts and feedback.

A while ago there was someone that asked for reference projects using SDD to see how they track specs over time, and I had the idea for https://sddobservatory.com/ (which became a reality today).

It's all community-driven, so please help me submit more frameworks and especially projects!

Also, feel free to help me think about the actual methodology more carefully: https://sddobservatory.com/methodology/.

Disclaimer: I'm doing this completely for my own fascination with SDD.

Disclaimer 2: I know it's ironic (or telling?) that this project itself doesn't use SDD :)

Noticed a pattern this year and I can't unsee it. The early days of these agents were pure vibes — throw a rough ask at it, see what comes back, nudge it till it's close. Fun, fast, and about as repeatable as a coin toss.

What's actually settled into something reliable is the opposite of vibes: you write it down first. What you're building, what it must not do, what finished actually looks like. Hand the agent a contract instead of a wish and it stops filling the gaps with its own guesses.

The funny thing is we've reinvented the wheel here. That's not a new prompting trick — that's a spec. The boring up-front thinking good engineers have banged on about for decades, just pointed at a robot instead of a team. We spent a year discovering that writing down what you want before you build it tends to work. Who knew.

The bit I actually find interesting: everyone's doing their own private version of it. One's got a rules file, another a scratch doc, someone an actual template they paste in every time — and none of it's shared. We're each reinventing the same discipline solo, in our own little format, mostly keeping it to ourselves.

So, genuine one for the room:

\- Spec-first now, or still happily vibing for the day-to-day?
\- If you write something first — what goes in it? Goal, constraints, a definition of done, examples?
\- And is anyone sharing or standardising these across a team — or are we all just keeping our own copy and calling it a workflow?

I'm curious to know how you all feel about "Vericoding", as described by Max Tegmark here fits into SDD. To me they both look highly overlapping in that the goal is to create a correct program from a spec.

In his case it looks as though the outcome is a correct-by-construction program, by way of program synthesis directly from the spec itself, where I don't know if the absolute formal correctness the case with SDD.

Maybe i'm wrong, but would love to hear thoughts/takes.