learnaiwithrafa
ClaudeSetup

Sua revisão semanal precisa de uma coluna "apagar"

Adicionar a sua 30ª skill pode deixar as outras 29 mais difíceis de achar: a listagem de skills recebe ~1% do `context window`, e o Claude Code corta a descrição das skills que você usa menos. Aqui está o ritual de sexta, a tabela que roteia cada lição e a passada de poda que todo mundo pula.

8 min de leitura5 fontes
  • #claude-code
  • #setup
  • #context-engineering

Tem uma parte que derruba todo aquele conselho de "melhore seu setup toda semana", e ela é mensurável: uma revisão que só adiciona piora o seu setup.

O estrago vem de dois mecanismos documentados. O primeiro é o CLAUDE.md — a documentação é direta: arquivos CLAUDE.md inflados fazem o Claude ignorar as suas instruções de verdade. Ou seja, a décima regra que você adicionou neste mês está competindo com as nove anteriores, e quem perde a disputa não é você que escolhe. O segundo é mais sutil. O Claude Code carrega uma listagem com o nome e a descrição de cada skill pro Claude saber o que existe, e essa listagem tem um orçamento de 1% do context window do modelo. Quando estoura, o Claude Code corta as descrições começando pelas skills que você invoca menos. O nome fica; a descrição — justamente o que o Claude compara com a sua tarefa — vai embora.

Agora releia isso pensando num ritual semanal. Toda sexta você adiciona uma skill, e toda sexta aquela skill que você escreveu três meses atrás fica um pouco mais invisível. Crescer não é melhorar.

O difícil não é revisar. É decidir pra onde vai.

Quem faz esse ritual normalmente acerta a primeira metade: consegue listar o que deu errado na semana. E aí joga tudo dentro do CLAUDE.md, porque é o arquivo que a pessoa conhece. É exatamente aí que quebra. A própria documentação da Anthropic publica uma tabela de gatilhos pra você montar o setup aos poucos, e completa com a frase que transforma aquilo numa ferramenta de revisão: os mesmos gatilhos dizem quando atualizar o que você já tem.

Então decida pelo sintoma, não pelo assunto. O assunto não te diz nada; o sintoma aponta o arquivo:

  • O Claude errou uma convenção ou um comando duas vezes → uma linha verificável no CLAUDE.md. Duas vezes, não uma. Uma vez é ruído.
  • Já existia uma regra e ela foi furada mesmo assim → é essa que todo mundo erra. Não precisa escrever mais forte. Texto que só orienta é um pedido, não uma garantia; leve pra um hook ou pra uma regra em permissions.deny. E aqui a garantia é real: um hook de PreToolUse que responde deny bloqueia a ferramenta até no modo bypassPermissions ou com --dangerously-skip-permissions.
  • Você colou o mesmo procedimento de vários passos no chat outra vez → uma skill. A documentação dá o gatilho exato: quando um pedaço do CLAUDE.md virou um procedimento em vez de um fato. O corpo da skill só carrega quando ela é usada, então o material de referência não custa nada até você precisar.
  • A lição só vale dentro de uma pasta.claude/rules/ com paths no frontmatter, pra carregar só quando o Claude mexe nos arquivos que casam.
  • Uma tarefa paralela entupiu a conversa com saída que você nunca vai reler → um subagent, que roda no contexto dele e devolve só um resumo.
  • Só é verdade nesta máquina → memória automática, não o repositório. (Leitura vizinha: o guia de memória aqui no site explica o que merece virar memória e por que aquela pasta nunca sai do seu notebook.)

O prompt

Trinta minutos, sexta-feira, no repositório em que você realmente trabalhou na semana. Três tabelas — e a segunda é o motivo de isso funcionar.

Revise meu setup do Claude Code na última semana. Não altere nenhum arquivo
ainda — me entregue um relatório de roteamento.

COLETE PRIMEIRO
1. `git log --since='7 days ago' --oneline` mais os comentários de review dos
   PRs que entraram nesta semana. Esses comentários são correções que eu já
   paguei um humano pra escrever.
