A maioria dos frameworks de prompt foi feita pra chat. Você abre o ChatGPT, escreve uma mensagem, recebe uma mensagem de volta. A troca inteira acontece num contexto em que a IA não sabe nada sobre você, sobre o seu código ou sobre o que você está fazendo.
O Claude Code é outra coisa. O modelo consegue ler o seu repositório inteiro antes de você terminar de digitar. Consegue rodar comandos. Consegue gravar arquivos. Consegue quebrar coisas. O prompt deixa de ser um pedido de resposta e vira uma instrução entregue a um sistema que está prestes a agir.
Isso muda o que faz um prompt ser bom.
Eu uso o Claude Code em produção desde o começo de 2025, e percebi que os prompts que funcionam não são os que parecem impressionantes. São chatos. Seguem sempre a mesma estrutura de seis partes, porque cada parte tem um trabalho de verdade.
Uma pessoa conhecida que trabalha com marketing me apresentou um framework chamado PACREF: Persona, Action, Context, References, Structure, Format. Ele foi criado pra quem não programa e usa o Cowork pra redigir e-mails e relatórios. Eu roubei, mantive a estrutura básica e reorganizei as prioridades pro Claude Code. O resultado está abaixo, com exemplos dos fluxos de WordPress que eu rodo toda semana.
P: Persona
Em prompt de chat, a persona é tudo. "Você é um redator sênior com vinte anos de experiência" direciona tom, vocabulário e nível de confiança.
No Claude Code, a persona é quase inútil. O modelo está editando arquivo, não escrevendo texto. Mandar ele "agir como um desenvolvedor PHP sênior" não muda muita coisa, porque o código compila ou não compila. No fim do dia, é binário.
Quando eu uso persona, é de um jeito estreito e específico:
"Trate este código como um plugin WordPress.org que tem que passar na verificação oficial de plugins. Aplique os Padrões de Código WordPress estritamente."
Percebeu? Isso não é uma persona, é uma regra explícita. Funciona porque diz ao modelo qual dos muitos estilos que ele aprendeu usar como padrão. Sem essa linha, você recebe um PHP genérico que vai reprovar na revisão de plugins do WordPress por coisas como prefixo em nome de função ou convenção de sanitização.
A lição: se a persona não muda o que é escrito, é enfeite. Corte.
A: Action
É aqui que a maioria erra. A pessoa escreve a ação como uma lista de desejos.
"Corrija o bug no checkout."
Serve pra um colega de time que sabe de qual bug você está falando. Pro Claude Code, é inútil: ele vai ler o WooCommerce inteiro tentando entender o que você quer e depois, todo prestativo, refatorar coisas que você não pediu pra mexer.
Melhor:
"No arquivo includes/class-checkout-validator.php, o método validate_billing_address retorna true mesmo quando o CEP está vazio. Descubra por que e proponha uma correção. Não modifique nenhum outro arquivo a menos que seja necessário."
Escopo específico. Comportamento específico a procurar. Limite específico pro estrago. Os verbos importam: "descubra por que" antes de "proponha uma correção" te dá um diagnóstico que você revisa antes de qualquer mudança no código. "Não modifique nenhum outro arquivo" evita que a prestatividade se espalhe.
Uma boa action diz o que fazer, onde fazer e quando parar.
C: Context
No chat, o contexto é o que você cola. No Claude Code, o contexto em grande parte já está lá. O modelo lê o projeto. Roda grep. Puxa o histórico de commits.
O que você acrescenta na mão é o contexto que não está no código. O porquê.
"Este plugin tem uma base de código de 7 anos com dois contribuidores sênior que não estão mais ativos. O estilo é inconsistente entre arquivos. Precisamos introduzir novas funcionalidades sem quebrar os padrões existentes que os usuários atuais dependem. A compatibilidade com versões anteriores é mais importante do que a consistência interna."
Esse parágrafo muda tudo no comportamento do modelo. Sem ele, o Claude Code vai tentar "melhorar" o código padronizando tudo. Com ele, o modelo sabe que a inconsistência é uma característica do projeto, e não um defeito.
O contexto que mais pesa é o que não dá pra tirar dos arquivos: as prioridades do cliente, as decisões do passado, as coisas que parecem erradas mas existem por um motivo.
R: References
Esta é a dimensão que mais se afasta do PACREF pensado pra chat.
No chat, referência costuma ser um ou dois exemplos colados no prompt. No Claude Code, referência é arquivo, pasta, URL ou commit específico do git. Você aponta pelo caminho.
"Use a estrutura de plugins/wp-myplugin/includes/class-api-handler.php como referência para como integrações de API devem ser organizadas nesta base de código. Combine o estilo de docblock e o padrão de tratamento de exceção."
É esse o prompt que transforma resultado genérico de IA em resultado que encaixa no seu código. Sem referência, o Claude Code gera um código plausível que você vai ter que adaptar às suas convenções na revisão. Com um bom arquivo de referência, sai encaixado.
O erro que eu mais vejo é referenciar arquivo demais. Escolha um ou dois exemplos oficiais. O modelo reconhece o padrão muito melhor a partir de uma referência focada do que de um "use o resto do código como guia".
S: Structure
Structure é como a resposta se organiza. Num texto, são títulos e parágrafos. Numa tarefa do Claude Code, é a ordem das operações.
"Aborde isto em três fases. Primeira, auditoria. Leia todos os arquivos correspondentes ao padrão admin/views/*.php e reporte quais deles têm entrada de usuário não sanitizada. Pare após a auditoria. Aguarde minha confirmação antes de qualquer correção. Segunda, proponha correções para cada descoberta, um arquivo por vez, mostrando-me o diff antes de aplicar. Terceira, aplique apenas as correções que eu aprovar."
Três fases explícitas. Pontos de parada. Etapas de aprovação. É a diferença entre soltar o Claude Code e usar ele como um colaborador com método. A estrutura é um contrato. Sem ela, o modelo junta as três fases numa resposta heroica só, e você passa a tarde desembaraçando o que mudou.
Se o prompt não diz onde e como parar, o modelo não para. A disciplina mora na estrutura.
F: Format
No chat, format é "tópicos", "tabela" ou "JSON". No Claude Code, format está mais perto de "que artefato eu quero no fim".
Um diff. Um arquivo novo num caminho específico. Um relatório em markdown. Uma configuração atualizada. Uma suíte de testes modificada. O tipo de saída diz ao modelo que forma o trabalho dele precisa ter.
"Saída: um único commit do git com uma mensagem clara de commit no formato conventional commit, nenhuma outra mudança. O commit deve conter apenas a correção do bug e um teste de regressão que falha no código antigo e passa no novo."
É um formato bem detalhado. Cada restrição existe porque algo já deu errado antes. Conventional commits porque eu reviso títulos de PR em lote e preciso que dê pra processar. Commit único porque misturar correção e refatoração no mesmo commit impossibilita o bisect depois. Teste de regressão porque é assim que você sabe que a correção corrige mesmo o bug.
É no format que entram os instintos do dev sênior. O dev júnior pergunta "devo escrever um teste?". O dev sênior parte do princípio de que o teste existe, porque nada vai pro ar sem um. O prompt precisa registrar esses mesmos padrões.
Um prompt PACREF completo
É assim que as seis partes ficam juntas numa tarefa real que eu rodei no mês passado:
[Persona]
Aplique os Padrões de Código WordPress. Este plugin deve passar na Verificação
de Plugin para o repositório WordPress.org.
[Action]
O shortcode [wpai_recent_posts] ocasionalmente retorna sem saída
quando chamado de um contexto de widget. Descubra por que. Proponha uma correção.
Não modifique os arquivos de template públicos.
[Context]
Este shortcode funcionava corretamente até WordPress 6.5. O bug apareceu
após um cliente atualizar. O plugin tem mais de 6.000 downloads
e mudanças que quebrem compatibilidade não são aceitáveis.
[References]
Use o padrão de tratamento de erros de includes/shortcodes/class-author-list.php
como referência. Logging deve combinar com o que está em includes/class-logger.php.
[Structure]
Primeiro, diagnostique. Mostre-me a causa raiz com referências de arquivo/linha
antes de qualquer mudança de código. Segundo, proponha a correção como um diff.
Terceiro, escreva um teste unitário que reproduz o bug.
[Format]
A saída final deve ser: um diagnóstico markdown, um único diff aplicado
a um arquivo, e um novo arquivo de teste sob tests/shortcodes/.
Esse prompt tem 180 palavras. Ler leva trinta segundos. E economiza uma hora de limpeza em comparação com a versão em que eu só teria digitado "corrija o shortcode de posts recentes".
O acrônimo é o de menos
O PACREF não tem mágica. Nenhum desses frameworks que circulam por aí tem. O ponto é que ele te obriga a dizer com clareza o que você quer antes de o modelo começar a trabalhar. O acrônimo é um andaime pra você não esquecer nenhuma dimensão.
As dimensões que mais pesam no Claude Code, em ordem de impacto: References, Structure e Action. Essas três respondem por uns 80% da diferença de qualidade entre um prompt que funciona e um que não funciona. Persona e Format ajudam nas margens. Context preenche o que o modelo não consegue ler no código.
Se os seus prompts parecem loteria, tente escrever o próximo com os seis rótulos no próprio prompt, nessa ordem. Quando virar hábito, você larga os rótulos e a estrutura fica. É esse o objetivo. Ou então crie uma skill que faça o trabalho pesado por você.
Um framework só ajuda um time se todo mundo usa o mesmo. Quando cinco devs escrevem prompt cada um do seu jeito, o code review vira um chute sobre qual instrução gerou qual diff. A solução é sem graça: combinar uma estrutura só, transformar os prompts que se repetem em skills compartilhadas e ler o prompt junto com o diff quando algo quebra. Definir esse padrão num time faz parte do meu trabalho como CTO fracionado. Se o seu time está nesse ponto, me conta como ele escreve prompts hoje.