O método PRP: o briefing para o Claude construir a coisa certa

Um Product Requirement Prompt — um PRP — é um documento curto que escreves antes de pedires ao Claude que construa uma funcionalidade. Quatro secções, cerca de trezentas palavras, vinte minutos a escrever — e transforma dois dias de depuração em uma a três horas de implementação limpa. É o hábito com mais alavancagem na construção assistida por IA, e quase ninguém que está a começar o usa.

"Claude, constrói-me um fluxo de registo" parece progresso. Não é. Este artigo dá-te o método, as quatro secções e um PRP real do meu próprio produto — palavra a palavra — para poderes copiar a estrutura ainda esta noite.

O que é o método PRP?

A IA não substitui o pensamento. A IA substitui a escrita à máquina. Escrever nunca foi o gargalo — o desenho daquilo que estás a escrever é que era. Quando dás ao Claude uma instrução vaga, ele preenche todas as lacunas com suposições: que tabela da base de dados usar, como está estruturada a tua aplicação, o que significa "feito". Algumas dessas suposições vão estar erradas, e vais pagá-las em horas de depuração que não podes gastar à noite e aos fins de semana.

Um PRP fecha as lacunas antes de a construção começar. Não é opcional. A diferença entre "Claude, constrói-me um fluxo de registo" e um PRP bem estruturado é a diferença entre dois dias a depurar lixo e vinte minutos de implementação limpa.

As quatro secções de um PRP

Objetivo. O que estás a construir, numa frase. "Constrói um fluxo de registo que cria um utilizador, cria uma empresa, liga-os e envia um email de boas-vindas."

Contexto. Tudo o que o Claude precisa de saber e não consegue deduzir: o esquema da tua base de dados, o teu fornecedor de autenticação, o teu serviço de email, a tua framework de frontend, os padrões que já existem no teu código, links para a documentação relevante. Quanto mais contexto dás, menos o Claude alucina e mais perto o resultado fica do nível de produção.

Plano de implementação. Um esboço passo a passo do que a funcionalidade deve fazer. Não código propriamente dito — isso é trabalho do Claude —, mas estrutura suficiente para o Claude não se perder. Obriga-te a pensar a funcionalidade antes de a delegares e dá ao Claude carris sobre os quais construir.

Ciclo de validação. Como vais saber que a funcionalidade funciona: os casos de teste que vais correr, os casos-limite que têm de ser tratados. O Claude também pode escrever os testes — mas tens de especificar o que testar antes de ele os escrever, senão vai testar as coisas erradas.

Um PRP real, palavra a palavra

Eis como era um PRP para uma funcionalidade que construí no FIKR Space — uma página simples de preferências de notificações por email:

Objetivo: Construir uma página de preferências de notificações em que os utilizadores com sessão iniciada escolhem que tipos de notificações por email recebem: resumo semanal, novidades do produto, alertas de segurança. Guardar as preferências no registo do utilizador. Por defeito, tudo ativo.

Contexto:

• Stack: React, TypeScript, Supabase, Tailwind.
• A tabela users existente tem as colunas id, email, created_at. É preciso acrescentar uma coluna JSON notification_preferences com o formato { digest: bool, updates: bool, security: bool }.
• O contexto de autenticação já fornece o utilizador atual através do hook useAuth() em /hooks/useAuth.ts.
• A página fica em /settings/notifications. As rotas já estão configuradas.
• Seguir o padrão da página de definições existente em /pages/settings/profile.tsx para o layout e o estilo do formulário.

Plano de implementação:

1. Acrescentar a coluna JSON notification_preferences à tabela users através de uma migração do Supabase. Valor por defeito: as três a true.
2. Criar o componente da página em /pages/settings/notifications.tsx.
3. Ao montar, carregar do Supabase as preferências do utilizador atual.
4. Mostrar três interruptores usando o componente <Switch> existente.
5. Quando um interruptor muda, esperar 500 ms (debounce) e depois guardar no Supabase.
6. Mostrar uma notificação toast em caso de sucesso ou falha ao guardar.
7. Tratar o estado de carregamento enquanto o pedido inicial está em curso.

