{"slug": "i-made-claude-code-refuse-to-write-code-unless-the-ticket-scores-80-100", "title": "I made Claude Code refuse to write code unless the ticket scores 80/100", "summary": "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.", "body_md": "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.\nThe recurring pattern looked like this:\nThe 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.\nSo 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.\nThe premise: no code is written until the ticket passes a gate.\nThe gate scores every ticket against 6 orthogonal dimensions, 100 points total:\nThe score decides what happens:\narchitect\nsubagent (Opus, read-only) drafts a plan before any write action.builder\nsubagent (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.\nThe score is not a vanity metric. The line that ended up at the top of the rubric file:\nA ticket that scores 95 and breaks production is worse than one that scored 65, was flagged, and got a plan first.\nHere's a ticket I rejected on myself: \"Add password reset email.\"\nKERNEL pass:\nClarity 15 / 20 \"Reset\" undefined — link only, or full flow + template?\nScope 10 / 20 No mention of expiry, rate limits, or email provider\nContext 8 / 15 Doesn't say which auth provider or where templates live\nRisk 5 / 15 Auth flow + email = high risk, not addressed\nValidation 8 / 15 \"Make it work\" isn't testable\nPriority 12 / 15 Active KPI\n─────\n58 / 100 → REJECT\nForgekeel refused to touch code. I rewrote the ticket as I would have if a junior asked me to spec it properly:\nClarity 19 / 20 Add `/reset-password` flow: email link with 30-min expiry token\nScope 18 / 20 This ticket: link email only. Excluded: SMS, recovery codes\nContext 14 / 15 Supabase Auth `resetPasswordForEmail`. Template in /emails/\nRisk 13 / 15 Rate-limit 3/h per email. No token leak in logs. RLS audit\nValidation 13 / 15 Cypress: request reset, click link, set new password, login\nPriority 13 / 15 Unblocks login retention KPI\n─────\n90 / 100 → EXECUTE\nSame 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.\nThis is what KERNEL really is: the difference between debugging in your editor and debugging in production.\nKERNEL is the most distinctive piece, but the methodology has more:\narchitect\n, security-auditor\n, and ui-reviewer\nnever modify files — their job is to think, not type. builder\n, tester\n, and designer\ncan write, but only after the read-only review./design-iterate\nrefuses to run because the designer\nwould hallucinate values.learnings.md\nfile. 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.\nForgekeel is opinionated and stack-locked to Next.js + Supabase + TypeScript + Tailwind v4 + shadcn/ui + pnpm.\nThat's deliberate. The agents reference specific patterns (Server Actions, RLS on every table, Tailwind @theme\ntokens). 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.\nMIT, v0.1.0, used internally on real projects before this release.\nRepo: https://github.com/forgekeel/forgekeel\nnpm: https://www.npmjs.com/package/forgekeel\nI'd genuinely value feedback on:\nIf KERNEL stops one ticket from shipping broken to your users, my week was worth it.", "url": "https://wpnews.pro/news/i-made-claude-code-refuse-to-write-code-unless-the-ticket-scores-80-100", "canonical_source": "https://dev.to/lex_cano/i-made-claude-code-refuse-to-write-code-unless-the-ticket-scores-80100-45lh", "published_at": "2026-05-23 10:21:43+00:00", "updated_at": "2026-05-23 11:04:23.277343+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "large-language-models", "open-source"], "entities": ["Claude Code", "Forgekeel", "KERNEL", "Opus", "Sonnet"], "alternates": {"html": "https://wpnews.pro/news/i-made-claude-code-refuse-to-write-code-unless-the-ticket-scores-80-100", "markdown": "https://wpnews.pro/news/i-made-claude-code-refuse-to-write-code-unless-the-ticket-scores-80-100.md", "text": "https://wpnews.pro/news/i-made-claude-code-refuse-to-write-code-unless-the-ticket-scores-80-100.txt", "jsonld": "https://wpnews.pro/news/i-made-claude-code-refuse-to-write-code-unless-the-ticket-scores-80-100.jsonld"}}