Prd

PRD — Documento de Produto

Visão geral

O PRD (Product Requirements Document) responde o quê e por quê na linguagem do produto; a spec técnica responde como na linguagem da engenharia. São documentos irmãos com leitores diferentes. Esta skill existe porque o portão de aprovação só funciona se o humano conseguir julgar o que está aprovando — e quem não é engenheiro julga o PRD, não a pilha técnica. A spec (skill especificar) deriva do PRD aprovado: se as duas se contradizem, é a spec que está errada.

Quando usar

• Depois da entrevistar, quando o trabalho é um produto ou funcionalidade nova de porte
• Quando o usuário é leigo em programação e vai aprovar o Portão 1
• Quando existirem outras pessoas (cliente, sócio, equipe) que precisam entender o projeto sem ler documento técnico

Quando NÃO usar: correções de bugs, ajustes pequenos e tarefas de uma sessão — vá direto para especificar. PRD para consertar um botão é burocracia, não processo.

O fluxo

1. Colher da entrevista

Todo o conteúdo do PRD deve vir do que a entrevista revelou. Não invente requisitos: lacuna descoberta aqui volta como pergunta, não vira suposição silenciosa.

2. Escrever — uma página, seções fixas

Salve em docs/prd.md. Limite duro: ~1 página. PRD longo ninguém lê, e o valor dele está em ser curto e julgável. Linguagem leiga do início ao fim — zero jargão.

# PRD: [Nome do produto/funcionalidade]

## O problema
[2-3 frases: qual dor existe hoje e para quem. Sem mencionar solução.]

## Para quem
[O usuário principal, descrito como gente: "professor que projeta slides em sala",
não "stakeholder educacional".]

## O que vamos construir
[3-6 frases descrevendo a solução do ponto de vista de quem usa — o que a pessoa
vê e faz, não como funciona por dentro.]

## O que fica DE FORA (por enquanto)
[Lista explícita. Escopo cortado agora é retrabalho evitado depois.]

## Como saberemos que deu certo
[2-4 critérios que o usuário final consegue verificar sozinho:
"abre com clique duplo, sem instalar nada", "legível do fundo da sala".]

## Premissas e riscos
[O que estamos assumindo como verdade e o que pode dar errado — em uma linha cada.]

3. Regras de qualidade

• Problema antes de solução — se a seção "O problema" menciona tecnologia, reescreva.
• "De fora" é obrigatório — PRD sem escopo cortado é lista de desejos.
• Critérios verificáveis por leigo — "rápido" não serve; "abre em menos de 3 segundos" serve.
• Zero decisão técnica — pilha, banco, arquitetura pertencem à spec. Se o usuário impôs uma tecnologia ("tem que ser no Excel"), registre em Premissas.

4. Entregar para a spec

Após a aprovação no portão, a skill especificar lê docs/prd.md como entrada e escreve a spec técnica como derivação. Cada requisito da spec deve ser rastreável a uma seção do PRD.

Sinais de alerta

• PRD com mais de uma página (está virando spec ou enrolação)
• Seções técnicas ("usaremos React") dentro do PRD
• "O que fica de fora" vazio
• PRD escrito sem entrevista antes — é ficção, não requisito
• Requisito na spec que não existe no PRD (escopo entrou escondido)

Portão de aprovação

Apresente: o PRD completo (cabe na tela — é uma página) e, se a spec já existir, a frase "a especificação técnica deriva deste documento e será apresentada como anexo". O humano aprova: o problema, o público, o escopo (dentro E fora) e os critérios de sucesso. Só avance após aprovação explícita — este é o coração do Portão 1.

Verificação

• docs/prd.md tem no máximo ~1 página com todas as seções
• Nenhuma decisão técnica no corpo (exceções registradas em Premissas)
• Todos os critérios de sucesso são verificáveis por um leigo
• "O que fica de fora" tem ao menos um item real
• Todo o conteúdo é rastreável à entrevista