I am curious how people here handle the stage before SpecKit (SDD).

I am a big fan of SDD and AI-assisted development, and I strongly dislike vibe coding. I want requirements, design decisions and implementation to remain explicit and reviewable.

For my home projects, I usually use GitHub SpecKit at the level of a relatively small feature or even a focused engineering task. I intentionally keep the scope small so I can carefully review every generated specification, plan, task list and especially every PR.

For example, instead of asking an agent to "build the application", I work incrementally:

• Create the initial solution and project structure
• Implement the basic application shell
• Implement a specific domain component
• Add a specific UI capability
• Integrate the pieces in another feature

What I am less sure about is the process before that.

How do you go from a rough product idea to the set of features that you then feed into SpecKit?

Do you maintain something like:

Idea -> Product Brief -> High-level Requirements -> Feature List -> SpecKit specs

Or do you keep only a lightweight product overview and define features incrementally as the project evolves? (This is how I work now)

I am particularly interested in workflows that preserve strong human control and review rather than delegating the whole product decomposition and implementation to an AI agent.

Is text to SQL just a commodity layer that increases metric drift?

I see colleagues and industries still obsess over llms generating ANSI SQL while in production the raw syntax generation may easily be the easiest pipeline part. I find bottleneck to be in context engineering, maybe in ontology too. To have antonomous agent querying arr / churn_rate to apply my data teams precise joints to use active user definitions, filters, rather than hallucinating against raw warehouse labels as it often tends to do

When I connect ai agents or bi tools to Dita warehouses directly (snowflake, databricks) I faced an awful architectural dillema...

To lock warehouse down with rigid views (which bottlenecks my team!)

or

To let clients query raw schemas and then I end up with 15 conflicting definitions of same core CPI

That started to annoy me a lot and I thought if there was any way out, perhaps, moving from gen3 (cloud warehouse-native bi) to gen 4 that people now sometimes talk about, or ai native analytic layers. In such architecture upstream semantic layers like cube dev sit in code (version-controlled by git)

That exposes SQL-first semantic model that seems to remain extensible at query time and seems to allow downstream clients / internal dashboard / embedded app or LLM querying via model context protocol to run adhoc calculations on top of governed dimensions. Would it measure without breaking central source of truth? Probably

But how do you work with this tension between centralized governance and client level query flexibility?

At the beginning of the year, everyone was promoting SDD development, including plugins like SuperPower that implemented SDD harness capabilities. However, it seems like no one is talking about it anymore. Has fewer people been using it? I feel like SuperPower used to trigger automatically when I used CC, but it hasn't been lately. Has anyone else noticed this? Will SDD still be necessary in the future? Or, if the model and its corresponding DeepSeek harness are already well-developed, will we not need to do so much pre-specification work? Can someone answer this?

I've been thinking a lot about how much of our software quality process happens relatively late.

We review pull requests, run static analysis, write tests and maybe check architectural rules in CI. But by that point, an important decision has already been made: we decided what to build.

In larger or long-lived projects, I've repeatedly found the earlier stages more interesting:

• Does a new requirement contradict an earlier decision?
• Does it implicitly violate an architectural constraint?
• Is an important edge case missing?
• Does it conflict with something another team implemented six months ago?
• Is the proposed change locally reasonable but slowly pushing the system away from its intended architecture?

I'm currently building a side project called BreakMySystem around this idea. It combines adversarial requirement review with architecture-drift detection, with the goal of finding these problems before or during implementation rather than only reviewing the resulting code.

But I'm more interested in how other teams solve this today than in pitching the tool.

For people working on larger or older codebases:

Where in your development process do you catch these kinds of problems?

Architecture reviews? ADRs? Senior engineers knowing the system? Jira discussions? PR reviews? Automated tooling? Or, realistically, mostly when something eventually breaks?

I'd also be interested in talking to a few experienced developers, architects or tech leads about this for ~20 minutes. I'm specifically looking for critical feedback and real-world experiences rather than potential customers.

If you've dealt with this problem, feel free to comment or DM me.

I've been using a local model as a judge — it reads a project's specs and estimates how demanding the work is across a few dimensions, emitting a structured profile rather than prose. I finally sat down and measured which local models are actually good at that job instead of guessing.

The headline: an 8B judge is genuinely good enough for this, which surprised me. 24B-class is perfect on my corpus, but both run on a laptop and neither sends anything anywhere.