2. Leia CLAUDE.md, .claude/rules/*, o nome + a descrição de cada
   .claude/skills/*/SKILL.md, .claude/agents/* e o bloco de hooks do
   .claude/settings.json. Informe a contagem de linhas de cada um.
3. Me pergunte quais correções eu digitei mais de uma vez nesta semana.

SAÍDA — exatamente três tabelas, nada além disso.

TABELA 1 · PROMOVER (no máximo 5 linhas) — sintoma | destino | texto exato a
adicionar | arquivo
Decida pelo sintoma, não pelo assunto:
- errou uma convenção ou comando duas vezes -> CLAUDE.md, uma linha verificável
- a regra existia e foi furada mesmo assim  -> hook ou permissions.deny
- eu colei o mesmo procedimento de novo     -> uma skill (disable-model-invocation:
                                               true se tiver efeito colateral)
- só vale dentro de uma pasta               -> .claude/rules/ com `paths`
- entupiu meu contexto de saída             -> um subagent
- só é verdade nesta máquina                -> memória automática, não o repo

TABELA 2 · PODAR — toda linha do CLAUDE.md ou de .claude/rules/ em que a
resposta pra "tirar isso faria o Claude errar?" é não. Inclua regras que o
Claude já cumpre sem ser avisado e skills que eu não invoco há 30 dias.

TABELA 3 · CONFERIR — pra cada linha da tabela 1: qual comportamento observável
deve mudar na semana que vem, e qual comando ou checagem mostraria isso.

Restrição: a contagem total de linhas de CLAUDE.md + .claude/rules/ não pode
crescer, a menos que você me explique por que deveria. Toda linha que você
adicionar tem que ser checável — nada de "escreva código limpo".

Dá pra agendar isso, e eu agendo. Mas agendar é a parte fácil: a automação junta as evidências e a decisão de roteamento continua sendo sua. Se você quer a mecânica de rodar coisas em cadência, o guia de loops aqui no site cobre isso; este aqui é sobre a decisão que o loop coloca na sua mão.

Depois, confira — e é isso que ninguém faz

A documentação estabelece um padrão mais alto do que a maioria pratica: trate o CLAUDE.md como código — revise quando as coisas dão errado, pode com frequência e teste as mudanças observando se o comportamento do Claude muda de verdade. Observando. Não adicionando a linha e presumindo.

É pra isso que a tabela 3 existe. Duas checagens baratas:

  1. Rode /context. Confirme que o seu CLAUDE.md aparece mesmo na lista de arquivos de memória — se não aparece, você passou semanas depurando um arquivo que o Claude nunca leu. Depois olhe a linha de Skills, que mostra o tamanho da listagem com o orçamento aplicado, ou seja, o que o modelo recebe de fato. Se estiver grande, as suas skills menos usadas já estão perdendo a descrição.
  2. Na sexta seguinte, veja se a linha da sexta passada ainda precisa existir. Se o Claude já faz certo, você apaga a linha e nada regride, então a linha nunca foi o motivo. O aprendizado de verdade aconteceu com você nesse momento, não com o arquivo.

Por que isso pesa mais num time internacional

Se você é dev ou EM no Brasil atrás de uma vaga remota nos EUA ou na Europa, esse ritual não é arrumação de casa — é o artefato visível do seu discernimento. Ninguém a cinco fusos de distância vê você sendo cuidadoso no chat. As pessoas veem os arquivos. E um CLAUDE.md compartilhado é um custo compartilhado: como diz o blog da Anthropic, cada linha carrega em toda sessão de todo engenheiro que trabalha no repositório, seja relevante pra tarefa dele ou não. Quem adiciona 40 linhas de texto opinativo gastou o contexto de todo mundo. Quem transforma um comentário de review recorrente num hook eliminou uma classe de erro pro time inteiro, pra sempre, num diff que alguém consegue ler. É o segundo que é promovido — e são os mesmos 30 minutos.

Faça isso hoje

Abra o repositório em que você mexe mais e rode /context. Anote dois números: a contagem de linhas do seu CLAUDE.md e o tamanho da linha de Skills. Depois faça só a tabela 2 — a passada de poda — e apague uma coisa: uma regra que o Claude já cumpre, ou uma skill que você não invoca há um mês. Suba essa exclusão como um commit só dela. Na sexta que vem, rode o prompt completo. Um setup que consegue encolher é um setup que consegue melhorar; um que só cresce é só um arquivo maior sendo ignorado com mais eficiência.

Fontes