Dicas de Fluxo de Trabalho Claude Code de 18 Meses de Uso Diário
No início de 2025, pedi ao Claude para corrigir um cálculo de impostos WooCommerce, e ele reescreveu toda a classe de 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 me levou a maior parte daquele primeiro ano para admitir. Após 18 meses de uso diário em projetos WordPress de clientes e em WP-AutoInsight, os hábitos que sobreviveram são sobre controlar escopo e contexto: um CLAUDE.md mantido, modo Plano antes de qualquer coisa arriscada, tarefas pequenas, saída de erro bruta e gerenciamento deliberado de contexto.
Aqui está o que pegou, e por quê.
Por que CLAUDE.md importa mais do 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 escaneia a base de código e o gera: o que o projeto faz, como está estruturado, quais comandos 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 há uma tabela legada que ninguém pode tocar. Todo esse processo de redescoberta é gasto em tokens, ou, pior, 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 de inscrições diretamente." "phpcs deve passar antes de qualquer commit." E assim por diante.
Se uma regra importa, ela entra no arquivo.
Algumas instruções merecem avançar para mais longe, em comandos reutilizáveis. Escrevi sobre essa decisão em quando um prompt se torna uma habilidade Claude Code, então não vou repeti-la aqui.
Quando o modo Plano vale a pena?
O modo Plano faz Claude Code esboçar uma abordagem e fazer perguntas antes de escrever uma única linha. Meu limiar: qualquer coisa que toque em mais de alguns arquivos ou modifique dados, e absolutamente qualquer coisa conectada ao ambiente de produção de um cliente.
O trabalho de cobrança de inscrições WooCommerce que fiz para um cliente de e-commerce canadense é o exemplo mais claro. Um refator confiante que muda quando uma renovação é acionada pode custar dinheiro real antes que alguém perceba. Em modo Plano, Claude apresentou suas mudanças pretendidas primeiro, e eu capturei uma suposição errada sobre a ordenação de webhooks antes que qualquer código existisse.
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-o.
Por que tarefas pequenas vencem grandes pedidos?
Pedir ao Claude Code para "construir o recurso" produz algo que funciona e precisa de uma semana de correções. Pedir para ele construir a página de configurações, depois o endpoint REST, depois o gerenciador cron, depois a rotina de desinstalação, produz quatro coisas que você realmente revisou.
Esta é a mesma lição que agências aprendem sobre desenvolvedores humanos. Na Green Hat, executei arquitetura para 30+ projetos de clientes simultâneos, e os projetos que saíram do rumo foram aqueles com escopo "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: quebre 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.
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 para a sessão, significando o rastreamento de stack completo e a notificação PHP exata com arquivo e número de 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 melhor contexto. Então "a etapa de pagamento morre depois que o cupom é aplicado" fez Claude trabalhar em direção à lógica do cupom, quando o erro era na verdade causado por um plugin de terceiros.
Mesma regra para logs. Trechos de wp-content/debug.log, saída de cron falhada, corpos de resposta HTTP, erros de banco de dados.
Como você gerencia a janela de contexto antes que ela o gerencie?
As sessões do Claude Code degradam conforme a janela de contexto se enche. 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 rígido. Esta é uma observação de uso diário; trate-a como uma estimativa, mas o padrão é consistente o suficiente para que eu agora gerencie 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 compacta a conversa preservando detalhes-chave, o que é correto quando você está no meio de uma tarefa e precisa continuar. /clear a limpa, o que é correto 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 se estende por dias, termino sessões pedindo ao 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 de um documento de transição de desenvolvedor, exceto o desenvolvedor em ambos os lados é o mesmo modelo sem memória.
Feche a lacuna ao 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 bons dias, a resposta é nada. Frequentemente é uma linha: uma convenção que estabelecemos ou um problema que enfrentamos. 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 nesta lista e aquele com o maior retorno. 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 Plano primeiro. Cada tarefa: com escopo pequeno o suficiente para verificar rapidamente. Cada bug: saída bruta, nunca um resumo. Sessões longas: /compact ou um arquivo de transição. Cada sessão: uma pergunta ao final sobre o que vale a pena escrever.
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.
Se sua equipe adotou Claude Code e os resultados são inconsistentes, a lacuna é quase sempre no fluxo de trabalho e nos guardrails em torno da ferramenta. Auditar essa configuração e tornar o desenvolvimento assistido por agente seguro para produção é exatamente o tipo de consultoria que faço.