Durante o primeiro mês, usei o Claude Code no estado bruto. Eu escrevia instruções, apertava Enter, lia o código gerado e corrigia. Achava que era suficiente. Mas, na realidade, era como dirigir em uma rodovia com uma habilitação recém-tirada e restrita a carro automático — eu não estava nem extraindo metade do desempenho dele. Houve um momento em que mudar apenas sete configurações fez o comportamento diante da mesma pergunta parecer algo completamente diferente.
Prazer, me chamo Hermes. Sou um profissional que roda IA, especialmente o Claude Code, no dia a dia do trabalho. Ao ler este artigo, você leva para casa essas sete configurações em um formato que dá para testar na hora, com valores de configuração reais.
Este conteúdo é uma prévia gratuita de parte da minha publicação paga "Claude Code Complete Guide". Vou deixar o link no final para quem tiver interesse.
Por que usar no "estado bruto" só entrega metade do desempenho
Se você não configurar nada, o Claude Code começa toda conversa sem saber nada sobre o projeto. Ele não conhece a estrutura de diretórios, as convenções de código nem o que verificar antes de commitar. Então, mesmo que você faça a mesma pergunta, um dia ele pode adivinhar o comando corretamente e, no outro, criar um arquivo no lugar errado.
Isso não é um defeito; é proposital. A documentação oficial afirma claramente que "cada sessão começa com uma página em branco". Em outras palavras, a responsabilidade de extrair o desempenho é do usuário. As sete configurações a seguir servem exatamente para preencher essa "página em branco".
As 7 configurações, com demonstrações
1. CLAUDE.md — Memória do projeto
Colocar um arquivo chamado CLAUDE.md na raiz do projeto faz com que o Claude Code o leia no início de toda sessão. Sem isso, o Claude precisa adivinhar tudo do zero toda vez.
O conteúdo deve ser escrito com a mentalidade de "vou escrever isso para não precisar corrigir o mesmo erro de novo". Escreva detalhes concretos e verificáveis, não filosofias abstratas.
Visão geral do projeto: Inventory Management API (Node.js + PostgreSQL) Execute os testes com npm test / Sempre execute npm run lint antes de commitar Os handlers da API estão localizados em src/api/handlers/
Em vez de "manter o código limpo", diga "indentação de 2 espaços". Em vez de "testar direito", diga "execute npm test". Essa diferença por si só muda significativamente a taxa de acerto do Claude. Como a eficácia cai se o arquivo ultrapassa 200 linhas, o truque é mover os procedimentos detalhados para a Configuração 7 (Skills), que abordaremos mais adiante.
2. hooks — Impondo decisões via máquina
O CLAUDE.md é um "pedido", não uma "exigência". Esse é um mal-entendido comum; é normal o Claude pular instruções sem querer. Regras que você realmente quer que sejam cumpridas devem ser bloqueadas de forma mecânica usando um mecanismo chamado hooks.
Escreva uma configuração assim em .claude/settings.json:
Especifique hooks.PreToolUse com matcher: "Bash" O comando a ser executado é ~/.claude/hooks/check-test.sh
Aqui vai uma demonstração. Antes de adicionar essa configuração, eu vivia enfrentando isto: pedia para o Claude "corrigir um bug", e ele fazia o commit logo depois de corrigir, sem rodar os testes — e eu só percebia os testes quebrados mais tarde.
Ao definir um hook no evento PreToolUse, um script intercepta a execução logo antes de o Claude rodar um comando. Se esse script retornar "exit code 2", a própria operação é bloqueada.
O conteúdo do script apenas executa npm test se detectar um git commit Se os testes falharem, ele exibe "Tests did not pass" e retorna o exit code 2 O exit code 2 é o sinal para o hook bloquear a chamada da ferramenta
A partir do momento em que adicionei essa única peça, fazer commit com os testes no vermelho se tornou fisicamente impossível. A força dos hooks é que você pode confirmar a passagem de "pedido" para "imposição" executando comandos de verdade.
3. Subagentes — Não polua a conversa principal com pesquisa
Se você pedir para ele ler arquivos de log enormes ou explorar o codebase inteiro, essas informações se acumulam no contexto da conversa. Quando o contexto fica poluído, a precisão no cumprimento das instruções cai na segunda metade.
Para evitar isso, use subagentes para transferir a pesquisa e a verificação para uma janela de contexto separada, devolvendo apenas o resumo para o fluxo principal. Por exemplo, se você pedir "Pesquise a implementação de autenticação neste repositório e me diga os pontos-chave", o processo de exploração (ler muitos arquivos e logs) acontece em uma janela separada, e apenas a conclusão volta para a conversa principal.
✗ Continuar deixando que ele leia arquivos de log enormes diretamente na conversa principal
◯ Transferir com "Peça para outro agente pesquisar isso e traga só o resumo"
Tarefas que envolvem "ler muito só para obter informação", como resultados de testes ou recuperação de documentos, valem especialmente a pena ser delegadas a subagentes.
4. Modo de Planejamento — Faça-o escrever um plano antes de colocar a mão na massa
Ao pedir mudanças complexas, o Claude pode começar a escrever código na direção errada, fazendo você refazer tudo depois. O Modo de Planejamento (Plan Mode) é um modo em que ele faz apenas pesquisa e planejamento, sem fazer nenhuma edição.
Você alterna para esse modo com Shift+Tab. No Modo de Planejamento, o Claude lê arquivos e executa comandos de pesquisa, mas não edita o código-fonte. Quando o plano fica pronto, ele é apresentado a você, e só então você decide se aprova.
Se for chato dizer "proponha primeiro" toda vez, você pode definir esse modo como padrão nas configurações do projeto.
Especifique o permissions.defaultMode do settings.json como "plan"
Quanto mais complexa a mudança, maior o retrabalho se o primeiro passo sair errado. O Modo de Planejamento é um seguro contra esse retrabalho.
5. Modos de permissão — Defina onde parar
O Claude Code tem vários modos que pedem confirmação toda vez que ele edita um arquivo ou executa um comando, e modos que seguem automaticamente até certo ponto. Por padrão, ele pede confirmação para tudo, exceto leitura.
No trabalho de implementação do dia a dia, um equilíbrio em que as edições de arquivo seguem automaticamente enquanto as demais coisas pedem confirmação é fácil de lidar. Você pode tornar esse equilíbrio o padrão escrevendo isto no arquivo de configurações:
Especifique o permissions.defaultMode do settings.json como "acceptEdits"
✗ Usar um modo que desativa todas as verificações só porque "pedir confirmação é chato"
◯ Automatizar apenas as edições de arquivo e manter a confirmação para operações destrutivas (como force pushes ou deploys equivalentes a produção)
Na minha experiência, quem define isso como "tudo automático" sem pensar é quem toma sustos com mudanças inesperadas depois. Você pode ir afrouxando as configurações aos poucos, conforme se acostuma com o ponto onde quer que ele pare.
6. Gerenciamento de contexto — Limpe a sala com frequência
Se você mantém uma única conversa por tempo indefinido, históricos irrelevantes continuam no contexto, desperdiçando tokens e reduzindo a precisão das respostas.
Digite /clear para limpar a conversa por completo ao mudar para uma tarefa não relacionada. É só isso. Para conversas que você quer retomar depois, use /rename para dar um nome antes de limpar, assim você pode chamá-las de volta sem se perder.
✗ Reutilizar a mesma conversa de manhã à noite, com tópicos não relacionados de ontem ainda pairando no ar
◯ Usar /clear nas fronteiras entre tarefas e, se necessário, /rename antes
Se a Configuração 3 (Subagentes) serve para "isolar a pesquisa dentro de uma única tarefa", esta Configuração 6 serve para "isolar entre tarefas". Fazer as duas coisas é a única forma de manter o contexto verdadeiramente limpo.
7. Skills — Mantenha os procedimentos fora da conversa
Se você fica adicionando procedimentos ao CLAUDE.md, o próprio arquivo incha, aumentando o volume lido no início de toda sessão. Além disso, procedimentos que você não usa com frequência continuam sendo lidos mesmo em tarefas não relacionadas.
É aí que entram as Skills. Se você colocar um arquivo SKILL.md em .claude/skills/, ele só será lido quando for necessário. Se o CLAUDE.md é a "memória que precisa ser lida toda vez", uma Skill é um "manual aberto apenas quando necessário".
Por exemplo, se você tem procedimentos longos que não são usados com frequência, como etapas de revisão de PR ou de migração de banco de dados, mova-os do CLAUDE.md para o lado das Skills. As conversas do dia a dia continuam leves, e você só paga o peso quando necessário.
Resumo — O que acontece sem essas 7?
Aqui estão os pontos-chave.
Sem o CLAUDE.md, o Claude adivinha tudo do zero toda vez. Sem hooks, as regras definidas continuam sendo apenas "pedidos" e podem ser quebradas. Sem subagentes e /clear, o contexto fica poluído e a precisão cai. Sem o Modo de Planejamento, você arca com o risco de retrabalho em mudanças complexas. Se você definir os modos de permissão descuidadamente, perde o ponto de parada de operações inesperadas. Sem Skills, o CLAUDE.md fica cada vez mais pesado.
Por outro lado, essa também é uma história de "quem não configura essas 7 fica no prejuízo". Se você está lendo isto e ainda não configurou um CLAUDE.md nem usou /clear uma única vez, esse é o seu espaço para evoluir.
Você não precisa fazer tudo de uma vez. Comece apenas com o CLAUDE.md e o Modo de Planejamento no trabalho de hoje. Mesmo isso já é suficiente para sentir a diferença do estado bruto na hora.
Também compilei de forma sistemática configurações mais aprofundadas e armadilhas comuns da prática na minha publicação paga "Claude Code Complete Guide". Para quem tiver curiosidade sobre o que vem depois dessas 7, é só clicar aqui.
