Um modelo de PRD em Markdown:copie-o e preencha-o.

O modelo

Copie isto para um novo ficheiro e substitua tudo o que está entre parênteses angulares. Elimine uma secção só se tiver a certeza de que não se aplica, e escreva "nenhum" em vez de a deixar vazia, para que o leitor perceba que foi considerada.

# PRD: <Feature name>

Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>

## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.

## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>

## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>

## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.

## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.

## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.

## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>

## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>

## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.

## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>

## 11. Open questions
- [ ] <Question> (owner: <name>)

## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.

Porque é que está escrito assim

Um PRD para um agente de IA tem a mesma função que um para uma pessoa, com menos margem para adivinhar. Uma pessoa pergunta-lhe no corredor o que queria dizer. Um agente preenche a lacuna com o melhor palpite e segue em frente.

• Os não-objetivos são a proteção mais barata contra o alargamento do âmbito. Os agentes juntam extras "úteis" a não ser que lhes diga para não o fazerem.
• Os requisitos numerados (R1, R2) permitem que um plano, um teste e um comentário de revisão apontem para a mesma coisa.
• Os critérios de aceitação como caixas de uma lista de tarefas tornam-se uma lista de tarefas que se pode ir marcando. Veja as listas de tarefas em Markdown para a sintaxe.
• Os casos-limite são onde o código gerado falha primeiro: dados vazios, entrada inválida, ligação perdida.
• A reversão obriga-o a pensar em como desfazer a alteração antes de a publicar.

Como o preencher

1. Escreva o problema sem a solução

   Se não consegue descrever o problema sem nomear uma funcionalidade, a funcionalidade é um palpite. Diga quem é afetado e o que acontece hoje.

2. Torne cada objetivo mensurável

   "Pagamento mais rápido" é um desejo. "Pagamento com mediana abaixo de 30 segundos" é um objetivo.

3. Escreva os requisitos como comportamento

   "O sistema deve mostrar um erro quando o ficheiro for maior do que 10 MB" pode ser testado. "Boa gestão de erros" não.

4. Associe um critério a cada requisito

   Use o formato dado, quando, então (Given, when, then). Se não consegue escrever a verificação, o requisito é vago.

5. Termine com as questões em aberto

   Indique o responsável por cada uma. Um agente deve perguntar por elas, e não decidi-las.

Os diagramas ajudam em fluxos e estados; um bloco Mermaid no ficheiro é fácil de alterar. Veja a sintaxe dos fluxogramas Mermaid.

Entregar o PRD a um agente de IA

Indique o ficheiro ao agente em vez de o colar: "Lê docs/prd/export.md e propõe um plano; ainda não escrevas código." Peça primeiro um plano, confirme-o com os requisitos numerados e só depois deixe-o construir. Um PRD, um plano e uma lista de tarefas são normalmente três ficheiros separados. O PRD diz o quê e porquê, o plano diz como, e as tarefas são os passos.

Mantenha as regras de todo o projeto (comandos, estilo, pastas) fora do PRD e no CLAUDE.md ou AGENTS.md, para que o PRD contenha apenas o que é específico desta funcionalidade.

Erros comuns

• Uma solução disfarçada de problema. "Precisamos de uma lista suspensa" não é um problema.
• Sem não-objetivos. Tudo o que está por perto passa a fazer parte do âmbito.
• Requisitos que não podem falhar. Se nenhum teste alguma vez o pudesse reprovar, não diz nada.
• Um PRD que ninguém volta a ler. Atualize o estado e as questões em aberto ao longo do caminho.
• Dez páginas para uma alteração pequena. Uma funcionalidade de um dia precisa de meia página.

Os gestores de produto podem ler e rever PRDs no DotMD como documentos formatados, com comentários na passagem exata. A leitura é gratuita; veja os preços para edição e revisões.

Perguntas sobre modelos de PRD em Markdown

Mais perguntas