Ciclo de validação:

• Iniciar sessão. Ir a /settings/notifications. Os três interruptores devem aparecer ativos.
• Desativar um. Recarregar a página. O interruptor deve continuar desativado.
• Desligar a rede. Mudar um interruptor. Deve aparecer um toast de erro.
• Voltar a ligar. Mudar outra vez. Deve guardar e mostrar um toast de sucesso.

São cerca de trezentas palavras. O Claude gera a implementação em menos de dez minutos. Tempo total de "quero esta funcionalidade" a "está no ar em produção": talvez noventa minutos, incluindo escrever o PRP, gerar o código, testar à mão e fazer o deploy.

O que acontece sem um PRP

Compara isso com a mesma funcionalidade sem PRP. Escreves "constrói-me uma página de preferências de notificações" no Claude. Ele produz alguma coisa. Essa coisa não sabe que tabela da base de dados usar, por isso inventa uma. Não conhece a tua biblioteca de componentes, por isso gera componentes novos com um aspeto diferente do resto da aplicação. Não conhece as tuas convenções para guardar, por isso guarda a cada tecla. Passas duas horas a reescrever a maior parte do que te deu para bater certo com o teu código. A funcionalidade sai em meio dia em vez de hora e meia — e o código com que ficas é cinquenta por cento teu e cinquenta por cento palpites do Claude cosidos uns aos outros.

	Com um PRP	Sem um PRP
Escrever o briefing	20 minutos	0 minutos
Construir	1–3 horas	as mesmas horas
Depuração e limpeza	mínimas	até 2 dias, 4–8 horas de limpeza por funcionalidade
A funcionalidade do exemplo, do início ao fim	~90 minutos	meio dia
Uma construção de 8 semanas	sai na semana 8	sai na semana 20

Porque é que o PRP parece pesado — e porque o escreves na mesma

O método PRP parece pesado quando estás a começar. Parece mais trabalho do que simplesmente escrever no Claude e esperar pelo melhor. Da primeira vez que saltares um e o Claude gerar mil e quinhentas linhas que tens de deitar fora, vais perceber. Vinte minutos de escrita poupam-te quatro a oito horas de limpeza por funcionalidade e, ao longo de uma construção completa, isso acumula-se na diferença entre lançar em oito semanas e lançar em vinte.

Escrever no Claude e esperar pelo melhor tem nome e um fim previsível — escrevi à parte sobre a armadilha do vibe coding. A versão curta: velocidade sem estrutura parece progresso até ao momento em que deixa de parecer. O PRP é a forma de manteres a velocidade e evitares o colapso.

E repara no que o PRP te obriga a fazer, discretamente: pensar. Escrever o plano 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 quer dizer "funcionar" antes de veres algo que parece funcionar. Esse pensamento é o teu trabalho — é a parte que a IA não consegue fazer, 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 escreves antes de pedires à IA que construa uma funcionalidade. Tem quatro secções — objetivo, contexto, plano de implementação e ciclo de validação — e serve para eliminar as suposições que o Claude faria de outra forma sobre a tua base de dados, as tuas convenções e o que significa "feito".

Que extensão deve ter um PRP?

Cerca de trezentas palavras para uma funcionalidade média, o que leva uns vinte minutos a escrever. Isso dá-te uma funcionalidade a funcionar em uma a três horas de construção, em vez das mesmas horas mais dois dias de depuração por cima.

Preciso de ser técnico para escrever um PRP?

Não. O plano é linguagem simples, passo a passo, não código — "verifica se o email já existe, cria o utilizador, envia o email de boas-vindas." Descreves o que deve acontecer e como o vais verificar; o Claude trata da implementação. Conhecer a fundo o teu produto importa muito mais do que conhecer sintaxe.

Quanto tempo poupa de facto o método PRP?

Quatro a oito horas de limpeza por funcionalidade. Numa construção de oito semanas com uma funcionalidade grande por semana, isso acumula-se em lançar em oito semanas em vez de vinte — as mesmas ferramentas, a mesma IA, uma disciplina diferente.