ZeNorm vs. GitHub Spec Kit

GitHub Spec Kit is the reason this comparison is hard to write honestly. It is free, MIT-licensed, sitting around 124k stars, and it works with 30-plus agents. It popularized the phrase "spec-driven development" and largely owns it. Any argument that starts "you should pay for spec authoring instead" has to clear a high bar, and most of the arguments people make don't.

So let's be specific about where the two things actually differ, which is narrower and more mechanical than the marketing on either side suggests.

What Spec Kit is, precisely#

Spec Kit is a specify CLI (Python 3.11+, installed via uv) that drops a set of slash-command templates into your repo. You then run them inside your own agent — Claude Code, Copilot, Cursor, Gemini CLI, Codex, whichever.

The workflow is /speckit.constitution → /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement, with optional /speckit.clarify before planning and /speckit.analyze after tasks. There is a /speckit.checklist command that generates what the docs call "unit tests for English."

The critical architectural fact: there is no server. Spec Kit is markdown templates and shell scripts. State is files in your repo — .specify/, spec markdown, a tasks.md. Everything it does happens inside the agent session you are already running.

That is a genuine strength. No account, no vendor, no data leaving your machine, no monthly bill, and it composes with whatever agent you already pay for. If your objection to tools in this category is "I don't want another SaaS in my loop," Spec Kit is the answer to that objection and it is a good one.

The mechanism difference: advisory vs. enforced#

Spec Kit's quality mechanisms are templates, checklists, and [NEEDS CLARIFICATION] markers. Its own methodology document describes phase gates as constitutional compliance checks written into templates. They guide the model. They are advisory by construction.

The structural problem is not that the templates are badly written — they are written well. It is that the thing being checked and the thing doing the checking are the same model in the same context window. /speckit.analyze asks Claude to evaluate whether Claude's spec is consistent. /speckit.checklist asks the model to grade its own English. When it says the spec looks complete, that judgment is downstream of the same assumptions that produced the incomplete spec.

And the escape hatch is always open. Type "the constraints are fine, generate the tasks" and you get tasks. Not because the template failed, but because there is nothing in the system whose job is to say no — every component is a prompt, and prompts are negotiable by anyone with a keyboard.

ZeNorm's equivalent check is not a prompt. create_task is a server-side tool call, and the server rejects it outright when the intent, constraints, and acceptance sections have not each cleared a score of 0.9. The threshold is a constant in the API (SECTION_COMPLETE_THRESHOLD = 0.9), and the rejection is a literal response the model receives:

Cannot create tasks until intent, constraints, and acceptance all have
clampedScore >= 0.9. Incomplete: constraints, acceptance.
Fix/report the missing section before retrying create_task.

No task is created. There is no ID to reference, so the follow-up call that builds the dependency graph fails too. You cannot rephrase your way past it, because the process evaluating the score is not in the conversation, has no memory of your frustration, and gets nothing from ending the exchange.

This is not a claim that ZeNorm's scoring is smarter than Spec Kit's checklists. It might not be. It is a claim about where the check runs and who can overrule it, which is a different property and the only one that survives a user who is in a hurry.

Prompt-framework tools structurally cannot copy this. Adding a real gate to Spec Kit would mean adding a server, which would mean stopping being Spec Kit.

The second difference: what happens after tasks exist#

Spec Kit's /speckit.implement executes the task list in your agent. When the session ends, what you have is a repo with modified files and some markdown. There is a /speckit.taskstoissues command that pushes tasks into GitHub Issues, which is a real integration, but the spec itself doesn't learn anything from the run.

ZeNorm runs the round trip and keeps the record. Gated tasks come out with a trace graph. zenorm work — or /zenorm SPEC-KEY inside Claude Code — claims tasks against the server with atomic leases and 30-second heartbeats, so two agents can never pick up the same task, and runs your agent against the full spec rather than a task summary. The installed skill instructs that agent to run typecheck, lint, and tests before completing. Then a structured outcome posts back onto the spec — and that part is enforced: the API rejects a transition to done without one, with outcome_required.

Two honest qualifications, since this post is about the difference between advisory and enforced and it would be cheap to blur it here. The typecheck/lint/test step is an instruction to your coding agent, not something the server verifies — nothing blocks a task from closing after a failing build. And the claim/lease/heartbeat machinery is genuinely enforced in SQL (FOR UPDATE SKIP LOCKED), which matters when you leave a daemon running, and not at all if you don't.

So the verification comparison is narrower than a pitch would make it. Spec Kit's /speckit.analyze is an LLM reading artifacts and forming an opinion about them. ZeNorm's execution step points your agent at your project's real commands — exit codes rather than a model's summary — but the enforcement lives in the skill, and a determined agent can still mark a task done. The difference that is structurally enforced in ZeNorm is upstream, at create_task, not downstream at execution.

