Ablation audit of your CLAUDE.md, your skills, and your hooks. It only reads, classifies, and proposes — it never changes anything.
Every line in your config is guilty of complexity until proven useful. The skill reads everything, classifies each instruction, and delivers a report with the minimum proposed version. Applying it is your decision, in a separate request.
Classifies each instruction as context, guardrail, criterion, verification, integration, procedure, micromanagement, redundancy, legacy, or unproven.
No edits, no rm, no mv, no commits. An audit that starts changing things is one you can't trust.
Ends with an A/B/C ablation plan using real tasks from your project — to prove the change before adopting it.
Boris Cherny created Claude Code at Anthropic. The thesis, in one sentence: configuration gets stale.
About every ~6 months, especially when a major model launches: delete your CLAUDE.md, delete your skills, delete your hooks — and see what the model does without them.
Boris Cherny · talk at Y Combinator, one day after the Opus 5 launch
Every instruction you write fixes a specific model’s weakness. When the next model no longer has that weakness, the line becomes dead weight—and keeps being reread every time it’s used.
That’s what happened in Claude Code itself with the arrival of Opus 5. What remains of the system prompt is almost entirely about safety, permissions, static analysis, and the interface.
Scripting “do A, then B, then C” worked with older models. Today it keeps the model from finding a better approach. Write the task + guardrails + completion criteria.
A short prompt with a real way for the model to check its own work beats a giant prompt without verification. Produce → observe → compare → stopping condition.
The fourth step is the one that matters: you're terrible at predicting which instructions the model needs, and every line you keep costs context in every run.
If you’ve been using Claude Code for a few months, you probably have at least three of these:
| Symptom | What it usually is |
|---|---|
CLAUDE.md of 300 lines with dated exceptions | fixes for models that are no longer around |
The same rule in the CLAUDE.md and in 3 skills | redundancy that turns into conflict when one of the copies changes |
| 400-line skill teaching “how to think” | generic reasoning the model can already do on its own |
| Rigid 12-step process | micromanagement that blocks the better path |
| Two conflicting rules | the model picks one, and you don’t know which |
| Nothing saying how to check what got it right | the most costly gap of all |
The cost adds up: context burned on every call, reduced autonomy, inconsistent behavior, and zombie rules nobody deletes because nobody remembers what they’re holding together anymore.
The goal no is to maximize the reduction. It’s to maximize quality + autonomy + verifiability ÷ complexity — that’s why the skill explicitly preserves what the model can’t infer: project identity, paths and sources of truth, branding, security, compliance, integrations, and interface contracts.
Each instruction gets a category and a decision. Without enough evidence, the skill prefers TEST a KEEP.
CONTEXTO · GUARDRAIL · CRITÉRIO DE QUALIDADE · VERIFICAÇÃO · INTEGRAÇÃO/FERRAMENTA · PROCEDIMENTO REPETÍVEL · MICROGERENCIAMENTO · REDUNDÂNCIA · LEGADO/OBSOLETA · AMBÍGUA/NÃO COMPROVADA
KEEP · SIMPLIFY · MERGE · SPLIT · LOAD-ON-DEMAND · CONVERT-TO-CONTEXT · DELETE-CANDIDATE
| # | Section |
|---|---|
| 1 | Executive summary — the 5 biggest issues |
| 2 | Metrics — count by decision and estimated reduction in % |
| 3 | Issues by file (severity + rationale) |
| 4 | Candidates for removal (reason, risk, how to test) |
| 5 | Redundancies and conflicts |
| 6 | Skills — function, diagnosis, recommendation |
| 7 | CLAUDE.md proposed minimum |
| 8 | Proposed skills in a reduced version |
| 9 | Ablation plan — versions A / B / C on real tasks |
| 10 | Top 10 changes by impact ÷ risk |
Self-contained skill: one file SKILL.md. No dependencies, no build.
O SKILL.md stays at the root—installation is a cp.
git clone https://github.com/inematds/audit-ablacaocc.git
Applies to every project on your machine.
mkdir -p ~/.claude/skills/audit-ablacao cp audit-ablacaocc/SKILL.md ~/.claude/skills/audit-ablacao/SKILL.md
That way, the skill versions alongside the code and doesn't leak into other projects.
mkdir -p .claude/skills/audit-ablacao cp /caminho/audit-ablacaocc/SKILL.md .claude/skills/audit-ablacao/SKILL.md
Explicit invocation removes trigger guesswork.
/audit-ablacao # or: "run an ablation audit of my global CLAUDE.md"
Global every ~6 months or when a model launches; per project when the CLAUDE.md exceeds ~150 lines; for a skill set when 3+ compete for the same trigger.
/audit-ablacao audita as skills deste projeto # scope in natural language
The skill doesn't apply anything — by design. Take the Top 10 by impact ÷ risk, apply it, use it in real work for a few days, and bring back an instruction only if the same failure happens again.
# ablation baseline used internally at Anthropic: CLAUDE_CODE_SIMPLE=1 claude # runs without any system prompt
This practice changes the outcome more than any prompt adjustment, and naturally complements the cleanup: what gets removed from the CLAUDE.md isn’t lost; it becomes a skill.
Rule in CLAUDE.md is read in every execution, including the 90% that have nothing to do with it. Within a skill, it only costs context when the task calls for it—that’s the MOVE e o LOAD-ON-DEMAND of the report.
/nome-da-skill doesn’t depend on the description matching what you say. When several skills compete for the same topic, explicit invocation breaks the tie—and removes the need for a routing rule in the CLAUDE.md.
In .claude/skills/, the procedure travels with the repo, goes into the PR, is reviewable, and doesn't contaminate other projects.
When the model stumbles, there are three remedies: a better prompt (unclear instruction), skill (no repeatable procedure) or MCP (missing unreachable context). Choosing correctly avoids the reflex to dump another rule into CLAUDE.md.
In practice: the CLAUDE.md keeps only what’s true always — identity, guardrails, sources of truth, security. Everything else (procedure, format, recipe, integration) becomes a skill, invoked directly when you know what you want.
Ablation isn't a one-time event. It's maintenance.
The process this repository itself followed. It works for any INEMA skill or project.
The guide goes in guia/, never in the root — the root is for code. And it's a page within in the project repo, never a separate repository.
audit-ablacaocc/ ├── SKILL.md # a skill (root = installable with a cp) ├── README.md ├── capa/capa.png # cover 1280x720 (skill capa-inema) ├── guia/index.html # self-contained landing page + guide └── doc/ # source material
Check the author before before committing: an author that doesn’t match the destination account is the #1 reason a deploy gets blocked afterward.
git init -b main git config user.name "inematds" git config user.email "inematds@gmail.com" git add -A && git commit -m "feat: skill audit-ablacao + guia" gh repo create inematds/audit-ablacaocc --public --source=. --remote=origin --push
First create the .github/workflows/pages.yml (full YAML in the README) — the legacy "deploy from a branch" build stalls. Since the guide is in guia/, the public URL ends in /guia/.
# with .github/workflows/pages.yml committed: gh api -X POST repos/inematds/audit-ablacaocc/pages -f build_type=workflow gh api repos/inematds/audit-ablacaocc/pages -q .html_url
Once the Pages URL is responding, publish to the 3 INEMA surfaces — portal, inemabuscas, and PRO catalog.
/atualiza-portal https://inematds.github.io/audit-ablacaocc/guia/
Publish = commit + push to origin. Deployment is automatic via git webhook → Vercel / Pages: no opening the dashboard, checking status, or triggering another deploy.
# done when the push reaches origin and Pages returns 200