Auditoria de ablação do seu CLAUDE.md, das suas skills e dos seus hooks. Só lê, classifica e propõe — nunca altera nada.
Toda linha da sua config é culpada de complexidade até provar utilidade. A skill lê tudo, classifica instrução por instrução e entrega um relatório com a versão mínima proposta. Aplicar é decisão sua, num pedido separado.
Classifica cada instrução como contexto, guardrail, critério, verificação, integração, procedimento, microgerenciamento, redundância, legado ou não comprovada.
Nenhum edit, nenhum rm, nenhum mv, nenhum commit. Auditoria que já sai mexendo é auditoria em que você não confia.
Termina com um plano de ablação A/B/C sobre tarefas reais do seu projeto — para provar a mudança antes de adotá-la.
Boris Cherny criou o Claude Code na Anthropic. A tese, em uma frase: configuração envelhece.
A cada ~6 meses, e principalmente em lançamento grande de modelo: apague seu CLAUDE.md, apague suas skills, apague seus hooks — e veja o que o modelo faz sem eles.
Boris Cherny · palestra na Y Combinator, um dia após o lançamento do Opus 5
Cada instrução que você escreve corrige a fraqueza de um modelo específico. Quando o modelo seguinte não tem mais aquela fraqueza, a linha vira peso morto — e continua sendo relida a cada uso.
Foi o que aconteceu no próprio Claude Code com a chegada do Opus 5. O que sobrou do prompt de sistema é quase todo segurança, permissões, análise estática e interface.
Roteirizar "faça A, depois B, depois C" funcionava com modelos antigos. Hoje impede o modelo de achar um caminho melhor. Escreva tarefa + guardrails + critérios de saída.
Prompt curto com um jeito real de o modelo conferir o próprio trabalho ganha de prompt gigante sem verificação. Produzir → observar → comparar → condição de parada.
A quarta etapa é a que importa: você é um péssimo previsor de qual instrução o modelo precisa, e cada linha mantida custa contexto em toda execução.
Se você usa Claude Code há alguns meses, provavelmente tem pelo menos três destes:
| Sintoma | O que costuma ser |
|---|---|
CLAUDE.md de 300 linhas com exceções datadas | correções de modelos que já saíram de cena |
A mesma regra no CLAUDE.md e em 3 skills | redundância que vira conflito quando uma das cópias muda |
| Skill de 400 linhas ensinando "como pensar" | raciocínio genérico que o modelo já faz sozinho |
| Passo a passo rígido de 12 etapas | microgerenciamento que trava a rota melhor |
| Duas regras que se contradizem | o modelo escolhe uma, e você não sabe qual |
| Nada dizendo como conferir que ficou certo | o buraco mais caro de todos |
O custo é composto: contexto queimado em toda chamada, autonomia reduzida, comportamento inconsistente e regras zumbis que ninguém apaga porque ninguém lembra mais o que elas seguram.
O objetivo não é maximizar a redução. É maximizar qualidade + autonomia + verificabilidade ÷ complexidade — por isso a skill preserva explicitamente o que o modelo não consegue inferir: identidade do projeto, caminhos e fontes de verdade, branding, segurança, compliance, integrações e contratos de interface.
Cada instrução recebe uma categoria e uma decisão. Sem evidência suficiente, a skill prefere 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
| # | Seção |
|---|---|
| 1 | Resumo executivo — os 5 maiores problemas |
| 2 | Métricas — contagem por decisão e redução estimada em % |
| 3 | Problemas por arquivo (severidade + justificativa) |
| 4 | Candidatas à remoção (motivo, risco, como testar) |
| 5 | Redundâncias e conflitos |
| 6 | Skills — função, diagnóstico, recomendação |
| 7 | CLAUDE.md mínimo proposto |
| 8 | Skills propostas em versão reduzida |
| 9 | Plano de ablação — versões A / B / C em tarefas reais |
| 10 | Top 10 mudanças por impacto ÷ risco |
Skill self-contained: um arquivo SKILL.md. Sem dependência, sem build.
O SKILL.md fica na raiz — instalação é um cp.
git clone https://github.com/inematds/audit-ablacaocc.git
Vale para todos os projetos da sua máquina.
mkdir -p ~/.claude/skills/audit-ablacao cp audit-ablacaocc/SKILL.md ~/.claude/skills/audit-ablacao/SKILL.md
Assim a skill versiona junto com o código e não vaza para os outros projetos.
mkdir -p .claude/skills/audit-ablacao cp /caminho/audit-ablacaocc/SKILL.md .claude/skills/audit-ablacao/SKILL.md
Invocação explícita elimina a loteria do gatilho.
/audit-ablacao # ou: "faz uma auditoria de ablação do meu CLAUDE.md global"
Global a cada ~6 meses ou em lançamento de modelo; por projeto quando o CLAUDE.md passa de ~150 linhas; por conjunto de skills quando 3+ brigam pelo mesmo gatilho.
/audit-ablacao audita as skills deste projeto # escopo em linguagem natural
A skill não aplica nada — de propósito. Pegue o Top 10 por impacto ÷ risco, aplique, use em trabalho real por alguns dias e devolva instrução só quando a mesma falha se repetir.
# linha de base de ablação usada internamente na Anthropic: CLAUDE_CODE_SIMPLE=1 claude # roda sem nenhum prompt de sistema
Essa prática muda o resultado mais do que qualquer ajuste de prompt, e é o complemento natural da faxina: o que sai do CLAUDE.md não se perde, vira skill.
Regra no CLAUDE.md é lida em toda execução, inclusive nas 90% que não têm nada a ver com ela. Dentro de uma skill, só custa contexto quando a tarefa é aquela — é o MOVE e o LOAD-ON-DEMAND do relatório.
/nome-da-skill não depende de a descrição casar com a sua frase. Quando várias skills competem pelo mesmo assunto, invocação explícita é o desempate — e dispensa regra de roteamento no CLAUDE.md.
Em .claude/skills/, o procedimento anda com o repo, entra no PR, é revisável e não contamina os outros projetos.
Quando o modelo tropeça há três remédios: prompt melhor (instrução obscura), skill (falta procedimento repetível) ou MCP (falta contexto inalcançável). Escolher certo evita o reflexo de despejar mais uma regra no CLAUDE.md.
Na prática: o CLAUDE.md fica só com o que é verdade sempre — identidade, guardrails, fontes de verdade, segurança. Todo o resto (procedimento, formato, receita, integração) vira skill, invocada direto quando você sabe o que quer.
Ablação não é evento único. É manutenção.
A receita que este próprio repositório seguiu. Vale para qualquer skill ou projeto INEMA.
O guia vai em guia/, nunca na raiz — a raiz é do código. E é uma página dentro do repo do projeto, nunca um repositório separado.
audit-ablacaocc/ ├── SKILL.md # a skill (raiz = instalável com um cp) ├── README.md ├── capa/capa.png # capa 1280x720 (skill capa-inema) ├── guia/index.html # landing + guia self-contained └── doc/ # material de base
Confira o autor antes de commitar: autor divergente da conta de destino é o motivo nº 1 de deploy bloqueado depois.
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
Crie primeiro o .github/workflows/pages.yml (YAML completo no README) — o build legacy "deploy from a branch" trava. Como o guia está em guia/, a URL pública termina em /guia/.
# com .github/workflows/pages.yml commitado: gh api -X POST repos/inematds/audit-ablacaocc/pages -f build_type=workflow gh api repos/inematds/audit-ablacaocc/pages -q .html_url
Com a URL do Pages respondendo, publique nas 3 superfícies INEMA — portal, inemabuscas e catálogo PRO.
/atualiza-portal https://inematds.github.io/audit-ablacaocc/guia/
Publicar = commit + push no origin. O deploy é automático via webhook git → Vercel / Pages: nada de abrir dashboard, checar status ou re-disparar deploy.
# terminou quando o push entrou no origin e o Pages responde 200