É 2022. Estou há três horas configurando um bloco de depoimentos no WordPress (o terceiro daquele trimestre) e paro pra pesquisar se RichText.Content vai na função de save ou no render callback. Eu já sei a resposta; já fiz exatamente isso várias vezes ao longo dos anos. Mas a troca de contexto ainda custa alguns minutos, e quando volto, já esqueci o que eu estava tentando resolver de verdade.
Foi aí que o Claude começou a ficar útil no meu trabalho com WordPress.
Não como substituto pra entender o codebase. Se você não sabe o que wp_enqueue_scripts faz, o Claude gerar isso pra você não ajuda na hora de debugar depois, quando o cliente reclamar de um bug. Mas como uma forma de continuar focado no problema enquanto ele cuida da mecânica: scaffolding de blocos, registro de hooks, aquele array de argumentos do register_post_type que eu reescrevo do zero em todo projeto porque nunca lembro se has_archive vem antes ou depois de rewrite, mesmo depois de criar uns macros no VSCode. O Claude cuida da maquinaria enquanto eu foco na arquitetura. É um desenvolvedor júnior competente que nunca cansa de boilerplate.
Então, aqui está como eu uso de verdade, com detalhe suficiente pra ser útil de imediato.
Antes de Escrever Qualquer Prompt
A diferença de produtividade entre "o Claude é útil" e "o Claude é irritante" mora quase inteiramente no contexto inicial. Cole um pedido vago e receba código genérico. Dê ao Claude as restrições reais do seu projeto e receba algo que você consegue jogar direto em wp-content/plugins/ depois de um code review e uma rodada de testes.
Eu mantenho um template de contexto de projeto salvo em markdown. Leva dois minutos pra preencher e elimina a maioria dos loops de revisão:
# Plugin WordPress — Contexto para o Claude Code
## Identidade do projeto
- Nome do plugin: [Nome do Plugin]
- Text domain: [text-domain]
- WordPress mínimo: 6.6
- PHP mínimo: 8.2
- Build: @wordpress/scripts
## Antes de gerar qualquer coisa
Leia o arquivo principal do plugin e uma classe existente antes de escrever código novo.
Se existirem blocos, leia um bloco completo (block.json + edit.js + render.php) antes de criar outro.
Se existirem patterns, leia patterns/ antes de criar um novo pattern.
Siga a nomenclatura, a estrutura de classes e a organização de arquivos do que já existe.
## Arquitetura
- Hooks são registrados através de uma classe Loader (includes/class-loader.php). Hooks novos entram lá, não inline.
- Uma classe por arquivo. Nome do arquivo: class-[nomedaclasse].php em kebab-case.
- Blocos: src/blocks/[nome-do-bloco]/ — cada bloco tem seu próprio diretório.
- Custom post types: includes/class-post-types.php
- Endpoints REST: includes/class-rest-api.php
- Admin: admin/class-admin.php
- Frontend: public/class-public.php
## JavaScript
- Sem jQuery. Use as APIs nativas wp.* ou JS puro.
- REST API para operações assíncronas. Nada de novos hooks wp_ajax_.
- Só módulos ES. Sem require() do CommonJS.
- Para blocos interativos: use a Interactivity API (wp-interactivity), não event listeners customizados.
## Segurança — inegociável
- Sanitize toda entrada: `sanitize_text_field()`, `absint()`, `wp_kses_post()` — combine a função com o tipo de dado.
- Escape toda saída: `esc_html()`, `esc_url()`, `esc_attr()` — nunca dê echo em dado cru.
- Verifique nonces em todo envio de formulário e em todo handler REST de escrita.
- Cheque capabilities antes de qualquer escrita de dados. Use a capability mais específica disponível, não `edit_posts` como curinga.
- `$wpdb->prepare()` em toda query direta, sem exceção.
## O que não fazer
- Nada de funções deprecated. Na dúvida, confira o changelog do WP contra a versão mínima.
- Nada de versão do plugin hardcoded em `wp_enqueue_*`. Use a constante do plugin.
- Nada de `extract()`. Nada de short tags do PHP.
- Não defina `publicly_queryable => true` num CPT a menos que ele precise de arquivo público.
- Nada de WP_Query buscando objetos de post completos quando só IDs ou meta são necessários.
- Nada de hooks dentro de construtores de classe. Eles passam pelo Loader.
- Nada de `update_option()` sem checar o valor atual antes, em dados grandes.
## Padrões
- PHPCS com o ruleset do WordPress em tudo.
- Toda string visível pro usuário com o text domain do plugin.
- DocBlocks em todas as classes e métodos públicos.
## Antes de dar uma tarefa por concluída
Varra os arquivos criados ou modificados procurando:
1. Funções deprecated para a versão mínima do WP
2. Saída sem escape
3. Checagens de capability faltando em operações de escrita
4. Nonces em todo formulário e endpoint REST de escrita
5. Qualquer `publicly_queryable` configurado errado
6. Strings sem internacionalização
7. Hooks registrados fora do Loader
Salve isso como o CLAUDE.md inicial do projeto, ou no prompt do seu projeto no Claude Web, e faça o prompt de verdade depois. Isso tem um efeito específico: força o Claude a gerar código que combina com o seu projeto real, em vez de exemplos genéricos de WordPress de 2019. Ele vai seguir o padrão daquela versão do PHP. Vai pesquisar o que aquela versão do WordPress faz que ele não conhece. Se você ainda dá suporte ao WordPress 5.8, diga. Se precisa de compatibilidade com PHP 7.4, deixe claro — ou seu plugin vai quebrar em produção.
A janela de contexto é grande o suficiente pra caber a estrutura inteira do seu plugin mais exemplos. Use isso.
Construindo Blocos Gutenberg Passo a Passo
Começando pelo Scaffold
Um bloco Gutenberg novo exige no mínimo quatro arquivos: block.json, um componente edit.js, um render callback em PHP e uma folha de estilos. O que toma tempo é a funcionalidade de verdade. O scaffold não deveria tomar.
Com o Claude Code rodando dentro do diretório do projeto, o ponto de partida é diferente da interface web. Você não descreve sua estrutura de arquivos; o Claude Code lê. Ele vê o que já existe em src/blocks/, como seus block.json estão estruturados e qual convenção de nomes você usa nas classes. O contexto é o codebase de verdade.
O prompt vira isto:
Olhe os blocos existentes em src/blocks/ para entender minhas convenções.
Depois crie um bloco de depoimento:
- Texto da citação (RichText, strip_tags no save)
- Nome do autor (PlainText)
- Foto do autor (MediaUpload com preview da imagem no editor)
- Avaliação em estrelas (atributo numérico, 1–5, armazenado como inteiro)
- Cor de fundo opcional vinda da paleta de cores do tema
Crie os quatro arquivos no diretório certo.
O Claude Code cria block.json, edit.js, render.php e style.scss diretamente. Sem copiar e colar. O block.json vem com os attribute sources corretos, o render callback vem com esc_html() e absint() onde devem estar, e os nomes de classe seguem o seu padrão existente, porque o Claude Code conferiu antes de gerar.
Você ainda revisa antes de commitar. Falo disso mais adiante.
Isso se acumula quando você está construindo um design system com doze tipos de bloco. Cada scaffold segue as suas convenções reais, não um exemplo genérico de WordPress.
Adicionando Variações de Bloco
Variações de bloco são onde o acesso aos arquivos rende mais. O Claude Code lê seu bloco de card existente antes de gerar as variantes horizontal e empilhada, então os nomes de atributos, classes e valores padrão batem com o que você já tem.
Salve variações em src/blocks/card/variations.js. O Claude Code cria o arquivo e importa no edit.js se você pedir.
A pergunta que ele continua sem conseguir responder: se uma variação é o padrão certo, ou se você precisa de um bloco separado. Isso depende da experiência de edição que você está projetando.
InnerBlocks e Lógica de Restrição
Padrões com InnerBlocks complicam rápido, entre allowedBlocks, template locks e configurações de orientação. Peça a implementação completa, incluindo o array de template e as configurações de lock. Especifique quantos blocos o usuário pode adicionar, se o template é travado e quais tipos de bloco são permitidos dentro.
Peça pro Claude Code checar suas implementações existentes de InnerBlocks primeiro. Consistência na sua biblioteca de blocos importa mais do que qualquer bloco individual estar tecnicamente correto isolado.
Teste a experiência no editor manualmente depois. O que parece certo no código às vezes cria uma UX inesperada no editor de blocos.
Arquitetura de Plugin Sem Cerimônia
O Padrão Loader
O Claude Code lê o arquivo principal do plugin antes de gerar qualquer coisa. Se você já tem uma estrutura, ele estende em vez de produzir um scaffold novo que conflita com o que está lá. Começando do zero, o prompt é:
Gere um scaffold de plugin WordPress com padrão loader:
- Nome do plugin: Seu Plugin, text domain: seu-plugin
- A classe Loader armazena arrays de actions e filters e executa no run()
- A classe Admin enfileira scripts só do admin em admin_enqueue_scripts
- A classe Public enfileira scripts do frontend em wp_enqueue_scripts
- O arquivo principal instancia e roda tudo em plugins_loaded
Crie todos os arquivos nos diretórios corretos.
O Claude Code cria includes/class-loader.php, admin/class-admin.php, public/class-public.php e o arquivo principal do plugin. Você adiciona a funcionalidade de verdade na estrutura de classes existente. É aqui que o scaffold compensa: você adiciona métodos em classes organizadas, em vez de despejar tudo num arquivo monolítico que vira algo impossível de manter no terceiro mês.
Custom Post Types
O array de argumentos do register_post_type tem cerca de trinta chaves possíveis. Você usa umas dez com frequência. O Claude Code gera a chamada completa a partir de uma descrição simples e cria ou atualiza o arquivo certo:
Registre o custom post type 'project':
- Hierárquico (como páginas)
- Arquivo em /projects/
- Suporta: title, editor, thumbnail, custom-fields
- Capabilities customizadas: edit_projects, publish_projects
- Map meta cap: true
- Excluir dos resultados de busca padrão
Se você já tem uma classe de post types, o Claude Code adiciona o novo CPT nela. Um passe de revisão pra confirmar o rewrite slug, os nomes das capabilities e se publicly_queryable está configurado corretamente. Peça pro Claude Code conferir suas definições de capability existentes na mesma sessão, antes de fechá-la.
Queries Customizadas no Banco
Quando você precisa de um WP_Query além do loop de posts padrão, o Claude Code gera o array de argumentos e consegue varrer suas queries existentes procurando o padrão N+1 antes que ele se acumule. Inclua só os campos que você realmente precisa: fields => 'ids' quando só precisa de IDs, no_found_rows => true quando não precisa de paginação.
Uma query que busca objetos de post completos quando você só precisa dos títulos é inofensiva num site pequeno e um problema real num site grande. Pra mais sobre otimização de velocidade no WordPress, tem um detalhamento de como a estrutura das queries afeta a performance em escala.
Padrões FSE em Escala
Block patterns são uma das tarefas mais repetitivas no desenvolvimento de temas FSE. O markup de uma seção hero com imagem de fundo, título e CTA não é difícil, é só denso. Com o Claude Code no diretório do tema, ele lê seus patterns existentes antes de gerar novos. Sem conflitos de nome. Classes que batem com o que você já tem.
Olhe os patterns em patterns/ para entender as convenções de nomenclatura.
Depois gere um pattern hero-with-cta:
- Slug do pattern: hero-with-cta
- Categoria: theme/heroes
- Bloco Cover full-width com overlay escuro de 50%
- Dentro: Group constrained com H1, parágrafo e bloco Button
- Só blocos do core
- Docblock PHP para registro automático no WordPress 6.4+
Crie o arquivo em patterns/.
O Claude Code cria o arquivo. Teste no editor e ajuste o espaçamento pros seus design tokens.
Sobre Errar
Esta seção é mais longa que as outras porque é a que importa quando algo quebra em produção.
O Claude Code gera código plausível. Plausível não é o mesmo que correto, e correto não é o mesmo que seguro pro seu contexto específico. Os modos de falha que eu mesmo já encontrei: um endpoint REST que verificava nonces mas não checava as capabilities do usuário antes de escrever dados; um WP_Query que buscava objetos de post completos quando eu só precisava de IDs, inofensivo até o site ter 80.000 posts; uma chamada de register_post_type que deixou publicly_queryable como true num CPT que era pra ficar interno. Nenhum desses foi pego automaticamente. Todos foram pegos lendo o código antes do deploy.
O Claude Code pega mais coisa que a interface web, porque consegue buscar no seu codebase de verdade. Depois de gerar, peça pra ele revisar a própria saída:
Revise os arquivos que você acabou de criar procurando:
- Funções deprecated do WordPress
- Checagens de capability faltando
- Saída sem escape
- Qualquer nome de função que eu deva verificar na documentação do WP para a minha versão
Ele pode encontrar problemas ou não. Mas é comum ver alguns escaparem da revisão.
A brecha de segurança que sobra é específica: o Claude Code conhece os padrões — sanitizar na entrada, escapar na saída, verificar nonces nos formulários. O que ele não conhece é o seu modelo de permissões. Se o seu plugin tem múltiplos papéis de usuário interagindo com os mesmos dados, o Claude Code frequentemente escreve checagens de capability que estão tecnicamente corretas isoladas e erradas pro seu setup. Ele pode checar current_user_can('edit_posts') onde o seu plugin exige uma capability customizada definida em outro arquivo. Isso não é alucinação. É contexto que você não deu. Resolve pedindo pro Claude Code ler sua estrutura de capabilities existente antes de escrever o endpoint.
Migrações de banco continuam sendo a única categoria em que eu trato a saída do Claude Code como primeiro rascunho. O código da migração geralmente está bom. O que falta é o conhecimento dos seus dados reais: os posts importados seis anos atrás com valores de meta estranhos, as linhas legadas que não seguem o schema que você assumiu ser universal. O Claude Code não tem como saber disso. Rode migrações contra um banco de staging com snapshot de produção primeiro. Isso vale tanto pra código do Claude Code quanto pro seu.
O problema das funções deprecated é real, mas detectável. Os dados de treinamento do Claude Code incluem muito código antigo de WordPress, e de vez em quando ele puxa funções que ainda existem mas foram deprecated na 5.5 ou na 6.0. Peça uma varredura depois de gerar. Ele costuma encontrar. A varredura ainda leva trinta segundos. Não pule.
Leia cada arquivo antes de ir pro controle de versão. O fato de o Claude Code ter criado o arquivo diretamente não torna a revisão opcional.
Por fim, depois de corrigir o que der e quando sentir que o codebase já evoluiu o bastante, peça pro Claude Code revisar o projeto e atualizar o CLAUDE.md com os novos padrões e checagens que você criou, pra garantir que ele não repita comportamentos antigos.
O Claude Code é rápido e tem contexto do seu codebase real. Você continua responsável pelo que vai pro ar. Pode acreditar: as duas coisas são verdade.
Usar o Claude Code no desenvolvimento WordPress não é um ganho de velocidade se você contar tarefa por tarefa. É o acúmulo: os quinze minutos que você não gastou na documentação, o boilerplate que não escreveu do zero pela oitava vez, as convenções que ficaram consistentes em doze blocos sem você fiscalizar manualmente, o passe de revisão que pegou o problema de permissões antes de chegar em produção.
O Claude Code cuida do trabalho básico e chato. COMO aquilo vai ser construído continua sendo decisão sua.
Este texto faz parte de uma série sobre usar o Claude em trabalho de produção. Se você quer a versão sem código do argumento de contexto — como configurar Claude Projects pra trabalho em chat, em vez de num codebase — escrevi essa pra consultores equilibrando vários clientes. E se você está avaliando Claude contra ChatGPT antes de se comprometer com algum, o guia honesto cobre onde cada um realmente ganha.
Se o seu plugin faz algo não trivial — modelos de capability customizados, lógica complexa de WooCommerce, migrações de dados em sites de produção — e você quer um segundo par de olhos no código antes do deploy, esse é o tipo de trabalho que eu assumo como tech lead embarcado. Me encontre em me@phalkmin.me ou pelo formulário de contato.