O método PRP: um briefing de 300 palavras e 4 seções que tira o Claude do chute e o torna um construtor confiável. 20 minutos poupam 4 a 8 horas de retrabalho.
Um Product Requirement Prompt — um PRP — é um documento curto que você escreve antes de pedir ao Claude para construir uma funcionalidade. Quatro seções, cerca de trezentas palavras, vinte minutos para escrever — e ele transforma dois dias de depuração em uma a três horas de implementação limpa. É o hábito de maior alavancagem na construção assistida por IA, e quase ninguém que está começando usa.
"Claude, cria um fluxo de cadastro pra mim" parece progresso. Não é. Este post te dá o método, as quatro seções e um PRP real do meu próprio produto — palavra por palavra — para você copiar a estrutura hoje à noite.
O que é o método PRP?
A IA não substitui o pensamento. A IA substitui a digitação. Digitar nunca foi o gargalo — o desenho daquilo que você está digitando era. Quando você dá ao Claude uma instrução vaga, ele preenche cada lacuna com suposições: qual tabela do banco usar, como seu app está estruturado, o que significa "pronto". Algumas dessas suposições vão estar erradas, e você vai pagar por elas em horas de depuração que não pode gastar nas noites e fins de semana.
Um PRP fecha as lacunas antes de a construção começar. Não é opcional. A diferença entre "Claude, cria um fluxo de cadastro pra mim" e um PRP bem estruturado é a diferença entre dois dias depurando lixo e vinte minutos de implementação limpa.
As quatro seções de um PRP
Objetivo. O que você está construindo, em uma frase. "Construir um fluxo de cadastro que cria um usuário, cria uma empresa, vincula os dois e envia um e-mail de boas-vindas."
Contexto. Tudo o que o Claude precisa saber e não consegue deduzir: o schema do seu banco, seu provedor de autenticação, seu serviço de e-mail, seu framework de frontend, os padrões já existentes no seu código, links para a documentação relevante. Quanto mais contexto você dá, menos o Claude alucina, e mais perto de nível de produção fica o resultado.
Blueprint de implementação. Um roteiro passo a passo do que a funcionalidade deve fazer. Não código de verdade — isso é trabalho do Claude — mas estrutura suficiente para que o Claude não se perca. Isso te obriga a pensar a funcionalidade inteira antes de delegá-la, e dá ao Claude trilhos para construir.
Ciclo de validação. Como você vai saber que a funcionalidade funciona: os casos de teste que vai rodar, os casos extremos que precisam ser tratados. O Claude também pode escrever os testes — mas você precisa especificar o que testar antes que ele os escreva, ou ele vai testar as coisas erradas.
Um PRP real, palavra por palavra
Veja como ficou um para uma funcionalidade que construí no FIKR Space — uma página simples de preferências de notificação por e-mail:
Objetivo: Construir uma página de preferências de notificação em que usuários logados escolhem quais tipos de notificação por e-mail recebem: resumo semanal, novidades do produto, alertas de segurança. Salvar as preferências no registro do usuário. Padrão: tudo ligado.
Contexto:
- Stack: React, TypeScript, Supabase, Tailwind.
- A tabela
usersexistente tem as colunasid,created_at. É preciso adicionar uma coluna JSONnotification_preferencescom o formato{ digest: bool, updates: bool, security: bool }.- O contexto de autenticação já fornece o usuário atual pelo hook
useAuth()em/hooks/useAuth.ts.- A página fica em
/settings/notifications. O roteamento já está configurado.- Seguir o padrão da página de configurações existente em
/pages/settings/profile.tsxpara layout e estilo do formulário.Blueprint de implementação:
- Adicionar a coluna JSON
notification_preferencesà tabelausersvia migration do Supabase. Valor padrão: as três como true.- Criar o componente de página em
/pages/settings/notifications.tsx.- Ao montar, carregar as preferências do usuário atual do Supabase.
- Renderizar três chaves liga/desliga usando o componente
<Switch>existente.- Ao alternar uma chave, aplicar debounce de 500 ms e então salvar no Supabase.
- Mostrar um toast de sucesso ou de falha ao salvar.
- Tratar o estado de carregamento enquanto a busca inicial está em andamento.
Ciclo de validação:
- Fazer login. Ir para
/settings/notifications. As três chaves devem aparecer ligadas.- Desligar uma. Recarregar a página. A chave deve continuar desligada.
- Desconectar a rede. Alternar uma chave. Deve aparecer um toast de erro.
- Reconectar. Alternar de novo. Deve salvar e mostrar o toast de sucesso.
São cerca de trezentas palavras. O Claude gera a implementação em menos de dez minutos. Tempo total de "quero essa funcionalidade" até "está no ar em produção": uns noventa minutos, incluindo escrever o PRP, gerar o código, testar manualmente e fazer o deploy.
O que acontece sem um PRP
Compare com a mesma funcionalidade sem PRP. Você digita "cria uma página de preferências de notificação" no Claude. Ele produz alguma coisa. Essa alguma coisa não sabe qual tabela do banco usar, então inventa uma. Não conhece sua biblioteca de componentes, então gera componentes novos que destoam do resto do app. Não conhece suas convenções de salvamento, então salva a cada tecla digitada. Você passa duas horas reescrevendo a maior parte do que ele entregou para encaixar no seu código. A funcionalidade sai em meio dia em vez de uma hora e meia — e o código que sobra é cinquenta por cento seu e cinquenta por cento chute do Claude costurado junto.
| Com PRP | Sem PRP | |
|---|---|---|
| Escrever o briefing | 20 minutos | 0 minuto |
| Construir | 1–3 horas | as mesmas horas |
| Depuração e limpeza | mínima | até 2 dias, 4–8 horas de limpeza por funcionalidade |
| A funcionalidade do exemplo, de ponta a ponta | ~90 minutos | meio dia |
| Uma construção de 8 semanas | sai na semana 8 | sai na semana 20 |
Por que o PRP parece pesado — e por que você escreve mesmo assim
O método PRP parece pesado quando você está começando. Parece mais trabalho do que simplesmente digitar no Claude e torcer. Na primeira vez que você pular um e o Claude gerar mil e quinhentas linhas que você vai ter que jogar fora, vai entender. Vinte minutos de escrita te poupam de quatro a oito horas de limpeza por funcionalidade e, ao longo de uma construção inteira, isso se acumula até virar a diferença entre lançar em oito semanas e lançar em vinte.
Digitar no Claude e torcer tem nome e um final previsível — escrevi separadamente sobre a armadilha do vibe coding. Resumindo: velocidade sem estrutura parece progresso até o momento em que deixa de ser. O PRP é como você mantém a velocidade e evita o colapso.
E repare no que o PRP te obriga a fazer, sem alarde: pensar. Escrever o blueprint de implementação significa percorrer a funcionalidade passo a passo antes de existir qualquer código. Escrever o ciclo de validação significa decidir o que é "funcionar" antes de ver algo que parece funcionar. Esse pensamento é trabalho seu — é a parte que a IA não faz, e a parte que o framework BUILD treina de propósito.
Perguntas frequentes
O que é um Product Requirement Prompt (PRP)?
Um PRP é um documento curto que você escreve antes de pedir à IA para construir uma funcionalidade. Tem quatro seções — objetivo, contexto, blueprint de implementação e ciclo de validação — e sua função é eliminar as suposições que o Claude faria sobre o seu banco de dados, as suas convenções e o que significa "pronto".
Qual deve ser o tamanho de um PRP?
Cerca de trezentas palavras para uma funcionalidade média, o que leva uns vinte minutos para escrever. Com isso você tem uma funcionalidade funcionando em uma a três horas de construção, em vez das mesmas horas mais dois dias de depuração por cima.
Preciso ser técnico para escrever um PRP?
Não. O blueprint é linguagem simples, passo a passo, não código — "verificar se o e-mail já existe, criar o usuário, enviar o e-mail de boas-vindas". Você descreve o que deve acontecer e como vai verificar; o Claude cuida da implementação. Conhecer profundamente o seu produto importa muito mais do que conhecer sintaxe.
Quanto tempo o método PRP realmente economiza?
De quatro a oito horas de limpeza por funcionalidade. Numa construção de oito semanas com uma funcionalidade importante por semana, isso se acumula até você lançar em oito semanas em vez de vinte — mesmas ferramentas, mesma IA, disciplina diferente.