Guia do CLAUDE.md: Escrevendo as regras do projeto na memória dele
📚 Navegação da Série: O artigo anterior 17 Imagens e Multimodal ensinou como alimentar capturas de tela e erros diretamente para o Claude. Este artigo muda de direção — como escrever as "regras" do projeto na memória dele de uma vez por todas, para que ele as obedeça automaticamente a cada nova tarefa, sem que você tenha que ficar repetindo.
Dizem que quanto mais detalhado for o CLAUDE.md, melhor. Mas para falar a verdade, o CLAUDE.md mais inútil é exatamente aquele que tem trezentas linhas e o Claude não obedece nenhuma.
Imagine um CLAUDE.md deixado pelo dev anterior ao assumir um projeto, cheio de prosa: contexto da empresa, visão do produto, introdução da equipe, a história de como as tecnologias foram escolhidas... Você rola até a segunda tela só para encontrar um útil "use pnpm, não npm". E o resultado? O Claude ainda assim te dá um npm install de vez em quando.
O problema não é que ele é desobediente, é que aquela regra foi enterrada no meio de duzentas linhas de lixo, e a atenção dele foi diluída.
O CLAUDE.md (arquivo de memória do projeto para o Claude), quando bem escrito, é um artefato mágico; quando mal escrito, é um fardo — ele ocupa a sua janela de contexto a cada sessão, e quanto mais inchado for, menos espaço sobra para o trabalho real. Hoje vamos destrinchar isso: quais são as camadas, o que escrever, o que não escrever, como referenciar outros arquivos e como mantê-lo enxuto.
Após ler este artigo, você terá:
- Entendimento das três camadas do CLAUDE.md (nível de usuário / nível de projeto / nível de subdiretório), o que cada uma gerencia e a ordem de carregamento
- Uma lista de verificação "O que escrever vs O que não escrever", evitando a armadilha de 90% dos novatos de encher de lixo
- A maneira correta de usar a sintaxe
@para referenciar outros arquivos, e seu verdadeiro custo no contexto - A forma oficial de adicionar temporariamente uma memória durante uma sessão, mais uma tabela de "Bom vs Ruim" para usar como modelo
ℹ️ Este artigo foca apenas em como escrever e manter o arquivo CLAUDE.md. A funcionalidade de geração automática via
/initjá foi abordada em 12 Inicialização de Projeto, e o mecanismo mais amplo de memória automática (auto-memory) será tratado especificamente em 25 Sistema de Memória.
01 Entenda primeiro: O que diabos é o CLAUDE.md?
Conclusão primeiro: CLAUDE.md é uma "instrução persistente" que você escreve para o Claude; a cada nova sessão, ele a lê primeiro e a coloca no cérebro como o contexto do projeto.
Por que precisamos disso? Porque toda sessão do Claude Code começa como uma folha em branco — aquelas suas ordens implorando "use pnpm, não toque no diretório legacy, os testes rodam assim" da última vez, ele não lembra de nenhuma. Sem o CLAUDE.md, você teria que explicar tudo de novo todas as vezes. Irritante, né?
Analogia: Manual de integração para um novo funcionário. O novato chega no primeiro dia, e você não fica do lado dele ditando as regras o dia todo. Você dá a ele um manual: o que o projeto faz, como submeter código, quais campos minados evitar. Ele lê e começa a trabalhar. O CLAUDE.md é o manual de integração do Claude — mas do tipo que ele relê todos os dias antes de começar a trabalhar.
Mas aqui vai um insight crucial, a documentação oficial diz muito francamente:
O conteúdo do CLAUDE.md é passado como uma mensagem do usuário após o prompt do sistema, e não como parte do próprio prompt do sistema. O Claude o lê e tenta segui-lo, mas não há garantias de obediência estrita.
Traduzindo para humanos: CLAUDE.md é uma "forte recomendação", não uma "lei de ferro". Ele molda o comportamento do Claude, mas não é uma camada de força bruta. Portanto, quanto mais específico e conciso você for, mais firme ele o seguirá. Esperando que ele bloqueie 100% uma operação perigosa? Esse é um trabalho para um Hook (gancho), não para o CLAUDE.md — a divisão entre os dois será falada em capítulos posteriores.
Quando você deve adicionar algo nele? A versão oficial dá alguns sinais bem práticos:
- O Claude comete o mesmo erro pela segunda vez — Sinal de que essa regra precisa ser formalizada
- Você digitou de novo nesta sessão aquela mesma correção que já tinha feito na sessão passada
- Durante a revisão de código, você percebeu que ele já deveria saber uma certa convenção da base de código
- Novos colegas de equipe precisariam do mesmo contexto para começar rapidamente
💡 Resumo em uma frase: CLAUDE.md é o manual de integração que o Claude lê toda vez que começa a trabalhar; é do nível "forte recomendação" e não "lei de ferro", quanto mais específico for, melhor funciona.
02 Três Camadas: Quem controla o global, quem controla o projeto único
Não existe apenas um CLAUDE.md, ele pode ser colocado em vários lugares, com o escopo de atuação variando do maior para o menor. Novatos costumam ficar confusos aqui, vamos esclarecer de uma vez por todas.
De acordo com a documentação oficial, estas são as três camadas comumente usadas (mais uma variação local):
| Camada | Onde Fica | Escopo de Atuação | Entra no git? |
|---|---|---|---|
| Nível do Usuário | ~/.claude/CLAUDE.md | Todos os projetos nesta sua máquina | Não, apenas preferências pessoais |
| Nível do Projeto | ./CLAUDE.md ou ./.claude/CLAUDE.md | Somente este projeto atual | ✅ Sim, compartilhado com a equipe |
| Nível do Subdiretório | Qualquer subdiretório/CLAUDE.md | Carrega apenas quando o Claude lê arquivos naquele diretório | ✅ Sim, bom para repos múltiplos |
| Nível Local (Variante) | ./CLAUDE.local.md | Projeto atual, só para você | ❌ Adicione no .gitignore |
Existe também uma "Camada de Política Gerenciada", implantada por administradores de TI no diretório do sistema (no macOS é
/Library/Application Support/ClaudeCode/CLAUDE.md), carregada antes do nível de usuário e não pode ser ignorada por indivíduos. Usuários comuns geralmente não mexem nisso, então vamos pular aqui; consulte a documentação oficial para cenários corporativos.
Como dividir o trabalho? Lembre-se de uma frase: Hábitos pessoais vão no nível do usuário, regras da equipe vão no nível do projeto.
- Nível do Usuário (
~/.claude/CLAUDE.md): Coloque preferências pessoais que valem para todos os projetos. Exemplo: "Responda em português", "Antes de alterar código, me fale a ideia e não comece logo", "Use inglês nas mensagens de commit". Isso não tem nada a ver com um projeto específico, é o hábito de "você, a pessoa", então aplica-se a todos os projetos e não entra no git de nenhum deles. - Nível do Projeto (
./CLAUDE.md): Coloque regras exclusivas deste projeto que toda a equipe deve seguir. Stack de tecnologia, comandos de build, convenções de diretório, lista de arquivos proibidos. Ele segue o código no controle de versão; quando um novo colega faz um clone, ele já vem com essas regras. - Nível do Subdiretório: Útil para repositórios gigantes. Exemplo: no diretório de frontend, ponha um exclusivo para o frontend; no de backend, um exclusivo do backend. Ele não é carregado normalmente, só quando o Claude realmente vai ler arquivos naquele diretório ele puxa aquele CLAUDE.md junto — economizando contexto.
Analogia do manual de novo: Nível do Usuário = Seu caderno pessoal de anotações de trabalho (você leva se mudar de empresa); Nível do Projeto = O manual do funcionário que a empresa entrega (você devolve quando sai); Nível do Subdiretório = Regras específicas de um departamento (você só recebe se for transferido para lá).
Um exemplo comum de configuração a nível de usuário: no ~/.claude/CLAUDE.md, coloque "Ao encontrar múltiplas soluções de implementação, liste as opções para eu escolher, em vez de decidir silenciosamente por mim". Essa regra vale para cada projeto seu, então colocá-la no nível do usuário economiza o esforço — configure uma vez, e nunca mais precise repetir isso em um novo projeto.
💡 Resumo em uma frase: Hábitos pessoais vão no nível de usuário (
~/.claude/CLAUDE.md), regras da equipe vão no nível de projeto (./CLAUDE.mdque vai pro git), para repositórios gigantes use o nível de subdiretório para separar por módulo.
03 Ordem de Carregamento: Por que o Nível de Projeto "Falar por Último" é Mais Importante
A seção anterior listou três camadas, mas quando todas existem ao mesmo tempo, quem manda? Esse é outro mal-entendido frequente, precisamos acertar isso.
A regra oficial: É carregado do escopo mais amplo para o mais específico; quanto mais perto do diretório onde você iniciou, mais tarde a instrução será lida.
Como isso é ordenado? O Claude Code vai a partir do diretório atual onde você está e sobe a árvore; em cada camada que encontrar um CLAUDE.md, ele o recolhe, juntando tudo num grande contexto no final. A ordem geralmente é:
Nível do Usuário ~/.claude/CLAUDE.md
↓ (Lido primeiro)
(Mais acima na árvore) CLAUDE.md do diretório pai
↓
Raiz do Projeto ./CLAUDE.md
↓ (Lido por último, mais perto de você)
Subdiretório CLAUDE.md (Adicionado apenas se o Claude ler arquivos daquele diretório)Preste atenção em dois pontos-chave, ambos retirados da documentação oficial:
Primeiro, todos os arquivos encontrados são "concatenados", não "sobrescritos". Eles entram inteiros no contexto, os últimos não apagam os primeiros. Portanto, nível de usuário e nível de projeto funcionam simultaneamente, não existe "se definiu o do projeto, o do usuário perde a validade".
Segundo, as instruções mais próximas ao diretório de trabalho são "lidas por último". Quando duas regras entram em conflito — digamos, o nível do usuário diz "use aspas simples" e o nível de projeto diz "use aspas duplas" — o nível do projeto que está mais perto, por ter falado depois, geralmente ganha. Simplificando: regras do projeto podem anular seus hábitos pessoais, e é exatamente esse o efeito desejado na colaboração de equipe.
Esta imagem empilha as três camadas de cima para baixo: Nível do Usuário (rege todos os projetos, lido primeiro), Nível do Projeto (projeto atual, vai para o git), Nível do Subdiretório (mais perto do código, tem precedência em conflitos); a seta à direita marca a ordem de carregamento "de cima para baixo", e a regra de ouro no fundo esclarece — as três camadas são concatenadas e não sobrescritas, a mais próxima do código é lida por último e é a que decide.
Aqui é preciso corrigir uma informação errada muito comum. Muitos tutoriais na internet escrevem a prioridade como "Local do Projeto → Raiz do Projeto → Subdiretório → Global", o que é exatamente o oposto da direção de carregamento descrita na documentação oficial. É fácil ser enganado por isso, mas olhando os documentos originais fica claro: eles dizem explicitamente que carrega "da abrangência mais ampla para a mais específica", com as instruções do projeto aparecendo depois das instruções do usuário. Siga a documentação oficial e não decore invertido.
Um pequeno detalhe carinhoso: o CLAUDE.md da raiz do projeto será relido automaticamente do disco após um /compact (comprimir conversa), ele não se perde. Mas aqueles CLAUDE.md alinhados em subdiretórios não serão reinjetados automaticamente, eles só voltam se o Claude for lá ler arquivos daquele diretório de novo. Então as regras mais importantes, coloque na raiz do projeto, não as enterre tão fundo.
💡 Resumo em uma frase: Múltiplos CLAUDE.md são concatenados e não sobrescritos; quanto mais próximos ao diretório de trabalho, mais tarde são lidos e mais peso têm em um conflito, portanto as regras do projeto podem cobrir hábitos pessoais — não confunda a ordem de carregamento oficial.
04 O que escrever vs O que não escrever
Esta seção é o pulo do gato. CLAUDE.md mal escrito falha em 90% das vezes porque "o que devia ser escrito não tá claro, e o que não devia encheu espaço".
Primeiro, o que escrever — a documentação oficial diz tudo em uma frase: Escreva "fatos que o Claude deve manter em todas as sessões". Traduzindo em lista, são essas cinco categorias:
| Categoria | O que escrever especificamente | Exemplo |
|---|---|---|
| Visão Geral do Projeto | O que é esse projeto em uma frase | "Backend de gestão de pedidos baseado em FastAPI" |
| Stack de Tecnologia | Linguagem, framework, BD, ferramentas-chave | "Python 3.11 / PostgreSQL / pytest" |
| Comandos Comuns | Como rodar testes, build e linter | uv run pytest, uv run ruff check . |
| Convenções de Código | Estilo, nomes, padrões obrigatórios | "Funções devem ter anotação de tipo", "Strings usam aspas duplas" |
| "Não faça" Explícitos | Zonas minadas, arquivos intocáveis, etc. | "Proibido modificar arquivos existentes em migrations/" |
Desses, os comandos comuns são os mais consultados — o Claude virá olhar os comandos antes de rodar testes ou builds, evitando que ele chute errado. A lista de proibições são as barreiras de proteção para evitar que ele seja "esperto demais e quebre as coisas": quais diretórios são código legado só de leitura, quais arquivos ele deve perguntar antes de alterar, quais chaves secretas ele está proibido de imprimir.
Agora o que não escrever, aqui é a verdadeira zona de desastre para iniciantes:
- ❌ Discursos longos de contexto: Histórico da empresa, visão do produto, razões pra escolher a tecnologia — o Claude não usa isso pra codar, só consome contexto.
- ❌ Informações desatualizadas: Trocou o gerenciador de pacotes, mas não atualizou o CLAUDE.md, continua escrito npm lá e você o engana.
- ❌ Coisas óbvias olhando o código: Não reescreva o que cada arquivo faz na estrutura de diretórios, não copie a configuração do ESLint de estilo de código. O Claude sabe ler código sozinho, repetir o óbvio é jogar espaço fora.
A posição oficial sobre isso é super firme, até traçando linhas vermelhas de tamanho:
Cada arquivo CLAUDE.md deve ter como alvo menos de 200 linhas. Arquivos longos consomem mais contexto e reduzem o nível de conformidade.
Por que 200 linhas é o teto crítico? Porque o CLAUDE.md compete pela mesma janela de contexto do seu chat. Se você socar trezentas linhas de baboseira, você rouba um naco da mesa de trabalho logo no início, reduzindo o espaço pro trabalho de verdade — e pior, as regras essenciais se afogam na prosa; e a adesão do bot só despenca. Essa é a raiz do problema das "trezentas linhas que ele não ouve" no começo do texto.
Um método prático legal: Antes de escrever cada regra, pergunte a si mesmo "O Claude descobriria isso sozinho só olhando o código? Se sim, delete". Só com essa facada, um CLAUDE.md herdado cai de mais de 300 linhas para umas 80, deixando apenas restrições inegociáveis que ele nunca deduziria. Após esse corte, a quantidade de vezes que ele usará o gerenciador de pacotes errado cairá a olhos vistos.
💡 Resumo em uma frase: Escreva os "fatos que ele precisa lembrar em toda sessão" (Resumo / Stack / Comandos / Padrões / Zonas Proibidas), apague tudo que o Claude consiga adivinhar lendo o código, mantenha abaixo de 200 linhas.
05 Referenciando outros arquivos: Sintaxe @ e seus Custos
Às vezes você já tem a documentação padrão pronta no projeto — um guia de design de API, uma convenção de banco de dados. Não precisa copiar e colar o conteúdo pro CLAUDE.md, basta referenciar com a sintaxe @.
A escrita é muito simples; adicione @ seguido do caminho em qualquer lugar do CLAUDE.md:
Para visão geral do projeto, veja @README.md, e comandos disponíveis em @package.json.
# Outras Instruções
- Workflow de git em @docs/git-instructions.mdAo ler o CLAUDE.md, o Claude vai expandir o conteúdo desses arquivos referenciados e carregar tudo junto no contexto. Atenção aos detalhes que a documentação oficial lista, grave-os pra não dar erro:
- O caminho relativo é interpretado em relação ao "arquivo que contém a referência", e não ao seu diretório de trabalho. Cuidado com isso.
- O caminho absoluto também funciona; os arquivos referenciados podem referenciar outros arquivos, recursivamente até 4 níveis.
- Se for a primeira vez que algo de fora do projeto é referenciado, o Claude Code vai mostrar uma caixa pedindo sua aprovação. Se recusar, a referência é desativada pra sempre e não vai apitar de novo.
Mas aqui vai a epifania mais importante, que a documentação reitera muito e que as pessoas vivem caindo:
Arquivos importados são expandidos na inicialização e carregados no contexto. Separar os dados em
@pathajuda na organização, mas não reduz o consumo de contexto, pois são carregados da mesma forma na inicialização.
Ou seja: Referenciar com @ serve pra "organizar" os arquivos, não para "economizar tokens". Muita gente acredita que quebrando os arquivos em módulos e deixando o CLAUDE.md mais curto o contexto é salvo — Falso. Os conteúdos continuam sendo injetados na largada, consumindo os mesmos recursos. Tente fatiar uma convenção de 500 linhas achando que emagreceu; se digitar /context (ver tamanho de uso do contexto) vai ver que os tokens continuam gordos e fofos lá dentro.
A regra é: Use a referência @ para deixar limpo de ler para os humanos, mas se quiser economizar o contexto de fato, você precisa "cortar conteúdo" ou usar as "regras de abrangência de diretório", não apenas fracionar em arquivos. E lembre, o arquivo referenciado não pode ser imenso, senão ele suga o chat inteiro pra ele.
Falando de arquivos separados: se você tem preferências só suas, que não devem ir pro git (ex: seu localhost de testes, dados fictícios que só você usa), não ponha no ./CLAUDE.md. Coloque num arquivo ./CLAUDE.local.md e adicione este último ao .gitignore. Ele será puxado e tratado exatamente como o CLAUDE.md real, mas sem ir pro commit e sem afetar seus colegas.
💡 Resumo em uma frase:
@caminhoimporta documentos externos pra "limpar a organização", mas os arquivos continuam consumindo tokens integralmente; se quiser salvar contexto, apague texto mesmo; para preferências não-públicas ponha noCLAUDE.local.md(e no gitignore).
06 Manutenção: Adicione na hora, limpe de tempos em tempos
O CLAUDE.md não é algo que você escreve e põe na prateleira; ele cresce com o projeto. Nesta seção dois movimentos: Como colocar novas regras ali na hora; Como e quando passar a tesoura.
Como colocar uma regra que pintou na cabeça do nada
Acontece sempre: no meio da conversa você corrige o Claude numa coisa, e pensa "ele precisaria lembrar disso nas outras vezes". A melhor maneira oficial de agir — Simplesmente mande ele anotar:
Adicione a seguinte regra no CLAUDE.md: "Operações de banco de dados devem passar na camada Service, não jogue SQL cru nas rotas"O Claude vai ele próprio escrever isso lá no CLAUDE.md. Outra forma é usar o comando /memory, e ele listará tudo que tá carregado no contexto do CLAUDE.md, CLAUDE.local.md e arquivos de regras, clicando lá abre no seu editor de código e você redige à mão. Se quiser que o Claude redija por você faça a opção 1; se quiser controle preciso do texto, use /memory e faça você.
ℹ️ Aviso sobre versão: No começo, você podia usar
#no input do Claude Code pra injetar uma memória rápido. Na versão nova mudou — agora o modo oficial é: diga "adicione isso no CLAUDE.md" ou abra com o/memory. Se falar pra ele só "lembre disso", ele salva na memória automática dele (auto-memory, papo para 25 Sistema de Memória); se quiser que vá para o arquivo, fale claramente "no CLAUDE.md".
Limpe sempre, apague os velhos e as brigas
Aviso implícito oficial: Se duas regras baterem de frente, o Claude pode seguir qualquer uma aleatoriamente. Você precisa voltar de tempos em tempos para varrer os caducos e conflitos. A hora certa de fazer a limpa:
- Quando mudar de empacotador / bundler (se não apagar os comandos velhos, você o está orientando a errar)
- Quando adicionar ou arrancar dependências chave
- Ao decidir uma nova convenção (pra ter certeza que não chuta o balde na anterior)
- Assim que você notar que o CLAUDE.md passou de 200 linhas de novo.
Como julgar se a regra é de fato boa ou não? Olhe se parece uma "regra de verdade" em vez de um "texto de reflexão". A documentação original tem comparações precisas que eu montei aqui:
| ❌ Texto Solto e Vago (Inútil) | ✅ Regra Específica (Funciona) |
|---|---|
| O código deve ser organizado | Funções não passam de 50 linhas, se passar quebre-as |
| Tente escrever testes sempre | Todo método novo precisa ter um respectivo teste unitário |
| Fique de olho na segurança | Dados de usuário devem passar pelo sanitize() antes de cair em SQL |
| A pasta legacy não importa tanto | É proibido alterar qualquer arquivo na pasta legacy/ |
| pnpm é a melhor opção | O gerenciamento de pacotes é APENAS pnpm, npm e yarn estão desativados |
O lado esquerdo não quer dizer nada — "organizado", "tente", "atenção" é tudo palavra fofinha pra humano, o Claude não consegue fazer checklist disso e logicamente não consegue seguir à risca. O lado direito diz verdades testáveis: 50 linhas, ter teste, rodar x método. Oficialmente eles recomendam "Escrever a instrução específica o bastante para que seja verificável".
Desenvolva o instinto na hora de compor: Acabou de escrever uma linha? Seja o juiz e diga "dá pra bater o olho e ver que essa regra foi quebrada?". Se não rolar, você filosofou demais; volte e seja seco.
💡 Resumo em uma frase: Adicione as regras à mão com
/memoryou mande ele "inserir no CLAUDE.md"; e regularmente corte os velhos e conflitos; Boas regras se assemelham a "cláusulas e restrições secas" ao invés de "discursos pomposos para ficarem bonitos".
07 A Prática Real: Crie o CLAUDE.md pro Projeto de Brinquedo
Conversar, conversar e nada. Pegue um projeto vazio, faça a pipeline "criar arquivo → escrever regras → checar o que rolou", demora cinco minutos.
Passo 1: Crie um projeto bobo e inicialize o git (Mac / Linux)
mkdir claude-md-demo
cd claude-md-demo
git init
echo 'def add(a, b):
return a + b' > main.pyEspera-se: O diretório claude-md-demo ganhará um main.py e um diretório oculto .git. O git serve pro CLAUDE.md poder entrar no versionamento no futuro (a condição pra compartilhar em time).
Passo 2: Escreva um CLAUDE.md perfeito a nível de projeto
No editor que preferir, abra a raiz do projeto e crie o arquivo CLAUDE.md, jogue o conteúdo de baixo dentro dele (perceba como há poucas linhas — essa é a cara do Sucesso):
# add-demo — Um projetinho mínimo de Python
Tem apenas a função `add`, para demonstrar como configurar o CLAUDE.md.
## Comandos Comuns
- `python -m pytest` —— Rodar os testes
## Padrões de Código
- Todas as funções DEVEM ter Type Annotations (Anotações de tipo)
- Strings usam sempre aspas duplas
## Atenção
- Jamais altere a assinatura da função `add` em `main.py`, mude apenas a lógica interna.Espera-se: Que apareça o CLAUDE.md com os textos em blocos da parte de cima. Suma total de linhas? Umas 15! Decore esse tamanho e aplique nos projetos da vida real, segure a mão para não estourar.
Passo 3: Abra o Claude Code e checar a importação
Onde o projeto reside, execute o comando:
claudeNa entrada já rodando:
/memoryEspera-se: Ver o ./CLAUDE.md que você montou ali na lista. Estando listado é porque o arquivo foi injetado com sucesso na memória atual. Essa é a primeira medida que as diretrizes recomendam quando há problema — Se ele tecer um desrespeito às regras, bata no /memory para ver se o bendito arquivo estava sequer carregado.
Passo 4: Ordene a ele que esbarre nos limites estipulados e confira a lealdade
Ainda lá dentro do chat, mande a seguinte instrução:
Coloque tipo de retorno e tipos nos parâmetros do método addEspera-se: A saída das diffs do Claude entregará sua adição com Types e o uso de aspas (se colocar texto). E também ele nem pensará em alterar o nome e parâmetros do add. Se ele obedecer às cegas a regra do "Anotações de tipo", parabéns, o manual de treinamento foi entregue aos miolos dele.
⚠️ Cuidado, e se ele desobedecer seu CLAUDE.md: verifique em
/memoryse constava nos importados; cheque se a regra não estava fofa demais ("seja higiênico"); observe se alguma outra regra não anulou essa última. Eis os 3 passos de debug para as falhas nesse setor.
💡 Resumo em uma frase: Execute o processo "criar arquivo → pôr menos de 15 linhas de regras →
/memorytestar importação → dar ordens que engatilhem as restrições", se não pegar de jeito, mande o/memorye veja conflito ou texto vago.
08 Conclusão
Nesta seção, o CLAUDE.md e a "memória central do projeto do Claude" foram mapeados do início ao fim:
| Dimensão | Veredito Chave |
|---|---|
| O que é? | Manual de treinamento, lido na largada. É uma "Recomendação" e não regra pétrea! |
| Três Camadas | Usuário (Seu local)/ Projeto (Time + Git) / Subdiretório (Por demanda) |
| A Ordem que manda | Concatena e não deleta, a Mais próxima é lida no fim, Logo ela Manda Mais! |
| O que botar na Mesa | Info/ Stack/ Comandos/ Regras / Proibições. Apague o que o código explica só pelo visual. |
Referência com @ | Para embelezar e arrumar. NÃO poupa os tokens (ele injeta tudo no contexto do mesmo jeito). |
| Faxina Constante | Jogue pra ele "pôr no CLAUDE.md" ou ponha por você mesmo em /memory; corte os ultrapassados e Transforme as reflexões em Regras Secas, Frias e Exigíveis. |
O que você deve saber agora: Bater o olho num pacote de informações e saber onde deve ficar hospedado; Ser afiado ao compilar as regras concretas no formato exigível, utilizar @ pra deixar bonito e ter clareza do pedágio que isso cobra ao Contexto da sessão. E a manutenção e a varredura não lhe é mais algo fora de mão. Em suma - você fará o Claude dançar na sua música e não fará um bloco de 300 parágrafos abandonado e mudo.
No próximo artigo 19 "Gerenciamento de Contexto" — Vimos aqui sobre "Gastos enormes de tokens do CLAUDE.md" e os pesadelos de que "@ suga o contexto sem limite", portanto o que exatamente seria isso e que fim o seu contexto leva se saturar? Que é /context e /compact pra salvar nosso dia? O próximo capítulo limpará a visão deste ambiente de trabalho. Uma semente pro que vem aí: o que devora mais do bot, um CLAUDE.md ou toda sua conversa gravada?