Over twenty features, the difference compounds into something structural. ZeNorm ends up with twenty specs, their grilling transcripts, the constraints you didn't think of, and the outcome of every task, feeding a knowledge graph that surfaces related prior specs when you start a new one. Spec Kit ends up with twenty directories of markdown in your repo, which is genuinely not nothing — it's version-controlled and greppable and yours forever — but it doesn't accumulate into a queryable record of decisions.

Where they're closer than the pitch admits#

Two things that are table stakes in mid-2026 and don't differentiate anything:

Repo grounding. Both read your code before producing a spec. So does Cursor's plan mode, for free. Anyone selling this as a differentiator is selling you 2024.

Asking clarifying questions. /speckit.clarify exists and works. The difference is not that ZeNorm asks and Spec Kit doesn't; it's that ZeNorm's questions arrive typed — challenge, contrarian, simplifier — one at a time with options, the agent is instructed to read your code rather than ask about things the code already answers, and the questions keep coming until the score clears — escalating in type as iterations mount, which the server drives rather than the model choosing. /speckit.clarify is a command you choose to run, and it ends when the model is satisfied.

That last clause is the whole difference restated. "Ends when the model is satisfied" versus "ends when a server-side score clears a bar."

Cost, honestly#

Spec Kit is $0 forever, MIT, and the code is on GitHub. ZeNorm is $27.99/month with the first ten specs free and no credit card. Execution runs on your existing Claude or Codex subscription — ZeNorm doesn't resell inference, because authoring is what it pays for and therefore what it charges for. See /pricing.

That gap is real and it should be the first thing in your evaluation, not a footnote. Twenty-eight dollars a month against free-and-open-source is a burden of proof, and if the gate mechanism doesn't solve a problem you actually have, the honest answer is that Spec Kit is the better purchase.

When to use Spec Kit instead#

Not rhetorical hedging — these are the cases where I'd tell you to skip ZeNorm.

You want zero vendor dependency. No account, no server, no company that can change its pricing or shut down. Your specs are markdown in your own git history. For a lot of engineers this is dispositive and no feature list overturns it.

Your constraints are already clear before you start. If your specs are good because you're disciplined, the gate is a tax on discipline you already have. Structure alone is what you need, and Spec Kit provides structure at no cost.

You want the constitution model. Spec Kit's project-level governing principles — including hard rules like tests-before-implementation — are a genuinely good idea that ZeNorm has no direct equivalent for. If enforcing architectural principles across every feature is the problem you're solving, that's Spec Kit's shape, not ZeNorm's.

You need it to run entirely offline or in an air-gapped environment. ZeNorm's authoring is a hosted service. That's a hard blocker and no amount of feature comparison changes it.

You're doing exploratory work. Prototypes, spikes, throwaway scripts. A gate that refuses vague input is exactly wrong when vagueness is the honest state of the problem.

You're already invested in the workflow and it's working. The 124k stars are not fake. If /speckit.specify → /speckit.tasks produces specs your agent implements correctly, you have solved your problem, and switching costs are real.

When ZeNorm is the better fit#

The inverse cases:

You can talk yourself past your own quality checks. If you've ever typed "yes it's fine, continue" to a clarification prompt and later regretted it, the advisory/enforced distinction is not academic — it's the description of your Tuesday.

Your acceptance criteria don't survive contact with a test. ZeNorm scores them and refuses below the bar, which in practice means "works correctly" gets rejected and you end up with something assertable. Why that's harder than it sounds: acceptance criteria that actually work.

You want the loop to close without supervision. zenorm work claims tasks under a lease, runs your agent against the full spec, and requires a structured outcome before any task closes. Start it, come back to commits.

You want to know six weeks later why a decision was made. Transcripts and outcomes persist and are queryable. Grepping twenty spec directories is not the same thing.

You don't want to maintain the scaffolding. Spec Kit is a toolkit you operate — Python, uv, templates that update, a constitution you author. ZeNorm is a service that operates on you.

The honest summary#

Spec Kit gives you the shape of a disciplined spec process for free, and the shape is most of the value for people who supply their own discipline. ZeNorm supplies the discipline mechanically, and charges for it.

The question isn't which has better templates. It's whether a check that you can overrule is a check. If you reliably don't overrule it, Spec Kit wins on cost and freedom and it isn't close. If the thing standing between you and a vague brief is your own restraint at 6pm on a Thursday, that's the specific problem a server-side gate solves, and templates cannot solve it at any level of quality.

Also worth reading: ZeNorm vs. Traycer, the closest commercial neighbour, and ZeNorm vs. AWS Kiro, which does close a loop but only inside its own IDE. If you're weighing whether structured planning is worth the ceremony at all, planning mode vs. just prompting is the more fundamental question.