I made Claude Code refuse to write code unless the ticket scores 80/100

I've been using Claude Code daily on real projects for several months. It's excellent. It's also a brilliant improviser — and that's the problem.

The failure mode

The recurring pattern looked like this:

• I'd write a vague ticket. Claude Code would happily start coding.


• It would ship something close to what I asked, but not quite.


• It would touch files I hadn't anticipated.


• Security and UI review lived in the same head as the implementation — so nothing caught the obvious.


• Each session forgot what the last one learned. The same bugs reappeared in different forms.

The model wasn't wrong. The workflow was wrong. I was treating a senior pair programmer like a junior who'd guess if I was unclear. The result was a slow drift toward "vibe-coded" software — superficially impressive demos that broke when they met real users.

So I stopped treating each ticket as a prompt and started treating it as a spec. The methodology that came out is now open-source. It's called Forgekeel, and the core idea is a quality gate I named KERNEL.

KERNEL: a scored gate before any code

The premise: no code is written until the ticket passes a gate.

The gate scores every ticket against 6 orthogonal dimensions, 100 points total:

The score decides what happens:

• 
  < 60 → reject. Return to me with concrete flags per dimension.


• 
  60–79 → conditional. The architect subagent (Opus, read-only) drafts a plan before any write action.


• 
  ≥ 80 → execute. The builder subagent (Sonnet) proceeds directly.

The 6 dimensions are orthogonal. You can't compensate for low Risk with high Clarity — a ticket with Clarity 20 and Risk 5 still totals well numerically, but the low Risk forces an architect review before any DB or auth touch.

The score is not a vanity metric. The line that ended up at the top of the rubric file:

A ticket that scores 95 and breaks production is worse than one that scored 65, was flagged, and got a plan first.

A concrete example

Here's a ticket I rejected on myself: "Add password reset email."

KERNEL pass:

Clarity      15 / 20   "Reset" undefined — link only, or full flow + template?

Scope        10 / 20   No mention of expiry, rate limits, or email provider

Context       8 / 15   Doesn't say which auth provider or where templates live

Risk          5 / 15   Auth flow + email = high risk, not addressed

Validation    8 / 15   "Make it work" isn't testable

Priority     12 / 15   Active KPI

                       ─────

                       58 / 100   → REJECT

Forgekeel refused to touch code. I rewrote the ticket as I would have if a junior asked me to spec it properly:

Clarity      19 / 20   Add `/reset-password` flow: email link with 30-min expiry token

Scope        18 / 20   This ticket: link email only. Excluded: SMS, recovery codes

Context      14 / 15   Supabase Auth `resetPasswordForEmail`. Template in /emails/

Risk         13 / 15   Rate-limit 3/h per email. No token leak in logs. RLS audit

Validation   13 / 15   Cypress: request reset, click link, set new password, login

Priority     13 / 15   Unblocks login retention KPI

                       ─────

                       90 / 100   → EXECUTE

Same problem, two tickets, two outcomes. The first version would have shipped something. Probably without rate limits, without auditing whether the token could leak into logs, with "manual testing" as the validation step. The second version forces every gap shut before the IDE opens.

This is what KERNEL really is: the difference between debugging in your editor and debugging in production.

Around the gate

KERNEL is the most distinctive piece, but the methodology has more:

• 
  7 specialized subagents with enforced read-only vs write roles. architect, security-auditor, and ui-reviewer never modify files — their job is to think, not type. builder, tester, and designer can write, but only after the read-only review.


• 
  A per-project constitution declaring stack, non-negotiable principles, design tokens, allowed/forbidden MCPs. Every agent reads it before acting. Without it, /design-iterate refuses to run because the designer would hallucinate values.


• 
  A learnings loop. Every closed ticket appends "what went wrong / how it was resolved / what not to repeat" to a learnings.md file. By ticket 20, the project has a written history of bugs it should never re-introduce. Future sessions read it as part of context.

Full breakdown in the

npm: https://www.npmjs.com/package/forgekeel

I'd genuinely value feedback on:

• The KERNEL rubric — would you weight the dimensions differently? Blind spots in the 6?


• Anyone running similar structured workflows on Claude Code — what worked, what didn't?


• The subagent setup — what's missing for your daily loop?

If KERNEL stops one ticket from shipping broken to your users, my week was worth it.