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

The article describes Forgekeel, an open-source methodology that prevents Claude Code from writing code until a ticket scores at least 80/100 on a six-dimensional quality gate called KERNEL. The system evaluates tickets across Clarity, Scope, Context, Risk, Validation, and Priority, rejecting vague specifications (like a 58/100 "password reset" ticket) while approving detailed ones (90/100) that force developers to address edge cases, security, and testing before any code is written. The approach aims to replace "vibe-coded" software with disciplined, spec-driven development by treating tickets as formal specifications rather than prompts.

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 recurring pattern looked like this: 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. 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: architect subagent Opus, read-only drafts a plan before any write action.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. 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. KERNEL is the most distinctive piece, but the methodology has more: 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./design-iterate refuses to run because the designer would hallucinate values.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 README. Forgekeel is opinionated and stack-locked to Next.js + Supabase + TypeScript + Tailwind v4 + shadcn/ui + pnpm. That's deliberate. The agents reference specific patterns Server Actions, RLS on every table, Tailwind @theme tokens . If I made them stack-agnostic, the methodology would become advice instead of execution. Adapting to a different stack means editing the agents directly — there's no abstraction layer planned. MIT, v0.1.0, used internally on real projects before this release. Repo: https://github.com/forgekeel/forgekeel npm: https://www.npmjs.com/package/forgekeel I'd genuinely value feedback on: If KERNEL stops one ticket from shipping broken to your users, my week was worth it.