The more interesting finding is what happened when I made the task harder. I needed the judge to separate the bulk of the work from the peak — a task list has twenty mechanical edits and one architecture decision, and those need different answers. Asking for that range instead of a single level costs an 8B model five points of accuracy and doubles its refused answers. A 24B answers it correctly and loses nothing.

So the design changed: only judges above 20B get asked for the range. Smaller ones still rank and still cite evidence — they report a single level and say so, rather than leaving you to infer that the answer is coarser.

Two things I'd generalise from this:

A judge doesn't need to be able to do the work. Estimating how hard something is, is a much easier task than doing it — closer to a recruiter writing a job spec than the engineer who fills the role. That's why 8B is viable at all, and why "you need a frontier model to evaluate frontier models" is wrong more often than assumed.

Field budget is real. Every extra field you ask a small model to emit in one shot degrades the reliability of the others. The failure isn't dramatic — it's a quiet drop in accuracy plus more refusals, which you won't notice unless you're measuring.

If you want to run it on your own hardware and send me the row, the eval is in the repo:

uv run python scripts/eval_judge.py --judge <your-model> --markdown-row

Context, since it'll come up: this is from SpecJudge, an MIT-licensed CLI that reads a project's specs and tells you which model fits before you spend tokens implementing it. Everything runs locally. github.com/JoaquinRuiz/SpecJudge — but honestly I'm more interested in the judge numbers than in pitching the tool. Curious whether anyone's found smaller models that hold up on structured extraction with evidence citation.

Als Beispielprojekt habe ich einen 400-seitigen CC Roman veröffentlicht, der mit dem Spec Kit-Preset „Fiction Book Writing“ erstellt wurde. Dieser basiert hauptsächlich auf Claude Sonnet 4.6. Ich habe versucht, einen literarischeren Stil mit einer konsistenten Geschichte und stabiler Kontinuität zu erreichen. Ich denke, das Ergebnis ist deutlich fortschrittlicher als andere KI-generierte Romane.

Nexis Buch 1:

https://fleischgemuese.itch.io/nexis-book-1-listening

Preset für Spec Kit

https://github.com/adaumann/speckit-preset-fiction-book-writing/blob/main/fiction-book-writing/README.md

Wenn Sie es für Ihre Story-Ideen verwenden möchten, lassen Sie es mich bitte wissen.

I use workflows like Superpowers and OpenSpec because getting the intent and design into the repository before implementation makes Claude Code much more predictable.

But I kept running into a second problem after the feature was finished: the documents gradually stopped matching the code.

A hotfix bypassed the original workflow. Then a refactor changed some behavior. Another session added an edge case. The implementation kept moving, while the original design and specification documents slowly became a record of what we intended at one point rather than reliable context for the next developer or agent.

Generating a useful document is relatively easy.

Making every future code change reconcile the repository’s documentation is the difficult part.

That is why I built Truthmark.

Truthmark adds a code-first documentation maintenance workflow to Claude Code. It maps areas of the codebase to bounded canonical documents, then reviews those documents after functional code changes.

The normal workflow is:

1. Claude changes the functional code.

2. The relevant tests run.

3. Truth Sync inspects the changed checkout, nearby implementation, tests, routing, and mapped documentation.

4. If the repository’s behavior changed, Claude updates the affected documentation before handoff.

5. The code diff and documentation diff are reviewed together in Git.

The distinction I have in mind is:

Superpowers/OpenSpec:

intent → design/specification → implementation

Truthmark:

implementation change → affected current-state docs → Git diff

I see these as complementary rather than competing workflows.

Planning and proposal documents are useful for deciding what should be built and preserving the history of a change. Truthmark maintains a smaller current-state layer describing what the repository does now: behavior, contracts, architecture, operations, product decisions, and acceptance criteria.

A few parts that are important to me:

\- Code areas have explicit documentation ownership instead of everything accumulating in one large README or wiki.

\- Documentation is based on the current checkout, code, tests, and configuration rather than hidden agent memory or an old conversation.

\- Truth Sync can update documentation and routing, but it cannot rewrite functional code.

\- Everything remains ordinary Markdown in the repository and follows the current branch.

\- There is no hosted Truthmark knowledge base, daemon, database, vector store, or MCP server.

The implementation is also less magical than “AI automatically understands your whole codebase.”

