Шаблон PRD у Markdown:скопіюйте й заповніть.

Шаблон

Скопіюйте його в новий файл і замініть усе, що в кутових дужках. Видаляйте розділ, лише якщо певні, що він не стосується справи, і пишіть «немає» замість порожнього місця, щоб читач бачив, що про це думали.

# 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>.

Чому він написаний саме так

У PRD для ШІ-агента те саме завдання, що й для людини, але з меншим простором для здогадок. Людина спитає вас у коридорі, що ви мали на увазі. Агент заповнить прогалину найкращим здогадом і піде далі.

• Не-цілі — найдешевший захист від розростання обсягу. Агенти додають «корисні» дрібниці, якщо не сказати їм цього не робити.
• Пронумеровані вимоги (R1, R2) дають змогу плану, тесту й коментарю рев'ю посилатися на те саме.
• Критерії приймання як прапорці списку завдань перетворюються на список справ, який можна відмічати. Синтаксис див. у статті списки завдань у Markdown.
• Крайні випадки — те, на чому згенерований код ламається першим: порожні дані, хибний ввід, втрата з'єднання.
• Відкат змушує подумати, як скасувати зміну, ще до випуску.

Як його заповнювати

1. Опишіть проблему без рішення

   Якщо ви не можете описати проблему, не назвавши функцію, значить, функція — здогад. Скажіть, кого це стосується і що відбувається сьогодні.

2. Зробіть кожну ціль вимірюваною

   «Швидше оформлення замовлення» — побажання. «Медіанний час оформлення менше 30 секунд» — ціль.

3. Пишіть вимоги як поведінку

   «Система має показати помилку, якщо файл більший за 10 МБ» можна перевірити. «Хороша обробка помилок» — ні.

4. До кожної вимоги — свій критерій

   Використовуйте схему «Дано, коли, тоді» (Given, when, then). Якщо перевірку написати не виходить, вимога розпливчаста.

5. Закінчіть відкритими питаннями

   Назвіть відповідального за кожне. Агент має питати про них, а не вирішувати їх.

Діаграми допомагають для потоків і станів; блок Mermaid у файлі легко змінювати. Див. синтаксис блок-схем Mermaid.

Передача PRD ШІ-агентові

Вказуйте агентові файл, а не вставляйте текст: «Прочитай docs/prd/export.md і запропонуй план; поки не пиши код». Спершу попросіть план, звірте його з пронумерованими вимогами, потім дозвольте будувати. PRD, план і список завдань зазвичай три окремі файли. PRD каже, що й навіщо, план — як, а завдання — це кроки.

Правила для всього проєкту (команди, стиль, папки) тримайте поза PRD, у CLAUDE.md чи AGENTS.md, щоб у PRD було лише те, що стосується цієї функції.

Часті помилки

• Рішення під виглядом проблеми. «Нам потрібен випадний список» — не проблема.
• Немає не-цілей. Усе поруч опиняється в обсязі роботи.
• Вимоги, які не можуть не виконатися. Якщо жоден тест не може їх провалити, вони нічого не кажуть.
• PRD, який ніхто не перечитує. Оновлюйте статус і відкриті питання по ходу роботи.
• Десять сторінок на дрібну зміну. Функції на один день вистачить півсторінки.

Менеджери продукту можуть читати PRD і перевіряти їх у DotMD як відмальовані документи, з коментарями до конкретного місця. Читання безкоштовне; про редагування та рев'ю див. ціни.

Питання про шаблони PRD у Markdown

Інші запитання