The CLAUDE.md owner audit: who added this line, and is it still true?

A CLAUDE.md has no CODEOWNERS file. It has no review gate, no test that fails when a line goes wrong, and no owner of record. It grows the way scar tissue grows: every engineer appends a rule, nobody deletes one, and after a few months the file is a sediment of decisions that made sense on the day they were written. The lines still fire. They are still billed on every turn. But nobody can tell you, line by line, which ones are still true.

An owner audit fixes that. It is not a vibe check and it is not a prompt you paste into the same model that has been ignoring half the file. It is two deterministic passes stacked together: git blame for the human owner, and a line-level analyzer for the patterns stale lines leave in the text. This page walks the audit end to end on a small example file, and shows the exact part ccmd.dev automates.

How a line goes stale

No line is born stale. Staleness happens to a line, slowly, while the repo moves and the file does not.

The line never broke a build. No tool went red. It just quietly stopped being true, and kept getting paid for. That is the failure mode an owner audit is built to catch.

The file under audit

Thirteen lines from a small payments repo. It reads fine. It is not. Three of these lines are stale and one is a duplicate, and you cannot see which from the text alone.

Pass 1: establish ownership with git blame

The file itself has no ownership metadata. Git does. One command turns the anonymous file into an annotated one: every line gets the commit, the author, and the date it last changed.

Read the dates, not the rules. Today is 2026-05-18. The seed:staging line is from Priya in August 2025, untouched for nine months. The old-billing-client prohibition is from the same commit, equally cold. And look at the last line: an intern re-added the seed:staging rule in February 2026, a verbatim copy of Priya's line from six months earlier. Two authors, same rule, neither aware of the other. That is the concatenation scar of a file with no owner.

Sort the blame output by date. Anything that has not been touched in roughly six months is not automatically stale, but it is stale-suspect: no one has re-confirmed it in a long time, and the repo has shipped a lot since.

Pass 2: flag the text fingerprints with ccmd

Stale lines leave marks in the text itself, and three of them are detectable without ever seeing the repo. Paste the file into the analyzer on ccmd.dev. It runs entirely in the browser, no upload, and reports them in roughly a fifth of a second.

Three of the seven finding kinds in src/lib/analyzer.ts are staleness fingerprints, and this file trips all three:

• cache_bust on L12. The check at analyzer.ts line 194 scans the first 20 lines for an ISO date or the words today, this session, right now. Today we are mid-migration is a fact with an expiry date. It is the highest-severity finding because it is both stale and it voids the prompt cache every session.
• duplicate on L13. The check at analyzer.ts line 207 lowercases every non-trivial line and flags the second occurrence. It is the exact detector for the two-authors-one-rule pattern that git blame just exposed.
• missing_why on L8 and L9. The check at analyzer.ts line 227 flags a prohibition whose next four lines contain no because, why, reason, or incident. A rule with no recorded reason cannot be judged stale. You can only guess. That is the worst possible state for an owner audit.

The bundled sample in the same analyzer file makes the point against itself: its final line (analyzer.ts:321) reads Today is 2026-05-17 and we are mid-sprint on the subscriptions rewrite. A line accurate for exactly one calendar day, shipped inside the tool that flags it.

Pass 3: cross-check named artifacts against the repo

ccmd cannot see your repository, and that is by design: nothing leaves your browser. So the analyzer cannot tell you that a script a line names was deleted. This pass is yours. For every line that names a script, a path, a file, or an env var, ask the repo whether it still exists.

Two greps settle it. The seed:staging script is not in package.json, so the L4 and L13 rules instruct the agent to run a command that will fail. The old billing client cannot even be grepped, because the rule never named a path, only a vague "old billing client". That vagueness is itself a finding: a line you cannot mechanically check is a line that will outlive its own truth.

Pass 4: give every survivor an owner and a reason

Deleting the dead lines is the easy part. The pass that makes the next audit possible is rewriting the survivors so they carry their own evidence. A line that records who, why, and when can be judged stale in five seconds next quarter. A line that records nothing can only be argued about.

After the four passes the example file drops from thirteen lines to eight, the two dead rules are gone, the duplicate is gone, and every remaining line either names something the repo still has or records why it is kept. The token saving is real but it is the smaller win. The bigger one is that the file is now something a person can stand behind, line by line.

The audit, as a pipeline

Three inputs feed one judgement and produce three actions. No step replaces another. git blame answers who, the analyzer answers what the text shows, and the grep answers what the repo still has.

Why not just run an audit prompt?

The most common advice online is to invoke an audit skill: a prompt file that asks Claude to read its own config and report what looks stale. It is better than nothing. It is also the same model that has been ignoring half the file, now grading the file. Here is what an owner audit gives you that a judgement prompt cannot.

Making the audit continuous

A one-time audit decays. The file was clean the day you ran it and starts collecting orphan lines the next morning. The free analyzer on ccmd.dev is the one-shot pass. The paid tier, 9 to 19 dollars a month solo and 49 for a team, closes the loop so the file cannot rot silently between audits.

• Pull request diff comments. When a PR adds or changes a CLAUDE.md line, ccmd comments inline. The new line gets a reviewer and a recorded reason at the moment it lands, which is the only moment the author still remembers why.
• Weekly drift email. A scheduled re-run that surfaces lines that have aged past your threshold or whose token weight has crept up since the last audit.
• Per-engineer attribution. For a shared file, the report ties each line, and its token cost, back to the engineer who added it. The owner question stops being a git blame you run by hand.