PACREF para Claude Code: As Seis Coisas que Todo Prompt Precisa
A maioria dos frameworks de prompts foi construída para chat. Você abre ChatGPT, escreve uma mensagem, recebe uma mensagem de volta. Toda a troca acontece em um contexto onde a IA não sabe nada sobre você, seu código ou no que está trabalhando.
Claude Code é outra coisa. O modelo pode ler seu repositório inteiro antes de você terminar de digitar. Pode executar comandos. Pode escrever arquivos. Pode quebrar coisas. O prompt não é apenas um pedido de resposta, é uma instrução entregue a um sistema que está prestes a agir.
Isso muda o que faz um bom prompt.
Tenho usado Claude Code em produção desde o início de 2025, e percebi que os prompts que funcionam não são os prompts que parecem impressionantes. Eles são chatos. Seguem a mesma estrutura de seis partes toda vez, porque cada parte está fazendo um trabalho real.
Um amigo meu que trabalha em marketing me apresentou a um framework chamado PACREF: Persona, Action, Context, References, Structure, Format. Foi construído para não-desenvolvedores usando Cowork para redigir e-mails e relatórios. Roubei, mantive a estrutura básica, e reorganizei as prioridades para Claude Code. O resultado está abaixo, com exemplos dos fluxos de WordPress que realmente executo toda semana.
P — Persona
Para prompts de chat, persona é tudo. "Você é um copywriter sênior com vinte anos de experiência" direciona tom, vocabulário e nível de confiança.
Para Claude Code, persona é quase inútil. O modelo está editando arquivos, não escrevendo prosa. Dizer a ele que "aja como um desenvolvedor PHP sênior" não muda muito porque o código ou compila ou não. No final do dia, é um processo binário.
Quando uso persona, é de forma estreita e específica:
"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."
Vê? Não é uma persona, mas uma regra explícita. Funciona porque diz ao modelo qual de seus muitos estilos internalizados usar por padrão. Sem essa linha, você fica com PHP genérico que vai falhar na revisão de plugin do WordPress por coisas como nomes de função com prefixo ou convenções de sanitização.
A lição: se a persona não muda o que é escrito, é decoração. Corte-a.
A — Action
É aqui que a maioria das pessoas falha. Eles escrevem a ação como uma lista de desejos.
"Corrija o bug no checkout."
Bom para um colega de equipe que sabe qual bug. Inútil para Claude Code, que vai ler todo WooCommerce, tentando descobrir o que você quer, e então helpfully refatorar coisas que você não pediu para modificar.
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. Restrição específica no raio de impacto. Os verbos de ação importam: "descubra por que" antes de "proponha uma correção" te dá um diagnóstico que você pode revisar antes de qualquer mudança de código. "Não modifique nenhum outro arquivo" previne o espalhamento helpful.
Uma boa action diz o que fazer, onde fazer, e quando parar.
C — Context
Em chat, contexto é o que você colar. Em Claude Code, contexto é principalmente já está lá. O modelo pode ler o projeto. Pode executar grep. Pode puxar histórico de commits.
O que você adiciona manualmente é 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 sobre como o modelo se comporta. Sem ele, Claude Code tentará "melhorar" o código normalizando padrões. Com ele, o modelo sabe que a inconsistência é uma feature, não um bug.
O contexto que mais importa é o tipo que você não pode ler dos arquivos: prioridades do cliente, decisões históricas, coisas que parecem erradas mas existem por uma razão.
R — References
Esta é a dimensão que se afasta mais do PACREF baseado em chat.
Em chat, referências são geralmente um ou dois exemplos colados no prompt. Em Claude Code, referências são arquivos, diretórios, URLs ou commits específicos do git. Você aponta para eles por 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."
Este é o prompt que transforma saída de IA genérica em saída que se encaixa na sua base de código. Sem uma referência, Claude Code gera código plausível que você vai precisar adaptar às suas convenções durante o processo de revisão. Com um bom arquivo de referência, a saída encaixa limpa.
O erro que vejo mais frequentemente é referenciar muitos arquivos. Escolha um ou dois exemplos canônicos. O modelo vai fazer pattern-match melhor a partir de uma referência focada do que de "use o resto da base de código como guia."
S — Structure
Structure é como a resposta é organizada. Para um pedaço de escrita, são títulos e parágrafos. Para uma tarefa de 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 pausa. Gates de aprovação. Esta é a diferença entre deixar Claude Code solto e usá-lo como um colaborador estruturado. A estrutura é um contrato. Sem isso, o modelo vai colapsar as três fases em uma resposta heróica, e você vai passar a tarde desemaranhar o que mudou.
Se o prompt não diz onde e como parar, o modelo não vai parar. Disciplina vive na estrutura.
F — Format
Para chat, format é "bullet points" ou "table" ou "JSON." Para Claude Code, format é mais próximo de "que artefato eu quero no final."
Um diff. Um novo arquivo em um caminho específico. Um relatório markdown. Um config atualizado. Uma suite de testes modificada. O tipo de saída diz ao modelo qual forma seu trabalho precisa tomar.
"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."
Esse é um formato bastante especificado. Toda restrição existe porque algo deu errado antes. Conventional commits porque reviso títulos de PR em massa e preciso que sejam parseáveis. Commit único porque misturar fix e refactor em um commit torna impossível bisect depois. Teste de regressão porque é assim que você sabe que a correção realmente corrige o bug.
Format é onde os instintos do desenvolvedor sênior vão. Devs juniores perguntam "devo escrever um teste?" Devs sênior assumem que o teste existe porque nada é enviado sem um. O prompt tem que codificar os mesmos defaults.
Um prompt PACREF completo
Aqui está como todas as seis partes se parecem juntas para uma tarefa real que executei 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 é usado em produção por ~3.000
sites 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. Lê-lo leva trinta segundos. Economiza uma hora de limpeza comparado à versão onde eu apenas teria digitado "corrija o shortcode de posts recentes."
O ponto não é o acrônimo
PACREF não é mágica. Nenhum desses frameworks disponíveis online é. O ponto é que força você a articular o que realmente quer antes do modelo começar a trabalhar. O acrônimo é scaffolding para você não esquecer uma dimensão.
As dimensões que mais importam para Claude Code, em ordem de impacto: References, Structure, Action. Essas três carregam aproximadamente 80% da diferença de qualidade entre um prompt que funciona e um que não funciona. Persona e Format são úteis nos marginais. Context preenche as lacunas que o modelo não consegue ler do código.
Se seus prompts parecem hit-or-miss, tente escrever o próximo com todos os seis rótulos no prompt real, nesta ordem. Uma vez que é um hábito, você pode largar os rótulos, e a estrutura permanece. Esse é o objetivo. Ou, talvez, crie uma skill que faça o trabalho pesado para você.
Se você está construindo fluxos de IA para sua equipe e quer ajuda para passar do estágio demo-and-pray, é isso que faço para viver. Envie uma mensagem.