Quatro fluxos de trabalho do Claude Code para desenvolvedores WordPress
A maioria dos artigos sobre assistentes de codificação com IA para WordPress é escrita por pessoas que nunca lançaram um plugin. Você consegue perceber porque os exemplos são sempre "construir um shortcode Hello World" ou "gerar um post type customizado". Ninguém realmente te paga para fazer isso. Eles pagam quando o checkout quebra às 2 da manhã na Black Friday, e o ambiente de staging não consegue reproduzir o problema.
Tenho usado Claude Code em produção desde o início de 2025, principalmente em trabalhos com WordPress e WooCommerce para clientes de consultoria, e no meu próprio plugin WP-AutoInsight. O que segue são quatro fluxos de trabalho que eu realmente executo, com os prompts que eu realmente uso.
Se você ainda não configurou o Claude Code, comece aqui. A configuração do terminal é mais importante do que as pessoas admitem, e não vou repetir esse post.
1. Scaffolding de plugin com aparência moderna
Todo autor de plugin WordPress tem um template privado que cola em novos projetos. O meu estava ficando velho. Propriedades tipadas do PHP 8, namespaces, autoloading, padrões modernos de hooks. O tipo de coisa que você sempre pretende atualizar e nunca faz porque o template existente ainda funciona.
O prompt que uso:
Leia a estrutura de WP-AutoInsight em ~/projects/wp-autoinsight
e use-a como referência para estilo de código, mas gere um novo scaffolding de plugin para
[nome do plugin e descrição de uma linha]. Use PHP 8.1+, namespaces, autoloading PSR-4
via Composer, uma classe main Singleton, e arquivos separados para UI admin,
endpoints REST, e hooks. Inclua readme.txt com o formato WordPress.org.
Não invente funcionalidades. Pare em shells de classe vazios com docblocks apropriados.
A linha "não invente funcionalidades" é essencial. Sem ela, Claude Code vai construir um plugin completamente funcional para algo que você não pediu, e você gastará uma hora deletando código em vez de escrever.
O output é um diretório em que você pode imediatamente fazer git init e começar a trabalhar. Aproximadamente quinze minutos de limpeza comparado aos quarenta minutos de começar do zero.
Qual é o problema? Claude Code às vezes pode gerar código em um formato um pouco desatualizado. Sempre verifique contra a spec atual de readme de plugin antes de enviar.
2. Geração de script WP-CLI para tarefas únicas de cliente
Metade do meu trabalho de consultoria envolve uma frase como "precisamos migrar 4.000 produtos dessa antiga taxonomia para essa nova sem quebrar SEO", e a melhor abordagem é "vamos criar um script WP-CLI", mas não estamos sendo pagos para criar um script; estamos sendo pagos para entregar a migração.
O prompt:
Gere uma classe de comando WP-CLI para [tarefa]. A classe deve: registrar
um comando customizado, aceitar flags --dry-run e --verbose, agrupar operações
em lotes de 200 com saída de progresso WP_CLI::log, lidar com erros por item
sem abortar toda a execução, e escrever um arquivo CSV de log em wp-content/uploads/.
Use $wpdb apenas quando WP_Query/WP_Term_Query não for a solução correta.
Sem dependências externas do composer.
As restrições nesse prompt vêm de coisas que deram errado antes. --dry-run porque precisamos garantir que funcionará no lado do cliente sem erros. Tratamento de erro por item porque uma única linha corrompida interromperá uma migração de uma hora. Arquivo CSV de log porque alguém vai perguntar "quais produtos falharam?" três dias depois, e "não sabemos" não é uma resposta.
Esse é o valor de usar Claude Code em vez de um prompt genérico do ChatGPT. O modelo tem toda a estrutura do projeto disponível. Sabe que classes existem, qual convenção de nomenclatura você usa, e onde você coloca scripts. O script volta, encaixando no seu repositório.
3. Verificações de sanidade em migrações de tema
Não faço muitas migrações de tema mais. Elas são trabalho tedioso, de alto risco e baixa margem. Mas às vezes um cliente de longo prazo pede e, bem, você diz sim.
O que Claude Code faz bem aqui é a parte entediante: comparar dois diretórios de tema e dizer o que é realmente diferente versus o que é apenas espaço em branco e variáveis renomeadas.
Compare ~/projects/client-old-theme e ~/projects/client-new-theme.
Liste, em ordem de prioridade:
(1) arquivos de template no tema antigo que não têm equivalente no novo,
(2) funções registradas no functions.php do tema antigo que não estão registradas
ou têm nomes diferentes no novo,
(3) hooks adicionados/removidos,
(4) scripts e estilos enfileirados que mudaram handles ou caminhos.
Ignore espaço em branco, comentários e números de versão. Saída como uma tabela markdown.
O que isso economiza: aproximadamente quatro horas de varredura manual de diff por migração. O que não substitui: executar o novo tema em staging com conteúdo real e clicar ao redor. Claude Code pode dizer a você a diferença estrutural, mas você ainda precisa testar. A diferença é que agora a migração começa de um lugar sensato.
4. Auditoria de segurança de plugin antes da entrega ao cliente
Este é o fluxo de trabalho que vale a pena.
Quando entrego um plugin a um cliente, seja um que construí ou um que eles estão herdando de um desenvolvedor anterior, faço uma passagem de segurança. Manualmente, isso pode levar tempo, e é o tipo de trabalho em que você comete erros quando está cansado. Claude Code comete os erros para mim, o que prefiro.
Audite o plugin em ~/projects/[caminho-plugin] pelos seguintes itens, nesta ordem:
1. Consultas SQL não usando $wpdb->prepare()
2. Valores $_GET, $_POST, $_REQUEST usados sem funções de sanitização
3. Output não escapado com esc_html, esc_attr, esc_url, ou wp_kses
4. Endpoints AJAX faltando verificação de nonce
5. Verificações de capability faltando em ações admin
6. file_get_contents ou wp_remote_get em URLs fornecidas pelo usuário sem validação
Para cada descoberta, saída: caminho do arquivo, número da linha, o código ofensivo,
e a função WordPress que deveria ser usada em vez disso.
Também, verifique se a base de código é compatível com WPCS e relate novos erros ou avisos que você não capturou.
Não corrija nada ainda. Apenas relate.
"Não corrija nada ainda" é importante. Claude Code é entusiasmado. Se você não especificar, ele começará a tentar corrigir coisas para você, mesmo antes de você decidir se está OK gastar tokens e tempo nisso. Encontre primeiro. Corrija depois, uma descoberta por vez, com você revisando cada mudança.
Também, a linha WPCS é importante. Qualquer desenvolvedor WordPress deveria ter phpcs rodando globalmente, com regras WPCS atualizadas.
O que esses fluxos de trabalho têm em comum
Cada prompt acima inclui uma restrição que impede Claude Code de fazer a coisa errada. "Não invente funcionalidades." "Apenas relate." "Pare em shells de classe vazios." O modelo é útil, mas útil na direção errada é pior que inútil. Aprendi isso pelo caminho caro, em um projeto real de cliente.
Claude Code é a melhor ferramenta de IA que já usei para trabalhos com WordPress, e testei a maioria delas dentro de WP-AutoInsight. Também é aquela que requer mais disciplina. Os prompts acima não são impressionantes. São entediantes. Esse é o ponto.
Se sua equipe está presa na fase de prototipagem com ferramentas de IA e não consegue descobrir como colocá-las em produção com segurança, isso é literalmente o que faço para viver. Mande uma mensagem.