Cada prompt do catálogo foi escrito para um caso concreto — mas publicado com variáveis que você deve substituir. O problema de quem só copia é que a adaptação "no olho" costuma errar no mesmo lugar: muda o conteúdo, esquece as restrições, e a resposta volta genérica. O framework P.C.R.F. existe para tornar essa adaptação mecânica.
P.C.R.F. = Papel, Contexto, Restrições, Formato. Todo prompt bom tem as quatro camadas; adaptar é revisar cada uma com o seu caso.
P — Papel: quem a IA deve ser
O papel define a lente de atenção do modelo. "Revisor sênior focado em segurança" e "assistente genérico" olham coisas diferentes no mesmo código. Para adaptar:
- Pergunte: qual especialista faria este trabalho melhor que um generalista?
- Especifique a especialidade com um adjetivo de foco ("focado em", "especializado em") — é o que concentra a atenção.
- Se o prompt original não tem papel explícito, adicione uma linha no topo. É a modificação de maior impacto por menor esforço.
C — Contexto: o mundo do seu problema
Contexto é tudo que o modelo precisa saber sobre a situação para não ter que chutar: stack e versões, público-alvo, estágio do projeto, material de referência. Regras práticas:
- Versões sempre. "Fastify" vira "Fastify 5 + Node 22". Versão é contexto — sem ela, o modelo mistura gerações de API (é a principal causa de código que não compila).
- Público com comportamento, não cargo. "Dev sênior com 15 minutos" informa mais que "profissionais de tecnologia".
- Material colado tem rótulo. Se você cola um documento, diga o que ele é e qual a relação com o pedido: "abaixo está o texto original; sua tarefa é...". Sem rótulo, o modelo não sabe se o material é referência, input ou exemplo de estilo.
R — Restrições: o que NÃO fazer
A camada mais negligenciada e a que mais diferencia resposta boa de resposta mediana. Restrição acionável é verificável depois; restrição vaga ("seja objetivo") não é. Padrões que pagam em qualquer categoria:
- Tetos numéricos: "máximo 300 palavras", "no máximo 5 itens", "cada item em 1 frase".
- Listas de proibição concretas: "sem jargão corporativo, sem perguntas retóricas, sem emoji". Proibir o vício específico é mais eficaz que pedir a virtude genérica.
- Anti-invenção (para código e dados): "se não tiver certeza de uma API/fato, marque // VERIFICAR em vez de inventar". Transforma erro silencioso em sinal visível.
- O que não pode mudar: em refatoração ou edição, liste explicitamente o que permanece intacto ("mantenha as assinaturas públicas", "preserve a ordem das seções").
F — Formato: como a saída deve chegar
Formato é o contrato de entrega. Sem ele, você recebe prosa; com ele, recebe ferramenta. Os formatos que mais pagam:
- Tabela para comparações e decisões (colunas = critérios).
- CSV/JSON quando a saída vai para outro sistema (flashcards, planilhas, APIs).
- Dif unificado + justificativa por hunk para refatoração.
- Estrutura nomeada ("decisões com dono e prazo; pendências; próximos passos") para documentos recorrentes — o formato vira template que você reaproveita.
O exercício de 10 minutos (passo a passo)
Pegue qualquer prompt do catálogo e faça este roteiro:
- Marque as camadas no texto original: onde está o papel? O contexto? As restrições? O formato? (Muitos prompts têm P e F implícitos — torná-los explícitos já é metade do trabalho.)
- Troque os parâmetros de contexto: stack, versão, público, material. É aqui que 80% da adaptação acontece.
- Ajuste o papel se a especialidade original não for a sua (ex.: "revisor de segurança" → "revisor de performance").
- Adicione 1–2 restrições do seu domínio: o vício que você mais vê nas respostas desse tipo de tarefa. Se a IA sempre exagera em listas, proíba listas.
- Confira o formato contra o destino da saída: vai para e-mail? Prosa. Vai para planilha? CSV. Vai para código? Arquivo completo com instruções de rodar.
Exemplo completo
Prompt original do catálogo: Gerador de Posts Virais Técnicos para LinkedIn e Twitter/X. Adaptação P.C.R.F. para um caso concreto:
- Papel (mantido): "redator técnico que escreve posts que viralizam no LinkedIn".
- Contexto (trocado): em vez de "tema genérico", entra "meu produto: API de pagamentos para fintechs brasileiras; público: CTOs e heads de engenharia de fintech com 50–200 devs".
- Restrições (adicionadas): "sem mencionar concorrentes por nome; sem promessa de número ('aumente em X%'); máximo 1300 caracteres no LinkedIn".
- Formato (mantido + estendido): "3 variações de gancho + corpo único; ao final, 5 hashtags do nicho fintech BR".
O resultado é um prompt que o autor original nunca escreveu — mas que herda toda a estrutura testada dele. Isso é adaptação: você não recria o prompt, você o especializa.
Quando adaptar não basta
Duas situações pedem mais do que P.C.R.F.:
- A tarefa tem etapas com dependência (ex.: pesquisar → rascunhar → revisar): aí o problema é de decomposição, não de parâmetro — veja nosso guia de prompt chains.
- O prompt original tem erro estrutural (restrição contraditória, formato incompatível com o papel): nesse caso, use o checklist do nosso guia de como avaliar a qualidade de um prompt para decidir se vale corrigir ou trocar.
Prompts bons para praticar a adaptação
- Boilerplate Fastify + Prisma + TypeScript — troque a stack e os endpoints; a estrutura de camadas permanece.
- Code Reviewer Sênior — troque o foco (segurança → performance → legibilidade) e observe como muda a saída.
- Sequência de 5 E-mails de Onboarding — troque o produto e os objetivos por e-mail; a progressão se mantém.
Perguntas frequentes
Como adaptar um prompt pronto ao meu negócio?
Substitua as variáveis e reescreva as restrições com os limites reais do seu caso: ferramentas que você usa, o que não pode mudar e o formato exato da saída.
O que são variáveis em um prompt?
Marcadores como {{nome_do_projeto}} que o Prompt Salvo transforma em campos preenchíveis. Elas separam a estrutura reutilizável do dado específico de cada uso.
Quando adaptar não resolve?
Quando a tarefa é grande demais para uma etapa só. Nesse caso, decomponha em prompt chains em vez de tentar resolver tudo em um único prompt.