No início de 2025, pedi a Claude para corrigir um cálculo de imposto WooCommerce, e ele reescreveu toda a classe checkout. Código funcionando, escopo errado, quarenta minutos de revisão de diff para uma correção de duas linhas.
O fluxo de trabalho era o problema, e levou a maior parte daquele primeiro ano para eu admitir. Após 18 meses de uso diário em projetos WordPress com clientes e em WP-AutoInsight, os hábitos que sobreviveram são sobre controlar escopo e contexto: um CLAUDE.md curto e mantido, modo Plan antes de qualquer coisa arriscada, tarefas pequenas, saída de erro bruta, uma verificação que Claude pode executar em seu próprio trabalho, e gestão deliberada de contexto.
Aqui está o que funcinou e por quê.
Por que CLAUDE.md importa mais que seus prompts?
CLAUDE.md é o arquivo que Claude Code lê no início de cada sessão em um diretório de projeto. Execute /init e Claude verifica a base de código e o gera: o que o projeto faz, como está estruturado, quais comandos o constroem e testam, e onde estão os pontos de entrada. É um README glorificado, escrito para uma máquina que esquece tudo entre sessões.
Essa amnésia é a parte que as pessoas subestimam. Cada nova sessão começa do zero. Sem CLAUDE.md, o modelo gasta a primeira parte de cada conversa redescobrir que seu plugin usa autoloading PSR-4, que deploys passam por um script específico, que existe uma tabela legada que ninguém pode tocar. Todo esse processo de redescoberta é gasto em tokens, ou, pior ainda, em suposições erradas.
O arquivo gerado é um ponto de partida. Mas o valor real vem de refiná-lo. O meu acumula regras para corrigir problemas que comecei a notar durante o uso. "Nunca modifique a tabela subscriptions diretamente." "phpcs deve passar antes de qualquer commit." E assim por diante.
Se uma regra importa, ela entra no arquivo.
O inverso importa igualmente: se uma regra não ganha seu lugar, ela sai. O arquivo carrega em cada sessão, e as melhores práticas da Anthropic avisamque um CLAUDE.md inchado faz Claude ignorar as instruções que você se importa. Pode a arquivo da forma que podaria código morto. Se Claude já faz algo certo sem a linha, delete a linha.
Algumas instruções merecem se graduar ainda mais, em comandos reutilizáveis. Escrevi sobre essa decisão em quando um prompt vira um skill do Claude Code, então não vou repetir aqui.
Quando o modo Plan vale a pena?
O modo Plan faz Claude Code elaborar uma abordagem e fazer perguntas antes de escrever uma única linha. Meu limiar: qualquer coisa que afete mais de um par de arquivos ou modifique dados, e absolutamente qualquer coisa conectada ao ambiente de produção de um cliente.
O trabalho de faturamento de subscriptions WooCommerce que fiz para um cliente de e-commerce canadense é o exemplo mais claro. Uma refatoração confiante que muda quando uma renovação dispara pode custar dinheiro real antes de alguém notar. No modo Plan, Claude apresentou suas mudanças planejadas primeiro, e detectei uma suposição errada sobre ordenação de webhooks antes de qualquer código existir.
Revisar um plano leva dois minutos. Revisar uma mudança que quebrou seu site pode custar horas. E dinheiro.
Para uma correção CSS de um arquivo ou um script WP-CLI descartável? Pule.
Por que tarefas pequenas vencem grandes asks?
Pedir a Claude Code para "construir o recurso" produz algo que executa e precisa de uma semana de correções. Pedir para construir a página de configurações, então o endpoint REST, então o handler cron, então a rotina de desinstalação, produz quatro coisas que você realmente revisou.
Esta é a mesma lição que agências aprendem sobre desenvolvedores humanos, e impô-la em toda uma equipe é uma parte permanente de um engajamento de CTO fracionário. Na Green Hat, executei arquitetura para 30+ projetos simultâneos de clientes, e os projetos que saíram dos trilhos foram os escopo como "faça funcionar" em vez de uma sequência de passos verificáveis. Um agente de IA com acesso ao repositório falha da mesma forma, apenas mais rápido e com mais confiança.
A versão prática: divida o trabalho em tarefas onde você pode verificar o resultado em menos de dez minutos. A estrutura de prompt que uso força isso tornando a linha de Ação específica o suficiente para testar.
O escopo pequeno também protege sua janela de contexto, o que nos leva ao próximo hábito.
Cole o erro bruto, pule seu resumo dele
Quando algo quebra, o caminho mais rápido é copiar a saída de erro completa na sessão, significando o rastreamento de stack completo e o aviso PHP exato com número de arquivo e linha. Seu paráfrase de um bug remove os detalhes que o modelo mais precisava.
Um cliente meu gostava de fazer suposições e pedir correções, em vez de colar os logs e saídas de erro para que Claude tivesse contexto melhor. Então "a etapa de pagamento morre depois que o cupom é aplicado" fez Claude trabalhar em direção à lógica de cupom, quando o erro era de fato causado por um plugin de terceiros.
Mesma regra para logs. Trechos de wp-content/debug.log, saída cron falhada, corpos de resposta HTTP, erros de banco de dados.
Dê a Claude uma verificação que ela pode executar
A primeira dica na página de melhores práticas da Anthropic é a que eu colocaria em primeiro lugar também: dê a Claude uma forma de verificar seu próprio trabalho. Sem uma, Claude para quando o trabalho parece pronto, e você vira a suíte de testes. Cada erro espera você notá-lo.
A verificação é qualquer coisa que retorna passar ou falhar: uma suíte de testes, uma construção, um linter, um script que compara saída contra um resultado conhecido. No trabalho WordPress, phpcs já está em meu CLAUDE.md como uma regra, então pedir a Claude para executá-lo e corrigir o que relata não custa nada. Um comando WP-CLI que confirma que o evento cron foi agendado, ou uma execução PHPUnit quando o plugin tem testes, fecha o loop da mesma forma.
Então peça pela evidência, significando o comando que ela executou e a saída que obteve. "Todos os testes passam" é uma reivindicação. A saída é prova, e lê-la leva menos tempo do que executar tudo novamente você mesmo.
Como você gerencia a janela de contexto antes que ela o gerencie?
As sessões Claude Code se degradam conforme a janela de contexto se enche. A ferramenta compacta automaticamente quando você chegar perto do limite, mas isso é uma rede de segurança. Na minha experiência, uma vez que uma sessão longa fica pesada com diffs antigos e becos sem saída, a qualidade da saída cai bem antes de você atingir qualquer limite físico. Esta é uma observação do uso diário; trate como uma estimativa, mas o padrão é consistente o suficiente que agora gerencio contexto deliberadamente em vez de esperar o modelo ficar burro.
Três ferramentas, três trabalhos. /context mostra o que está consumindo a janela. /compact comprime a conversa preservando detalhes-chave, que é certo quando você está no meio da tarefa e precisa continuar. Também leva instruções, como /compact keep the list of modified files, que bate esperança de que o resumo mantenha o que você precisa. /clear limpa, que é certo quando você está mudando para algo não relacionado. Arrastar contexto de refatoração de ontem para a tarefa de SEO de hoje não ajuda ninguém e custa tokens.
Para trabalho que dura dias, termino sessões pedindo a Claude para escrever um arquivo de transição: status atual, decisões tomadas, perguntas abertas, próximos passos, salvo como markdown no projeto. A próxima sessão começa lendo-o. É a mesma disciplina que um documento de handoff de desenvolvedor, exceto que o desenvolvedor em ambos os lados é o mesmo modelo sem memória.
Feche o loop no final de cada sessão
A última mensagem de minhas sessões de trabalho é geralmente uma versão de "o que devo adicionar a CLAUDE.md com base no que fizemos hoje?"
Em dias bons, a resposta é nada. Muitas vezes é uma linha: uma convenção que estabelecemos ou um problema que atingimos. Ao longo dos meses, o arquivo se torna conhecimento institucional para uma equipe de um humano e um modelo.
Este é o hábito mais barato desta lista e o com o retorno mais longo. Cada regra capturada é um erro que não se repete, neste projeto e em cada sessão futura.
Então qual é a aparência do fluxo de trabalho montado?
Novo projeto: /init, depois edite CLAUDE.md à mão. Tarefa complexa ou arriscada: modo Plan primeiro. Cada tarefa: escopo pequeno o suficiente para verificar rapidamente, com uma verificação que Claude pode executar. Cada bug: saída bruta, nunca um resumo. Sessões longas: /compact ou um arquivo de transição. Cada sessão: uma pergunta no final sobre o que vale a pena anotação.
Nada disso é inteligente. Esse é o ponto. Os desenvolvedores obtendo resultados consistentes do Claude Code em trabalho WordPress real estão executando um processo entediante e repetível em torno de uma ferramenta muito capaz.
A outra metade do processo é o que você para de fazer. O conselho popular que dropei, das palavras-chave "pense mais cuidadosamente" à bandeira de permissões, está em Dicas do Claude Code que você pode ignorar com segurança.
Se sua equipe adotou Claude Code e os resultados são inconsistentes, o gap é quase sempre no fluxo de trabalho e nas proteções em torno da ferramenta. Auditar essa configuração é parte do trabalho de consultoria de CTO fracionário. Diga-me onde está inconsistente.