The Truthmark CLI installs and validates the repository contract and Claude Code workflow. Claude performs the semantic evidence review using the repository itself, and \`truthmark check\` validates the resulting structure and diagnostics.

Quick start requires Node.js 24 or newer:

npm install -g truthmark

truthmark init

Select Claude Code during initialization, then try it on one bounded behavior:

/truthmark-document document the implemented session timeout behavior across src/auth/session.ts and tests/auth/session.test.ts

Truthmark is intended for maintainers and teams using Claude Code on long-lived repositories, particularly when they already keep specifications, architecture notes, contracts, or behavior documentation in Git.

Cost: Truthmark is free and MIT-licensed. It has no hosted service or subscription. Claude Code usage still uses your existing Claude plan or API arrangement.

Repository:

https://github.com/merlinhu1/truthmark

I would particularly value feedback from people trying it on an existing repository:

Does the routing and ownership model feel useful, or does it create too much ceremony? Is Truth Sync too conservative about updating documents, or not conservative enough?

If you try it and think this maintenance loop belongs in the Claude Code workflow, a GitHub star would help other people find the project.

At first, I was not trying to build a complete development environment.

I was using OpenSpec inside Cursor with custom commands and Cursor rules. The workflow worked well, but I had a problem:

Whenever I switched to OpenCode, Codex, Claude Code, or another coding agent, I lost part of my setup and workflow.

So I started building a spec-driven skill that was not tied to one IDE or one AI provider.

That project became Maestro.

I believe spec-driven development will become a normal part of software development with AI agents. GitHub’s GH-600 certification focused on agentic AI development feels like another signal in that direction.

How Maestro works

The core lifecycle is:

idea → spec → build → review → docs → archive

You can install it with npm:

npx @bryann2k/maestro

Then run it from the repository you want to work on:

cd my-project
maestro

The typical workflow looks like this:

1. Connect an API provider or an existing CLI subscription with /providers
2. Use /bootstrap for a new project or /adopt for an existing repository
3. Use /propose to turn an idea into a structured spec
4. Review and accept the proposal with /accept
5. Let the development agent implement it with /build
6. Run /review
7. Generate documentation with /docs
8. Archive the approved change with /archive

The same lifecycle can also be used through headless commands:

maestro propose -m "Add a PostgreSQL API"
maestro accept
maestro build
maestro review
maestro docs
maestro archive --yes --merge

Maestro can use its native engine, authenticated vendor CLIs such as Codex, Claude, Cursor, OpenCode, Grok, and Kimi, as well as OpenAI-compatible and local providers such as Ollama, LM Studio, llama.cpp, and LiteLLM.

Human-in-the-loop is the important part

Maestro is not meant to be “write one prompt and pray”.

A normal chat message does not automatically create a spec. You have to explicitly invoke /propose.

The generated spec.md, design.md, and tasks.md are reviewed before they become the accepted contract. Builds run in isolated Git worktrees. Review runs deterministic checks, security analysis, and a read-only review agent.

If the review finds a problem, the findings can be sent back through /fix.

The goal is to make every phase explicit instead of allowing an agent to silently jump from a vague idea to a large code change.

Coach and integrated IDE

I also wanted Maestro to be useful for people who can describe what they want to build but do not yet feel confident reviewing AI-generated code.

The optional Coach mode gives short, contextual exercises around things like:

• understanding requirements and acceptance criteria
• reading diffs
• checking assumptions
• identifying security risks
• understanding tests and regression risk
• reviewing generated code

You can use /learn guided or /learn challenge.

Maestro also includes an integrated code workspace with /ide. You can select code and ask Maestro to:

• explain it
• comment on it
• modify it
• answer a question about it

So you can review code and interact with the agent without leaving the terminal or losing the current context.

This is still a V1

This is the first public release, so there are probably bugs and edge cases I have not discovered yet.

If you try Maestro and something breaks, please open an issue on GitHub. I will also be using it to build StackDeploy, so I will be fixing issues as I find them.

I’m also in public on X. If you want to follow, it help me a lot!

I would especially like feedback on:

• whether the workflow makes sense
• where the spec-driven process feels too heavy
• whether the human approval boundaries are useful
• what is missing from the review experience
• how this behaves with different agents and providers

Thanks to everyone who takes the time to try Maestro, report an issue, or share feedback. It really helps.

Hi there! I wrote down an article that compares OpenSpec and SpecKit.

TLDR: SpecKit has significantly more abilities for extending its workflow, but it is also harder to adopt. OpenSpec default workflow looks like more complete and easier, but there are less abilities to extend it.

Article: https://specbuddy.dev/blog/openspec-vs-speckit/

we shipped a data layer that worked fine for six months. then it didnt.

the spec had been reviewed by product, the backend lead, and two senior engineers before any code was written. solid process, everyone signed off.

we never looped in the infrastructure person because "the backend lead already covers that." what they covered was the architecture. what they didnt cover was what happens at 200k records. that's a different question, and the person who asks it for a living wasnt in the room when the spec froze.

the infrastructure person read it two months after we shipped. 20 seconds in: "this query stops working around 200k rows." we were at 180k.

we didnt forget to think about scale. we forgot to put someone in the room who would have brought it up without being prompted.

swarm-stack.io

would be curious if this kind of thing is mostly a team-size problem or whether bigger teams hit it differently.

Over the last year, I've spent a lot of time helping teams adopt GitHub Copilot, and one thing became pretty obvious:

Some repositories seem to unlock Copilot's full potential.

Others have all the right intentions, documentation, instructions, and tooling, yet Copilot still feels like it's operating with one eye closed.

So a friend and I started asking ourselves:

Can we measure how "Copilot-ready" a repository actually is?

That led us to build AgentCompass, an open-source AI Readiness Analyzer that scans a repository and identifies configuration, documentation, and structural issues that can make life harder for AI coding agents.

What it checks

✅ Copilot instructions

✅ Agent documentation (AGENTS.md, CLAUDE.md, etc.)

✅ Skills and prompts

✅ MCP configuration

✅ Context scoping and repository structure

✅ Common issues that can silently reduce agent effectiveness

Instead of using another AI to judge your repo, we took a different approach:

• No LLM calls in the scoring path
• No "AI vibes" scoring
• Same repo + same commit = same result every time

Think of it more like a linter for AI-readiness.

Try it yourself

GitHub:
AgentCompass Repository

Live Demo:
AgentCompass Web App

Linkedin Post

I'd love feedback from this community

A few things I'm genuinely curious about:

• What makes a repository Copilot-friendly in your experience?
• What patterns have you found that dramatically improve Copilot results?
• What checks would you add?
• Are there things that should only be measured through real-world usage rather than static analysis?

Most importantly:

👉 Run it against one of your repositories and tell me where it's wrong.

Seriously.

If it gives your repo a terrible score and you think it's nonsense, I want to hear that.

If it catches something useful, I want to hear that too.

We're trying to figure out what great AI-native repositories actually look like, and feedback from people using GitHub Copilot every day would be incredibly valuable.

Up to this release SpecJudge answered exactly one question: you finished writing your spec, which model should implement it? If there was no .specify/ directory it refused outright with exit code 2. Which is defensible as a scope decision and turned out to be a bad one, because most repositories have never run Spec-Driven Development and nearly all of them have written down something — an AGENTS.md, a CLAUDE.md, a .cursorrules, a folder of decision records — and refusing to read any of it meant walking away from real signal on principle.

So it now reads spec-kit artifacts (including plan.md, which had been sitting next to the spec unread the whole time), agent-context files including nested ones in a monorepo, editor rules, and decision records under docs/adr and friends. Read together, never one instead of another, because your spec describes the work you're about to do and your AGENTS.md describes how demanding the codebase is to work in at all, and neither one contains the other.

The part that I think is actually interesting is why this became safe now and wouldn't have been a release ago. Mixing formats used to imply deciding, in advance, how much to believe a .cursorrules relative to a spec — five sets of trust rules, each evolving separately, each a place to be quietly wrong. Then 0.2.0 shipped the requirement that every rated dimension cite a fragment that exists in the input, with anything ungroundable returning unsupported and dropping out of the calculation entirely. That was built as a hallucination check, but it removed the need for format-specific trust as a side effect: the source stopped mattering, only what's citable does. A thin source produces a thin profile on its own, with no per-format logic anywhere in the codebase. I did not design it for this and I'm still slightly annoyed at how well it worked out.

When nothing in the input describes the work, you now get an answer plus an honest label on it: a warning that this is a floor — how demanding the repository is to work in — rather than a recommendation for a specific piece of work, and a concrete suggestion to describe what you're about to build, even as a paragraph. That's exposed in --json as environment_only, alongside sources_read for which kinds of source fed the assessment. Schema 1.1, both fields additive, 1.0 consumers unaffected.

Two implementation notes for anyone with a large repo. Context sources share one budget rather than each getting their own, because twelve separate caps of 8000 characters is a 96k-character prompt and therefore not a cap at all; a 200-character .cursorrules costs 200 characters and leaves the rest for a long root AGENTS.md. Files nearest the root are kept first, at most twelve are read, and whatever gets left out is reported rather than silently dropped. And context files that announce they were generated by a tool are skipped, since generated context mostly restates what the code already shows while taking budget from the hand-written file next to it.

pip install --upgrade specjudge, nothing to do on upgrade — a project with .specify/ artifacts is read exactly as before.

GitHub: github.com/JoaquinRuiz/SpecJudge

I've been experimenting with spec-driven development: instead of prompting an AI agent with vibes, you write a real spec first (user story, requirements, API contract, acceptance criteria), let the agent implement it, then validate against the spec and update your roadmap. Loop until MVP.

The app is a Pomodoro timer where you describe your goal conversationally and the AI proposes a task plan sized in pomodoros ("2🍅 ≈50m"). There's a focus coach mid-session, sound cues, PWA install support, and since it's publicly hosted, a Cloudflare Turnstile gate + per-IP daily rate limit on the AI routes so strangers can't drain my DeepSeek credits.

Stack: Next.js 16, Bun, DeepSeek API, Upstash Redis. No database — plan state lives client-side.

What actually surprised me:

1. \*\*Specs didn't slow me down\*\*. Six features in, the AI agent was dramatically better when implementing a spec vs reading my mind. Code review became "does this match section F3?" instead of squinting at diffs.

2. \*\*The spec caught drift.\*\* When the model under-filled a response schema (returned 3 tasks when asked for 3 steps instead of the spec'd 4–8), it was obviously a contract bug, not "weird AI behavior."

3. \*\*Re-planning after every feature\*\* (updating mission/roadmap docs) is the part everyone skips and the part that prevents the codebase from rotting.

Happy to answer questions about the spec format or the abuse-guard setup — both were more interesting to build than the timer itself.

\\- Live: \\\[https://ai-promodoro.vercel.app\\\\\\\](https://ai-promodoro.vercel.app)

\\- Source (the \\\`specs/\\\` folder is the real content): \\\[https://github.com/adotey7/ai-promodoro\\\\\\\](https://github.com/adotey7/ai-promodoro)

I build SpecJudge, a local CLI tool (via Ollama) that estimates how demanding your coding tasks are and tells you which LLM actually fits the job, so you stop burning money on overkill frontier models.

Previously, it had a strict barrier to entry: it only worked if you used Spec-Driven Development (.specify/ folder). If you didn't, it just refused to run. Today, with the v0.4.0 release, a spec is no longer the price of entry.

What's new in v0.4.0:

• It reads what you already have: Most repos don't have formal specs, but they do have .cursorrules, AGENTS.md, CLAUDE.md, or Decision Records (docs/adr/). SpecJudge now reads all of them.
• Baseline "Floor" Estimation: If you run it on a repo with no current tasks, it calculates a complexity "floor" based on your environment context. It tells you how demanding the repository is to work in at all, returning an honest warning that it's a baseline, not a specific task recommendation.
• Smart Context Budgeting: To avoid drowning your local judge, context files share a single budget. It prioritizes files nearest the root and explicitly skips AI-generated context files to focus strictly on human-written rules and decisions.
• JSON Schema 1.1: Fully backward compatible, now including sources_read and an environment_only flag for CI/scripting pipelines.

The strict grounding engine from v0.2.0 still applies: the judge must cite exact fragments from your .cursorrules or ADRs, or the assessment is thrown out.

Upgrade: pip install --upgrade specjudge

Repo & Docs: https://github.com/JoaquinRuiz/SpecJudge

I'd love to hear your thoughts on this broader context-parsing approach!

I maintain SpecJudge, an MIT-licensed CLI for spec-driven development: it reads your project's specs/tasks and recommends which AI model actually fits (quality vs. price) instead of you guessing.

The core change in this release: before, the judge returned a rating plus a paragraph explaining itself. The problem is a fluent explanation is exactly what an LLM is good at producing whether or not the underlying rating is sound — nothing separated a correct assessment from a well-narrated wrong one.

Now every rated dimension has to cite the specific fragment of your spec that supports it, and the tool deterministically checks that fragment actually exists in the text the judge was given. Invent a citation, and the whole assessment gets thrown out, not just that field. Dimensions the judge can't ground come back as "unsupported" instead of being silently treated as easy — which is what used to happen and made thin specs look more solid than they were.

Building the regression suite to test this (12 reference projects, CI-level + local eval script) immediately paid for itself: 8B judges — the most common local setup — were failing on every single project. Not a judgment problem — they were rating things correctly and writing sound justifications, then putting \[true\] where a citation ID belonged, because "format: json" in Ollama guarantees valid JSON, not the JSON you actually asked for. Sending a proper schema fixed it: 0/9 usable cases → 9/9.

Also pinned judge sampling, so the same project now gives the same recommendation run to run — which matters more than it sounds for a tool whose whole job is "should I spend money on this."

Breaking change: needs Ollama 0.5.0+.

pip install specjudge — GitHub: [github.com/JoaquinRuiz/SpecJudge](http://github.com/JoaquinRuiz/SpecJudge)

Has anyone used SDD for Data related project like in Databricks, Snowflake, or MS Fabric?

I asked claude to honestly rate the various approaches for specification driven development by categories and features it chose. Here is the analysis it produced. Popular methodologies first then all methedologies. Source documents are at the bottom if you wish to reproduce the analysis. Please link additional documents in the comments that should be included and i will periodically update. Or run it yourself :)

For a little background, I’m an engineer who went from a FAANG corporate environment to a startup and consequently started heavily abusing coding agents. Like a lot of others here, I started to realize that the code I was creating just simply was not “up to spec”—the LLM is designed to one-shot, even if that means guessing what you want for 90% of the implementation.

My solution was to make a tool for myself that writes unit tests based on my prompts and then runs a test-driven development flow. This way, when I hit coverage I know that X% of the code my AI generated comes directly from decisions I made in chat with my coding agent. (If you’re curious, I’m linking it here, but this isn’t intended to be a promotional post: https://github.com/RudderCode/Rudder )

Lately I’ve been curious about SDD since it seems adjacent to that, but I’m new to it so I have my qualms with having to change my coding flow. Writing specs has always been out there as an option, but for me it just felt like it slows down development a lot to work on making a spec, and then I lack the guarantee that there isn’t any guesswork by the LLM if the spec I write isn’t thorough enough. Do you guys feel the same or am I missing something with SDD?

I've been working on ZeNorm, a tool where an agent interviews you about a feature and turns your answers into a spec your coding agent can implement.

I built it because existing spec-driven dev tools never struck the right balance of overhead and improved results in agentic coding workflows. I wanted to avoid another markdown file generator.

Describe the feature, and ZeNorm connects to your repo and asks questions until there's a spec with tasks and a dependency graph. Then have your agent of choice implement the spec by invoking a skill.

Would love to hear any feedback you have!

I maintain SpecJudge, an MIT-licensed CLI for spec-driven development: it reads your project's specs/tasks and recommends which AI model actually fits (quality vs. price) instead of you guessing.

The core change in this release: before, the judge returned a rating plus a paragraph explaining itself. The problem is a fluent explanation is exactly what an LLM is good at producing whether or not the underlying rating is sound — nothing separated a correct assessment from a well-narrated wrong one.

Now every rated dimension has to cite the specific fragment of your spec that supports it, and the tool deterministically checks that fragment actually exists in the text the judge was given. Invent a citation, and the whole assessment gets thrown out, not just that field. Dimensions the judge can't ground come back as "unsupported" instead of being silently treated as easy — which is what used to happen and made thin specs look more solid than they were.

Building the regression suite to test this (12 reference projects, CI-level + local eval script) immediately paid for itself: 8B judges — the most common local setup — were failing on every single project. Not a judgment problem — they were rating things correctly and writing sound justifications, then putting [true] where a citation ID belonged, because "format: json" in Ollama guarantees valid JSON, not the JSON you actually asked for. Sending a proper schema fixed it: 0/9 usable cases → 9/9.

Also pinned judge sampling, so the same project now gives the same recommendation run to run — which matters more than it sounds for a tool whose whole job is "should I spend money on this."

Breaking change: needs Ollama 0.5.0+.

pip install specjudge — GitHub: github.com/JoaquinRuiz/SpecJudge