ZeNorm vs. /grill-me

Matt Pocock's /grill-me is the best free articulation of the idea ZeNorm is built on: the expensive failure in agentic coding isn't bad code, it's building from an unexamined plan, and the fix is to invert the dialog — the model interrogates the human, relentlessly, before anything gets written. If you've felt ZeNorm's grilling and wondered whether a skill file could do it, this is that skill file, and it's good.

So this comparison is between two implementations of the same conviction, which makes the differences unusually easy to state precisely.

What /grill-me is, precisely#

/grill-me is a Claude Code skill — a markdown prompt, MIT-style open, no server, no account. It runs the interview as a decision tree: identify the "frontier" of questions whose prerequisites are settled, ask the whole frontier in one round, wait for answers, recompute. Each question ships with a recommended answer. Sub-agents get dispatched for anything the model can look up itself, so you're never asked for facts the filesystem already knows. The session ends when the frontier is empty — every branch explored, nothing assumed.

It's also the anchor of a larger flow documented at aihero.dev. /grill-with-docs is the stateful variant: resolved vocabulary is written term-by-term into CONTEXT.md, and decisions that clear three gates — hard to reverse, surprising without context, a real trade-off — become ADRs in docs/adr/. From there the main chain runs /to-spec → /to-tickets → /implement → /code-review: conversation into a spec issue, spec into vertically sliced "tracer-bullet" tickets with blocked-by ordering, tickets into TDD sessions at pre-agreed seams.

The philosophy is glossary-first and file-native. The durable artifacts are domain vocabulary and ADRs in git; the docs are explicit that specs are disposable — "they go stale once implementation begins."

The critical architectural fact, same as every skill-based tool: everything is a prompt, and every check is advisory. The frontier discipline, the three ADR gates, the "nothing assumed" ending condition — all of it is convention the model is asked to follow, in the same context window as the user who's in a hurry.

Where the differences actually are#

The interview itself is the overlap. ZeNorm's spec agent runs the same discipline — one question at a time, the question whose answer most changes what gets asked next, read the code instead of asking about things the code answers. If the interview were the whole product, /grill-me would be the better purchase, because it's free.

The differences are everything around the interview, and the grill stack's own documentation is unusually honest about them — honest enough that its documented pitfalls read like ZeNorm's feature list.

Decisions evaporate. The docs' stated mitigation for answers living only in conversation is "pipe the session to /to-spec immediately." In ZeNorm nothing lives only in conversation: every question is a row with typed options and a recommended answer, and every answer is a tracked, revisable, undoable application to the spec. You can change your answer to question four next Tuesday and the spec updates; a chat transcript can't do that.

Single-writer only. The docs report roughly 20% state drift on sampled merged PRs when multiple developers curate the shared CONTEXT.md and ADRs. That's not a bug in the skill — it's what file-based state does under concurrent writers. ZeNorm's specs are multiplayer by construction: real-time sync, presence, org scoping, share links. Drift between what one person decided and what the team sees isn't a failure mode that needs curating away.

No completion step. This is the sharpest single contrast, and again it's their docs saying it: /implement "has no completion step. It ends at the commit and never touches the work item… Close the ticket and reconcile the criteria yourself." ZeNorm's execution loop is built around the opposite contract. /zenorm pulls the spec, executes tasks as vertical slices, and gates completion on acceptance criteria backed by observable evidence — a task that can't meet its criteria stays active, with the failure recorded rather than papered over. A stop hook refuses to end the session until outcomes are synced back. The API rejects a transition to done without a structured outcome.

Convention vs. gate. The frontier discipline ends "when the frontier is empty" — a judgment the model makes about its own thoroughness, revisable by anyone who types "that's enough, let's build." ZeNorm's sections complete when a server-side score clears 0.9, and create_task is rejected outright until intent, constraints, and acceptance all have. The full argument for why that distinction matters more than template quality is in the Spec Kit comparison; it applies here unchanged, because a skill and a template are the same thing structurally: prose the model is asked to respect.

Traceability. /to-tickets numbers tickets and declares blockers, maintained by convention. ZeNorm keeps a typed trace-edge graph where "every task traces to at least one acceptance criterion" is a checkable invariant, plus a second graph for cross-spec dependencies — and a semantic index over the workspace surfaces related prior specs while you're being grilled about a new one.

Where /grill-me is genuinely better#

The glossary idea is the one place the grill stack has something ZeNorm doesn't. Compressing your domain's vocabulary into CONTEXT.md, term by term as it resolves, pays off for every future session — human or agent — and ZeNorm has no first-class equivalent. If building shared domain language is your actual problem, /grill-with-docs addresses it directly and nothing in ZeNorm does.

It's also model-honest in a way worth naming: the stack's docs openly debate whether the glossary even helps the agent versus just helping humans communicate. Documentation that argues against its own value proposition has earned some trust.

And the artifacts are yours in the strongest possible sense — markdown in your own git history, greppable forever, no vendor. ZeNorm's zenorm pull gives you markdown, but it's a view of the database, not the source of truth.

When to use /grill-me instead#

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

You're one person and the work fits one session. The docs themselves scope /grill-with-docs to single-session planning, and inside that scope the enforcement ZeNorm adds is solving problems you don't have. The interview is the value, and the interview is free.

Building domain vocabulary is the point. The CONTEXT.md glossary discipline is the stack's genuine invention and ZeNorm has no equivalent surface.

You want zero vendor dependency. No account, no server, no bill, artifacts in git. As with Spec Kit, for many engineers this is dispositive and no feature list overturns it.

You're already living in Claude Code and want composability. The stack is skills all the way down — it composes with whatever else is in your skills/ directory, and you can read and fork every line of it.

Exploratory work. Spikes and prototypes don't deserve a scored, phase-gated spec. A frontier of questions you can walk away from mid-round is the right weight.

When ZeNorm is the better fit#

The inverse cases, most of which the grill stack's docs concede in advance:

More than one person touches the plan. The documented ~20% drift under shared curation is the cost of file-based state. Multiplayer specs don't drift from themselves.

You need decisions to survive the session without discipline. If "pipe it to /to-spec immediately" is a step you'll sometimes skip, you want a system where skipping it isn't possible.

Completion has to mean something. "Close the ticket and reconcile the criteria yourself" is exactly the step that gets skipped at 6pm. ZeNorm's evidence-gated criteria and the stop hook exist because that step, left to discipline, doesn't happen.

You can talk yourself past your own checks. A skill's rules live in the same context window as your impatience. A server-side gate doesn't. See the Spec Kit comparison for the full version of this argument.

You want the record. Six weeks later, the question "why did we decide this" is answerable from persisted transcripts, answer applications, and task outcomes — not from grepping ADRs and hoping the decision cleared the three gates that day.

The honest summary#

/grill-me proves the interview is the right primitive, and it gives you the interview for free, in your repo, under your control. What it can't give you — and its own documentation is admirably clear about this — is anything that survives contact with hurry, concurrency, or time: decisions persist only if you pipe them somewhere, state drifts under multiple writers, and nothing enforces that finished means finished.

ZeNorm is that same interview made institutional: enforced phases, persistent revisable answers, a traceability graph, teams, and a loop that closes back onto the spec with evidence. If you're one disciplined person doing single-session work, the skill wins on cost and freedom and it isn't close. If you're a team, or your discipline has ever lost to a Thursday deadline, the enforcement is the product.

Also worth reading: ZeNorm vs. GitHub Spec Kit, the same advisory-vs-enforced argument against the biggest open-source player, and ZeNorm vs. Traycer, the closest commercial neighbour.