A maioria dos artigos sobre assistentes de programação com IA pra WordPress é escrita por gente que nunca lançou um plugin. Dá pra perceber, porque os exemplos são sempre "criar um shortcode Hello World" ou "gerar um post type personalizado". Ninguém te paga pra fazer isso. Te pagam quando o checkout quebra às 2 da manhã na Black Friday e o staging não consegue reproduzir o problema.
Uso o Claude Code em produção desde o começo de 2025, principalmente em trabalho de WordPress e WooCommerce pra clientes de consultoria e no meu próprio plugin, o WP-AutoInsight. A seguir estão quatro fluxos que eu rodo de verdade, com os prompts que eu uso de verdade.
Se você ainda não configurou o Claude Code, comece por aqui. A configuração do terminal importa mais do que as pessoas admitem, e não vou repetir aquele post.
1. Esqueleto de plugin com cara de moderno
Todo autor de plugin WordPress tem um template particular que cola em projeto novo. O meu estava envelhecendo. Propriedades tipadas do PHP 8, namespaces, autoloading, padrões modernos de hooks. O tipo de coisa que você sempre pretende atualizar e nunca atualiza, porque o template antigo ainda funciona.
O prompt que eu 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, o Claude Code constrói um plugin inteiro e funcionando pra algo que você não pediu, e você passa uma hora apagando código em vez de escrever.
O resultado é uma pasta em que você já pode dar git init e começar a trabalhar. Uns quinze minutos de limpeza, contra os quarenta de começar do zero.
O porém: às vezes o Claude Code gera o código num formato meio desatualizado. Confira sempre com a especificação atual do readme de plugins antes de publicar.
2. Scripts WP-CLI pra tarefas avulsas de cliente
Metade do meu trabalho de consultoria começa com uma frase tipo "precisamos migrar 4.000 produtos dessa taxonomia antiga pra essa nova sem quebrar o SEO", e o melhor caminho é "vamos escrever um script WP-CLI". Só que ninguém está pagando pelo script; estão pagando pela migração entregue.
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.
Cada restrição desse prompt vem de algo que já deu errado antes. --dry-run porque a gente precisa ter certeza de que vai rodar sem erro no ambiente do cliente. Tratamento de erro por item porque uma única linha corrompida derruba uma migração de uma hora. Log em CSV porque alguém vai perguntar "quais produtos falharam?" três dias depois, e "não sabemos" não é resposta.
Esse é o valor de usar o Claude Code em vez de um prompt genérico no ChatGPT. O modelo tem a estrutura inteira do projeto à mão. Sabe que classes existem, que convenção de nomes você usa e onde você guarda os scripts. O script volta já encaixado no seu repositório.
3. Conferência de sanidade em migração de tema
Hoje em dia faço pouca migração de tema. É trabalho chato, de risco alto e margem baixa. Mas às vezes um cliente antigo pede e, bom, você diz sim.
O que o Claude Code faz bem aqui é a parte chata: comparar duas pastas de tema e dizer o que mudou de verdade e o que é só espaço em branco e variável renomeada.
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: umas quatro horas de diff manual por migração. O que não substitui: rodar o tema novo em staging com conteúdo real e sair clicando. O Claude Code te mostra a diferença estrutural, mas o teste continua sendo seu. A diferença é que agora a migração começa de um ponto razoável.
4. Auditoria de segurança de plugin antes de entregar pro cliente
Este é o fluxo que se paga.
Quando entrego um plugin pra um cliente, seja um que eu construí ou um que ele herdou de outro desenvolvedor, faço uma passada de segurança. Na mão, isso leva tempo, e é o tipo de trabalho em que a gente erra quando está cansado. O Claude Code erra por mim, e eu prefiro assim.
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.
O "não corrija nada ainda" é importante. O Claude Code é empolgado. Se você não disser, ele começa a consertar as coisas por conta própria, antes mesmo de você decidir se vale gastar token e tempo com isso. Primeiro encontra. Depois corrige, um achado por vez, com você revisando cada mudança.
A linha do WPCS também importa. Todo desenvolvedor WordPress deveria ter o phpcs rodando globalmente, com as regras do WPCS atualizadas.
O que esses fluxos têm em comum
Todo prompt acima tem uma restrição que impede o Claude Code de fazer a coisa errada. "Não invente funcionalidades." "Apenas relate." "Pare em shells de classe vazios." O modelo é prestativo, mas prestativo na direção errada é pior que inútil. Aprendi isso do jeito caro, num projeto real de cliente.
O Claude Code é a melhor ferramenta de IA que já usei pra trabalho com WordPress, e testei a maioria delas dentro do WP-AutoInsight. Também é a que mais exige disciplina. Os prompts acima não impressionam ninguém. São chatos. E é exatamente essa a ideia.
Se o seu time está preso na fase de protótipo com ferramentas de IA e não consegue descobrir como levar isso pra produção com segurança, isso é trabalho de IA em WordPress em produção. Me manda uma mensagem.