Your CLAUDE.md is ignored because it is too long

Paste it below. You get a bloat score, the exact lines to delete, the lines to move out of context, and a trimmed file you can commit. Free, no account, nothing leaves your browser.

Runs in your browser · no upload, no account

The whole market sells you the opposite of this

Count the pitches. One competitor advertises 10,000+ community rules. Another sells "50 to 100+ lines of real rules, not a skeleton". A third generates ten formats at once and stacks MCP servers, hooks and reviewer agents on top. Volume as proof of quality.

It is the wrong metric, and that is not an opinion. It is how the file is used. CLAUDE.md is read into context at the start of every session. Every line you add competes with every other line for attention, including the two lines that actually matter. That is why the symptom people report is always the same one: Claude ignored my rule. The rule was there. It was buried.

So this tool does the unglamorous half nobody sells: it takes things out. Anthropic's own memory documentation argues the same thing: keep it concise, because it is loaded every time. We just made it measurable.

What each verdict means

The three verdicts and what to do with them
VerdictThe test it failed or passedYour move
keep Removing it would make the agent do the wrong thing — a command, a path, a "never do X". Leave it. This is the file.
cut Removing it changes nothing: default behaviour, a duplicate, prose, or a restatement of package.json. Delete. It is not free weight — it is competition.
offload True and useful, but only in some sessions: a deploy runbook, a schema dump, an endpoint list. Move it to its own file, reference it with @docs/deploy.md, let it load on demand.

The rules the parser applies

No model call, no black box. It is a set of pattern rules you can read in /audit.js. Roughly, it flags:

  • Role-play preambles — "You are an expert senior developer". CLAUDE.md is project memory, not a system prompt.
  • Default behaviour — "write clean code", "use meaningful names", "handle errors gracefully". The model already tries to.
  • Manifest restatements — a bullet list of your dependency versions, which the agent can read from the lockfile.
  • Emphasis inflation — more than five IMPORTANT / ALWAYS / NEVER in one file. Contrast only works when it is scarce.
  • Duplicates — the same instruction twice, usually because it was ignored the first time. It will be ignored twice.
  • Pasted file trees and schema dumps — the repo already holds the truth, and the copy goes stale on the next migration.
  • Code blocks over 12 lines — real content, wrong container. Put it in a file, keep one line saying when to open it.
  • Situational sections — "Troubleshooting", "Migration guide", "Getting started". Needed sometimes, loaded always.

Where the parser cannot tell, it says so and keeps the line. It marks it unverified and hands the removal test back to you. We would rather return a file three lines too long than delete the one rule that mattered. A paste gives us no way to know your repo.

Honest limits

This is pattern matching, not comprehension. It cannot know that your "always run the migration first" line is critical because of a bug you hit in March. It never rewrites. It only removes and reorders, so the output is your words. The token count is an estimate at ~4 characters per token; treat it as a budget gauge, not a bill. Read the flags, argue with them, keep what you disagree with.

Frequently asked questions

What does the bloat score measure?

The share of your file's estimated tokens that we classify as cut or offload. A file at 60% bloat still works — it just spends 60% of its context budget on lines that would not change what the agent does if you deleted them.

Why does file length matter at all? Context windows are huge.

CLAUDE.md is loaded at the start of every session, so its cost is paid on every task, and the model has to find your two real rules inside it. A long window means the file fits. It does not mean the file is read the way you hope.

What is the test you apply to each line?

Would removing this line make the agent do the wrong thing? If not, it is decoration. "Write clean code" fails the test — the model already tries to. "Never import from src/legacy/*" passes it: nothing in the repo says so.

What is the difference between "cut" and "offload"?

Cut means the line carries no information the agent lacks — delete it. Offload means the line is true and useful but only matters in some sessions, like a deploy runbook. Move it to its own file and reference it so it loads on demand.

Why do you flag my database schema and file tree?

Because both have a source of truth already in the repo, and both drift. A pasted tree is wrong one week after the first refactor, and then it is worse than nothing — the agent trusts it.

Why flag lines that just list my dependency versions?

package.json, composer.json and requirements.txt are in the repo and the agent reads them. Keep a version line only when the pin has a reason the file cannot express, like "stay on 8.0.2, 8.1 breaks the iOS build".

You told me to cut my IMPORTANT lines. Why?

We only flag them when there are more than five in the file. Emphasis is a contrast effect: if nine rules are IMPORTANT, none of them stand out. Keep the caps for the two that actually burned you in production.

Is my file uploaded anywhere?

No. The parser is a JavaScript file your browser downloads once, and the analysis runs on your machine. There is no request, no logging, no account. Open devtools and check the network tab.

How accurate is the token count?

It is an estimate at roughly 4 characters per token, which is the usual rule of thumb for English prose. Code and tables run denser. Treat it as a budget indicator, not a billing number.

Where do the 200-line and 60-line numbers come from?

They are our thresholds, not a spec. 200 is the point past which we have never seen a memory file that was not mostly padding; 60 is where a trimmed file usually lands once the situational parts are moved out. Anthropic's own memory documentation makes the same argument qualitatively: keep it concise, because it is loaded every time.

The tool marked a line "unverified". What do I do?

We could not tell whether it is load-bearing, so we left it in rather than guessing. That is your call — apply the removal test by hand. We would rather hand you a file with three extra lines than silently delete the one rule that mattered.

Does this work on .cursorrules, AGENTS.md or copilot-instructions.md?

Yes, mechanically — they are all Markdown loaded into an agent's context, and the same padding shows up in all of them. The offload advice is Claude Code-specific though: the @file reference syntax is what makes on-demand loading work there.

Can it rewrite my rules, not just cut them?

No. It removes and reorders; it never writes a line you did not write. Rewriting your rules from a paste would mean inventing project facts we do not have. That is exactly the failure mode we are arguing against.

Why does the trimmed output drop some of my headings?

If every line under a heading was cut or offloaded, the heading has nothing left to introduce. An empty "## Best practices" section is pure token cost.

What does the paid generator do that this does not?

This audit only reacts to what you already wrote. The generator asks you 117 questions about the project and writes the specification behind the rules file — database schema, auth flows, security and legal requirements. Two generations are free with an account; unlimited is $19/month or $99 once.

Cutting is the easy half. Writing the rules is the hard one.

The audit reacts to what you already wrote. The generator asks 117 questions about your project and writes the specification behind the rules file: database schema, auth flows, security, legal, file structure. 2 free prompts with an account, no card.

Generate a real one, free