claude-md-hygiene
Skill2 starsChanged 2 months agoMITView on GitHub
How to cut a CLAUDE.md without losing a fact — the four-bucket taxonomy, the trigger-line shape that makes an extracted skill actually load, the gitignore prerequisite, and the line-coverage check that must be made to fail once. Load before editing, restructuring or pruning any CLAUDE.md, or when claude-md-weight.sh reports a file over threshold.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- loonylabs-dev/claude-setuptheir own version, first seen Nov 1, 2026
- loonylabs/claude-setuptheir own version, first seen Oct 17, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- loonylabs-dev/claude-setup★ 0same name
- loonylabs/claude-setup★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- .claude/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- ci-and-branch-protectionSkill
- design-critiqueSkill
- design-directionSkill
- design-tellsSkill
- memory-and-plansSkill
- portfolio-conventionsSkill
- python-uvSkill
- scheduled-jobsSkill
- testing-conventionsSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 91
Every substantive original line must appear in the new CLAUDE.md or in a skill.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Cutting a CLAUDE.md without losing a fact
A CLAUDE.md is loaded in full into every session started under it, so its size
is a recurring tax, not a one-off cost. ~/.claude/scripts/claude-md-weight.sh
measures every file on the machine and owns the size threshold — read the number
there, never re-type it in prose. (Restated numbers are exactly what that script
measures.)
The four buckets
Sort every paragraph. This is the whole method.
| bucket | test | action |
| guard | prevents a wrong action a session would otherwise take | KEEP, compressed to the rule |
| instruction | a task that will eventually be finished | DELETE when done |
| domain knowledge | true, but only needed once you are already in that subsystem | MOVE to a skill |
| archaeology | how we found out, or what we used to believe | DELETE — git log holds it |
Refinements that decide the hard cases:
- A measured-wrong rule stays. "This looks like an obvious improvement but was measured to be wrong" is a guard, because without it a session re-derives the wrong belief from the same evidence. State it as a rule, never as a story.
- Money-path, auth and secrets rules stay, always.
- The measurement itself goes to the skill. The rule is the guard; the falsifying control, the numbers and the retraction narrative are domain knowledge.
- When a belief here turns out wrong, delete the wrong sentence. Do not strike it through and explain. Keep a retraction only where a future session would independently re-derive the wrong belief from the same evidence.
- Never hand-type a count, an inventory or a file list. Derive it, or omit it. This construction has drifted repeatedly — "eighteen scripts" when there were nineteen, "Eight plugins" when there were ten, a plist count written from memory.
- Each script is the source of truth for its own numbers (retentions, weights, thresholds, tiers). Prose describes them and must never restate them.
An extracted skill only helps if something loads it
A skill loads when the model decides to invoke it. So the line that survives in CLAUDE.md must name the skill AND the situation. Copy this shape:
Scheduled jobs and
~/.claude/scripts/: load thescheduled-jobsskill before creating, editing, moving or diagnosing any of them. It holds the reasons;jobs-inventory.shderives the current state.
A bare "see the X skill" is not a trigger and will not fire.
Skill frontmatter: name kebab-case (prefix with the repo name for a project skill);
description naming the situation that should trigger it, not just the topic.
Prerequisite 1 — a wholesale .claude/ gitignore silently voids the work
A project skill written under a repo that ignores .claude/ wholesale is
untracked and lost on a fresh clone. Narrow first to
.claude/agent-memory/, agent-memory-local/, worktrees/, then prove both
directions:
git check-ignore -v .claude/skills/x/SKILL.md # must report NOTHING
git check-ignore -v .claude/agent-memory/x # must STILL report a matchPer-agent memory must never become tracked. See memory-and-plans.
Prerequisite 2 — a CLAUDE.md can be a load-bearing input to a check
Documentation here is sometimes parsed. Before moving or deleting a section:
grep -rn "CLAUDE\.md" scripts src bin tools .github 2>/dev/nullSplit the hits into comments that mention it (repoint the prose) and code that reads it (repoint the path). After repointing, corrupt the moved artifact on purpose and confirm the verifier goes red — a check that now reads a file with no matching section can throw, pass vacuously, or match nothing, and only the deliberate failure tells you which.
Measured in vigie: scripts/verify-strata.mjs parses a CLAUDE.md section and pins
its bolded rows against the @keyframes in tokens.css. Moving the section made
npm run verify throw, while npm test and astro build both stayed green.
Verification — line coverage, and make it fail once first
Every substantive original line must appear in the new CLAUDE.md or in a skill.
git show HEAD:CLAUDE.md > /tmp/before.txt # BEFORE editing
# after:
while IFS= read -r line; do
[ ${#line} -lt 40 ] && continue
grep -qF -- "$line" CLAUDE.md .claude/skills/*/SKILL.md 2>/dev/null \
|| printf 'UNCOVERED: %s\n' "$line"
done < /tmp/before.txt-F and -- are not optional. Without them grep silently mis-parses any line
starting with - and reports garbage — that bug produced a fake clean pass once.
Then delete a known sentence and confirm it is reported. A check that has never produced the opposite answer is not evidence.
An uncovered line is not automatically a bug — a deleted count or a deleted retraction story is a correct uncovered line. But you must be able to name the bucket for every one.
The method that has worked twice
Move the reasoning into skills; keep only what a session must see unprompted.
Nothing is deleted except hand-typed counts and archaeology. Project skills live at
<repo>/.claude/skills/<name>/SKILL.md; machine-wide ones at
~/.claude/skills/<name>/SKILL.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

