Score the CLAUDE.md and AGENTS.md files you never audited.

Most config files are unaudited. You wrote one when you set up the repo, it grew a section every time the agent did something annoying, and nobody ever ran a number on it. The advice you find for fixing that is all qualitative: keep it short, be specific, delete dead rules. True, and none of it tells you where you are starting from. An audit gives you a starting number. This page is about that first number, what it almost always is, and why.

1. The unaudited baseline is 2 out of 12

We collected five config files that were written by hand and had never been scored against a rubric. Different repos, different authors, different stacks: Next.js, Go, Python FastAPI, React. One of the five is ccmd's own bundled sample. We pasted each one, unedited, into the analyzer.

Every file landed on the same number. Not close to the same number. The same number. A 56-token .cursorrules and a 280-token CLAUDE.md both scored 2 out of 12. And it is not only the score that matched. All five files missed the identical set of ten rules. The two rules they passed were the same two rules across the board.

The one rule a hand-written file reliably earns is R9, stack awareness. Its regex looks for a named language or framework, and every file lists one, because describing the stack is the obvious thing to do when you write a config file. So the floor is not zero. It is the score of someone who did the obvious thing and stopped there. That is what unaudited means in practice: not empty, just never measured.

2. Why every unaudited file lands in the same place

The score is identical across five files because the rubric tests for the presence of specific rules, and the rules a hand-written file skips are skipped for the same reason every time. They do not feel like things you put in a config file. Here are the ten that all five files missed, grouped by what they are actually asking for.

The rubric is one of two layers. The other is a per-line scan, and it is where the lines you already wrote show up as problems rather than absences. The bundled sample returned 18 of these findings: 10 aspirational (an absolute like "always" or "never" with no escape clause), 5 vague (a soft word like "properly" or "appropriately" the agent cannot test itself against), and 3 missing-why (a prohibition with no reason attached). An unaudited file is not just missing the ten rules. The lines it does have are mostly the wrong shape: "always write clean code" is aspirational and vague in a single five-word line. The scan names every one with a line number.

3. The analyzer never reads your filename

Look at the first column of the scan again. The file named SAMPLE_CLAUDE_MD was detected as a .cursorrules file. That is not a mistake. ccmd's analyzer never sees a filename. It reads the first 300 characters of whatever you paste and routes by content. The detector flips to .cursorrules when the input opens with the phrase You are an expert, because that opening is the .cursorrules idiom. The bundled sample, a constant literally named SAMPLE_CLAUDE_MD in src/lib/analyzer.ts, opens with "You are an expert TypeScript engineer", so it classifies as .cursorrules.

This matters when you have several files to score. You do not have to tell the analyzer what each one is. Paste a file, named or unnamed, and it picks the right header on its own. The score does not change with the label; the same 12 rules run on all four formats. Detection by content is also why scoring a directory full of files is just paste, read, paste the next one. Every config file you have ever written is unaudited until a number says otherwise, and the number is the same kind of number regardless of which tool the file was written for.

4. Why the score holds still when you run it twice

The other common way to audit a config file is to ask an LLM to grade it: paste the file into a chat with a rubric prompt and read the score it gives back. That works once. It does not work as a baseline, because the baseline has to hold still so a later version can be compared against it. ccmd's score is a set of regex tests, so the same file always returns the same number.

For a file you are auditing for the first time, determinism is the whole point. The 2/12 is not an opinion about your file. It is a fixed coordinate. Make four edits, re-paste, and any movement you see is movement you caused. An LLM-graded audit cannot give you that, because it cannot tell you whether a 2-point jump came from your edits or from the grader having a different day.

5. Score your own files

The point of a baseline is that you take it before you change anything. Do not tidy the file first. The unedited score is the one worth knowing.

Once you have the baseline, the route up is short. The single highest-leverage move is the pair the "memory of failure" card describes: one line recording a real past incident, and one line telling the agent to append future lessons to the file itself. After that, a tests-must-pass line, a completion condition, and a one-line plan step are each a single sentence that flips a rule. Five or six sentences is usually the difference between 2/12 and the high single digits. The config audit walkthrough covers the full rubric and the fix order line by line.