Šablona PRD v Markdownu:zkopírujte ji a vyplňte.
Dokument s požadavky na produkt se nejsnáz udržuje v souboru .md vedle kódu. Tahle šablona je krátká, má číslované požadavky a ověřitelná kritéria přijetí a je napsaná tak, aby podle ní mohl stavět AI agent.
macOS 14 nebo novější. Čtení je zdarma; úpravy a revize se platí jednou.
Rychlá odpověď
Dobré PRD uvádí problém, cíle a co je mimo rozsah, pak vypíše číslované požadavky s kritérii přijetí, která lze ověřit. Uložte ho jako prd.md nebo docs/prd/feature-name.md, zkopírujte šablonu níže a každou sekci vyplňte prostými větami.
# PRD: <Feature name>
## 1. Problem
## 2. Goals
## 3. Non-goals
## 5. Requirements
## 6. Acceptance criteria
·
Šablona
Zkopírujte ji do nového souboru a nahraďte vše ve špičatých závorkách. Sekci smažte, jen když jste si jistí, že se netýká věci, a místo prázdného místa napište „žádné“, aby čtenář poznal, že se o ní uvažovalo.
# 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>.
Proč je napsaná takhle
PRD pro AI agenta má stejný úkol jako PRD pro člověka, jen s menším prostorem pro dohady. Člověk se vás na chodbě zeptá, co jste měli na mysli. Agent mezeru vyplní nejlepším odhadem a jede dál.
- Necíle jsou nejlevnější ochrana proti rozrůstání rozsahu. Agenti přidávají „užitečné“ extra, pokud jim neřeknete, ať to nedělají.
- Číslované požadavky (R1, R2) umožní plánu, testu i komentáři z revize odkazovat na totéž.
- Kritéria přijetí jako políčka úkolového seznamu se změní v seznam úkolů, které lze odškrtávat. Syntaxi viz úkolové seznamy v Markdownu.
- Okrajové případy jsou místo, kde vygenerovaný kód selhává jako první: prázdná data, špatný vstup, ztracené připojení.
- Návrat zpět vás donutí promyslet, jak změnu vrátit, ještě než ji nasadíte.
Jak ho vyplnit
-
Napište problém bez řešení
Pokud nedokážete problém popsat, aniž byste pojmenovali funkci, funkce je jen odhad. Řekněte, koho se týká a co se děje dnes.
-
Každý cíl udělejte měřitelný
„Rychlejší pokladna“ je přání. „Medián pokladny pod 30 sekund“ je cíl.
-
Požadavky pište jako chování
„Systém musí zobrazit chybu, když je soubor větší než 10 MB“ se dá otestovat. „Dobré zpracování chyb“ ne.
-
Ke každému požadavku přidejte kritérium
Použijte schéma Given, when, then (Je dáno, když, pak). Pokud kontrolu nedokážete napsat, požadavek je vágní.
-
Skončete otevřenými otázkami
U každé uveďte vlastníka. Agent se na ně má ptát, ne je rozhodovat.
Diagramy pomáhají u toků a stavů; blok Mermaid v souboru se snadno mění. Viz syntaxe vývojových diagramů Mermaid.
Předání PRD AI agentovi
Agenta nasměrujte na soubor, ne ho vkládejte: „Přečti docs/prd/export.md a navrhni plán; zatím nepiš kód.“ Nejdřív požádejte o plán, porovnejte ho s číslovanými požadavky a pak nechte agenta stavět. PRD, plán a seznam úkolů jsou obvykle tři oddělené soubory. PRD říká co a proč, plán říká jak a úkoly jsou kroky.
Pravidla pro celý projekt (příkazy, styl, složky) držte mimo PRD v CLAUDE.md nebo AGENTS.md, aby PRD obsahovalo jen to, co je specifické pro tuto funkci.
Časté chyby
- Řešení převlečené za problém. „Potřebujeme rozbalovací seznam“ není problém.
- Žádné necíle. Všechno okolo se stane součástí rozsahu.
- Požadavky, které nemohou selhat. Pokud by je žádný test nikdy nemohl neprojít, nic neříkají.
- PRD, které už nikdo nečte. Aktualizujte stav a otevřené otázky průběžně.
- Deset stran na malou změnu. Funkci na jeden den stačí půl stránky.
Produktoví manažeři mohou PRD číst a revidovat v DotMD jako vykreslené dokumenty, s komentáři přímo k danému místu. Čtení je zdarma; úpravy a revize viz ceník.
Otázky k šablonám PRD v Markdownu
Co patří do šablony PRD?
Problém, cíle, necíle, uživatelské scénáře, číslované požadavky, kritéria přijetí, okrajové případy, data a rozhraní, metriky úspěchu, nasazení a návrat zpět a otevřené otázky.
Proč psát PRD v Markdownu?
Soubor Markdown leží vedle kódu, má čitelnou historii v Gitu, AI agent ho snadno přečte a lze ho revidovat a měnit jako jakýkoli jiný soubor.
Jak soubor pojmenovat?
prd.md pro jediný produkt, nebo docs/prd/feature-name.md, když jich je víc. Jedna funkce v jednom souboru.
Čím se PRD liší od specifikace?
PRD říká, co postavit a proč, z pohledu uživatele. Specifikace nebo plán říká, jak se to postaví. Držte je odděleně, aby šlo každé revidovat samostatně.