The Karpathy rubric, scored: twelve regexes deciding pass or fail.

Every published version of Karpathy's CLAUDE.md rubric does the same thing: lists the rules, gives a failure mode for each, names a source, and stops. The rubric is aspirational on the page where you read about it, and you have no way to find out whether your file passes without re-reading both end to end and guessing.

ccmd turns each of the twelve rules into one regex. Match means pass. Miss means fail. The score is a count. That is the entire scoring mechanism. The rest of this page is the twelve patterns, the count function, what a real run looks like, and the parts the score cannot tell you.

1. The rubric as twelve regex tests

The shape is an array of twelve objects. Each object has an id, a rule name, a description, and a test function that takes the file as a string and returns a boolean. Four of the twelve, byte for byte:

A regex is a strong choice for this kind of pre-flight test for one reason and one reason only: it runs in the browser, in microseconds, with no network call and no LLM judge. The whole analyzer is a 322-line pure file. The cost of a rubric pass is roughly nothing, and you can run it after every edit while you are still typing.

2. The twelve regexes, each rule's pass criterion

Left column: the rule name. Middle column: the literal pattern from src/lib/analyzer.ts. Right column: the human-readable version of what makes the rule pass. Read top to bottom; the first time you see a phrase in your file is the moment that rule goes green.

Row 9 (Stack Awareness) is the only one with a fixed vocabulary list. The others are short alternation patterns covering two to six common phrasings for the rule. If your CLAUDE.md says "think first, then code" you pass rule 1. If it says "reason through it before editing", you do not, even though the intent is identical. The rubric is a coverage smoke test, not a semantic one.

3. The scorer is eight lines

Map the array to a list of pass results, filter for the truthy ones, count the length. That is the entire function:

There is no weighting (rule 11 counts the same as rule 1), no proximity check (a match in the middle of a 9,000-line file counts the same as a match in the first paragraph), and no recurrence requirement (one match counts the same as forty). The score lives in a single integer field on the result object, rubricPassed, and the homepage renders it as {rubricPassed}/12 karpathy in the header chip row.

4. What a 4-of-12 run looks like

One paste of a real CLAUDE.md, the rubric panel expanded. The four passing rules and the eight failing ones, plus the cheapest sequence of edits to bring the score up:

Four added lines, roughly thirty tokens. The rubric moves from 4 of 12 to 8 of 12 without changing anything else in the file. Whether the agent actually plans before coding is a separate question; the rubric is satisfied either way. That is the next section.

5. What the score cannot tell you

A passing rule means the trigger phrase is in your file. It does not mean the surrounding context makes the rule load-bearing for the agent. A CLAUDE.md that opens with "always plan before editing" and then runs for 180 lines of contradictory aspirational rules will still pass rule 1, and the agent will still skip planning. The score is a necessary condition, not a sufficient one.

The rubric also says nothing about token cost. A 12-of-12 file can be 9,000 tokens of duplicate rules and dated lines at the top; the rubric reports 12, the per-line scan reports cache_bust, duplicate, and bloat findings that make the file three times more expensive per turn than it needs to be. Run both: the rubric for coverage, the per-line scan for waste. They look at the same file through different lenses.

And the rubric is a fixed twelve. The community extension stopped at twelve because Karpathy started with four and the community extended it once. There is no theoretical reason the right rubric for your codebase is exactly these twelve rules. The right one is probably some of these twelve plus a handful of failure-mode rules drawn from your specific incidents. We have a longer take on this at /t/claude-md-accuracy-gain-audit.

6. Using the score honestly

1. Paste the file. Read which rules failed. For each failure, ask whether the rule actually matters for your project. Some genuinely do not (you may have no past failures to call out yet; rule 11 can stay red without harm).
2. For each failure that does matter, write the rule the way you would write it for a new hire, not the way the regex wants it. The phrase the regex looks for will probably show up naturally; if it does not, that is fine, the rule still works for the agent even if it stays red.
3. Re-paste. The rubric should move. The per-line scan should not have grown. If the per-line scan grew (a new bloat line, a duplicate of an earlier rule) you have just paid tokens to pass a rubric check. Strip and try again.
4. Stop at the rubric score that matches the work you actually do. 7 or 8 of 12 is normal for a tight file; 12 of 12 is suspicious and usually means keyword-stuffing.

The full twelve rules with failure modes and source citations live at /karpathy-rules. The polyglot per-line scan is at /t/agent-config-token-bloat-audit. The per-turn cost math is at /t/claude-md-per-turn-token-cost.