prd

name	prd
description	Create a full Product Requirements Document (PRD-NNN) via a structured PM interview — for large initiatives that justify the overhead. Use when PM mentions "create PRD", "write product requirements", "PRD document", "product brief", "requirements doc", "напиши PRD", "создай PRD", or any request to capture a full product vision before handing to design / engineering. Trigger liberally — under-triggering forces the agent to write freeform docs that drift from the canonical PRD template; over-triggering is recoverable (PM can downgrade to Feature Brief).
argument-hint	[название]

/polisade:prd [название] — Создание PRD для крупной инициативы

Создание полного Product Requirements Document через структурированное интервью с PM.

Используй PRD только для:

• Новых модулей или подсистем
• Эпиков на несколько недель работы
• Кросс-функциональных инициатив
• Работы, требующей согласования стейкхолдеров

Для обычных фич используй /polisade:feature — это быстрее и проще.

Использование

/polisade:prd                      # Новый PRD с интервью
/polisade:prd Система уведомлений  # PRD с названием

Принципы

• Проблема первична, решение вторично (Marty Cagan, SVPG). PRD описывает ЧТО и ЗАЧЕМ, а не КАК.
• Эпистемологическая честность. Каждое утверждение — это либо факт (подтверждён данными), либо допущение (считаем верным, но не проверяли), либо гипотеза (требует эксперимента). Никогда не выдавай гипотезу за факт.
• Однозначные требования (IEEE 830 / ISO 29148). Тест: могут ли два инженера независимо прочитать требование и построить одно и то же? Если нет — переформулируй.
• Документ — единый источник правды. PRD должен быть понятен без дополнительного контекста.
• Не выдумывай факты. Если информация отсутствует — спроси или пометь как открытый вопрос.
• Избегай weasel words: «удобный», «быстрый», «интуитивный», «бесшовный». Замени каждое измеримым критерием.

Алгоритм

Проверка необходимости PRD

Сначала уточни у PM: "Это крупная инициатива на несколько недель? Если это обычная фича на несколько дней, лучше использовать /polisade:feature."

Фаза 0: Проверка контекста

Перед началом интервью проверь, предоставил ли продакт дополнительные материалы (файлы, ссылки, скриншоты, документы, транскрибации).

Если предоставлена транскрибация встречи / заметки:

• Прочитай полностью (даже если файл большой — читай по частям)
• Извлеки все продуктово-значимые решения, цифры, имена участников, открытые вопросы
• Резюмируй что понял и сразу переходи к генерации PRD (интервью не нужно — информация уже есть)
• Если есть пробелы — задай только точечные вопросы по ним

Если предоставлены другие материалы:

• Прочитай все файлы (Read для файлов, WebFetch для ссылок)
• Кратко резюмируй что понял
• Задай уточняющие вопросы по пробелам

Если материалы НЕ предоставлены:

• Спроси: "У вас есть дополнительные материалы? Например: ссылки на документацию, транскрибации встреч, исследования, макеты, технические документы. Если нет — не проблема, начнём с вашего описания."
• Если нет — переходи к фазе 1

Фаза 1: Получение идеи

Попроси продакта описать идею продукта или фичи в свободной форме.

Если продакт уже описал идею в первом сообщении — не проси повторяться, переходи к интервью.

Фаза 2: Глубинное интервью

Работай как профессиональный интервьюер — задавай по одному вопросу за раз. Каждый следующий вопрос строится на предыдущем ответе.

Почему по одному: список из 5-7 вопросов провоцирует поверхностные ответы. Один точный вопрос — развёрнутый, честный ответ.

Области, которые нужно покрыть:

A. Проблема и ценность — Какую боль решаем? Почему сейчас? Какие есть данные? B. Целевые пользователи и JTBD — Для кого? В каких ситуациях? Какие задачи решают? C. Контекст и альтернативы — Что используют сейчас? Почему не подходит? D. Критерии успеха и метрики — Как поймём что получилось? Конкретные цифры? E. Функциональный скоуп — Что должен уметь? Что явно не входит? Приоритеты? J. Границы системы и интеграции (System boundaries & integrations)

• Какая конкретно АС / модуль / сервис дорабатывается?
• Эта система standalone или интегрируется с другими?
• [если интеграция] С какими системами? Кто за них отвечает?
• [если интеграция] Есть ли уже согласованные контракты (API, XSD, topic list)?
• [если интеграция] Какие данные идут в каком направлении?
• Наша команда отвечает только за эту АС — верно? Что точно вне нашей зоны? F. Нефункциональные требования — Нагрузка, SLA, безопасность, приватность, комплаенс? G. Ограничения и зависимости — Юридические, технические, организационные, от команд? H. Риски — Что может пойти не так? Какие допущения самые хрупкие? I. Раскатка и эволюция — MVP, V1, V2? Почему именно такой состав MVP?

Правила интервью:

1. Один вопрос — один ответ. Исключение: короткий уточняющий подвопрос к основному.
2. Адаптивность. Не иди механически по списку. Если тема раскрыта — двигайся дальше. Если поверхностно — копай глубже.
3. Лимит: 8-15 вопросов. После 6-8 — сообщи прогресс: "Покрыли X, Y, Z. Осталось уточнить A, B — ещё 3-4 вопроса."
4. Умный выход. Нет ответа — зафиксируй как допущение. Продакт торопится — "Сгенерирую черновик и помечу пробелы."
5. Явный переход. "У меня достаточно информации. Перехожу к написанию PRD."
6. Границы системы. Если PM упоминает несколько систем → обязательно уточнить: "Какую из этих систем мы реализуем?" Если PM говорит "интеграция с X" → спросить: "Контракт с X согласован или нужно проектировать?" Если PM не упоминает интеграций → явно спросить: "Система полностью автономная?"

Фаза 3: Генерация PRD

Когда интервью завершено (или когда информации из транскрибации/материалов достаточно):

1. Вычисли next-id для PRD по протоколу из skills/tasks/references/compute-next-id.md (единый max по .state/counters.json, PROJECT_STATE.artifactIndex и file-scan docs/prd/PRD-*.md). При Counter drift — АБОРТ с рекомендацией python3 {plugin_root}/scripts/polisade_sync.py . --apply --yes.
2. Write-guard. Перед Write проверь, что docs/prd/PRD-{N}-slug.md не существует и что PRD-{N} нет в state.artifactIndex. При коллизии — АБОРТ.
3. Создай файл docs/prd/PRD-XXX-slug.md по структуре ниже
4. Заполни PRD ответами из интервью
5. Инкрементируй счётчик (counters.json[PRD] = N).
6. Обнови PROJECT_STATE.json:
   • Добавь артефакт со статусом ready
   • Добавь в readyToWork
7. Покажи результат

КРИТИЧЕСКИ ВАЖНО — правила генерации, которые отличают хороший PRD от скелета:

1. Используй таблицы. Функциональные требования, риски, open questions, метрики, decision log, глоссарий — всё в таблицах. Таблицы заставляют заполнять все поля и делают документ сканируемым.

2. Нумеруй всё. FR-01, OS-01, NFR-01, AC-01, R-01, OQ-01 — каждый элемент должен иметь уникальный ID для ссылок.

3. Соблюдай минимумы глубины (см. раздел "Минимальные требования к глубине" ниже). Это самое важное правило — оно не даёт скатиться в поверхностный скелет.

4. Маркируй эпистемологический статус. Каждая цифра, утверждение, метрика должна быть помечена: подтверждено (чем), допущение, гипотеза (требует валидации).

5. Называй конкретных людей. Если из интервью известны ответственные, владельцы зависимостей, участники решений — указывай ФИО или роли.

6. Давай примеры текстов. В user journey включай примеры сообщений/уведомлений, которые увидит пользователь.

Структура PRD (обязательная)

# PRD: <Название продукта/фичи>

**Статус:** Черновик | Финал
**Дата:** <текущая дата>
**Автор:** <имя продакта / источник>
**Участники:** <кто предоставил информацию — имена и роли>
**Документ описывает продукт целиком.** Архитектурная детализация — в отдельном ТЗ.

---

## 1. Executive Summary

Одностраничное описание на 3-5 абзацев:
- Абзац 1: Какая проблема существует, для кого, масштаб проблемы (цифры)
- Абзац 2: Почему проблема не решается текущими средствами, почему сейчас
- Абзац 3: Что за продукт, какую ценность даёт (НЕ список фич, а outcome)
- Абзац 4: Ожидаемый результат (с пометкой "гипотеза" если не подтверждён)
- Финальная строка: «Данный документ — НЕ перечень фич, а описание проблемы,
  аудитории и рамок продукта.»

---

## 2. Описание проблемы

### 2.1 Суть проблемы
Одним абзацем — что не работает и для кого.

### 2.2 Кто сталкивается и в каких ситуациях
Перечисли конкретные ситуации (не абстрактные).

### 2.3 Масштаб проблемы

| Показатель | Значение | Источник |
|---|---|---|
| ... | ... | Подтверждено / Допущение / Гипотеза |

### 2.4 Предположения, требующие валидации
Явно отдели подтверждённое от предполагаемого.

---

## 3. Целевые пользователи и персоны

### 3.1 Первичные пользователи

| Пользователь | Характеристика |
|---|---|
| **Персона 1** | Контекст, мотивация, боль |
| **Персона 2** | ... |

### 3.2 Вторичные / косвенные пользователи

| Пользователь | Контекст |
|---|---|
| ... | ... |

### 3.3 Jobs-to-be-Done

Минимум 2-3 формулировки, покрывающие разные контексты использования:

> **JTBD-1:** «Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат].»
> **JTBD-2:** «Когда [другая ситуация], я хочу ...»
> **JTBD-3:** «Когда [ещё ситуация], я хочу ...»

### 3.4 Вне скоупа (кто НЕ является целевым пользователем)

| Категория | Обоснование исключения |
|---|---|
| ... | ... |

---

## 4. Текущие альтернативы и их недостатки

| Альтернатива | Почему не работает |
|---|---|
| ... | ... |

**Что пользователи делают сегодня (типовой негативный сценарий):**
Опиши конкретный путь пользователя, который приводит к проблеме.

**Ключевой инсайт:** одно предложение, суммирующее почему текущие решения не работают.

---

## 5. Видение продукта и ценностное предложение

### 5.1 Что меняется для пользователя
### 5.2 Что НЕ меняется
### 5.3 Что продукт НЕ пытается решить

---

## 6. Скоуп

### 6.1 В скоупе (функциональные требования)

| # | Требование |
|---|---|
| FR-01 | [Актор] должен иметь возможность [действие], чтобы [результат] |
| FR-02 | ... |

Правила написания FR:
- Каждое требование — одно предложение
- Формат: «Система должна...» или «Пользователь должен иметь возможность...»
- Без деталей технической реализации (КАК — это ТЗ, не PRD)
- Тест на однозначность: могут ли два инженера построить одно и то же?

### 6.2 Вне скоупа

| # | Исключение | Обоснование |
|---|---|---|
| OS-01 | ... | Почему исключено / когда планируется |

---

## 6A. Внешние системы и границы ответственности

### 6A.1 Система под доработку

| Параметр | Значение |
|---|---|
| Название АС / модуля | ... |
| Назначение | ... |
| Команда-владелец | ... |
| Компоненты в скоупе | API, БД, интеграционный адаптер, … |

### 6A.2 Смежные системы

| Система | Роль | Протокол | Направление данных | Команда-владелец | Статус контракта |
|---|---|---|---|---|---|
| ... | ... | REST / Kafka / gRPC / ... | → / ← / ↔ | ... | Согласован / В проработке / Отсутствует |

### 6A.3 Что НЕ в нашей ответственности

| # | Область | Ответственная команда |
|---|---|---|
| ... | ... | ... |

> Если система standalone (без интеграций) → "Не применимо (standalone система)".

---

## 7. Пользовательские сценарии

### 7.1 Happy Path
Пошаговый сценарий основного успешного пути. Включай примеры
текстов, которые увидит пользователь.

### 7.2 Критичные крайние случаи (Edge Cases)

| # | Сценарий | Ожидаемое поведение |
|---|---|---|
| EC-1 | ... | ... |

### 7.3 Сценарии ошибок (Failure Scenarios)

| # | Сценарий | Ожидаемое поведение |
|---|---|---|
| FS-1 | ... | ... |

Failure scenarios — это не edge cases. Это ситуации, когда что-то идёт
НЕ по плану (сбой интеграции, таймаут, недоступность данных, некорректный ввод).

---

## 8. Нефункциональные требования

| # | Категория | Требование |
|---|---|---|
| NFR-01 | **Производительность** | Конкретные цифры: RPS, время отклика |
| NFR-02 | **Надёжность** | SLA, поведение при сбоях |
| NFR-03 | **Безопасность** | Стандарты, требования к данным |
| NFR-04 | **Приватность (Privacy)** | Какие данные обрабатываются, согласие |
| NFR-05 | **Комплаенс (Compliance)** | Регуляторные требования |
| NFR-06 | **Масштабируемость** | Рост от MVP до целевого масштаба |

Privacy и Compliance — отдельные строки, не часть «Безопасности».

---

## 9. Метрики успеха и критерии приёмки

### 9.1 Продуктовые метрики (North Star)

| Метрика | Описание | Целевое значение | Статус |
|---|---|---|---|
| ... | ... | ... | Факт / Гипотеза / TBD |

### 9.2 Критерии приёмки (Acceptance Criteria)

| # | Критерий |
|---|---|
| AC-01 | Если [условие], то система должна [поведение] |

### 9.3 Методика валидации
Как конкретно будет измеряться успех: A/B тест, пилот vs контроль,
до/после, UX-тестирование и т.д.

---

## 10. Допущения, риски и открытые вопросы

### 10.1 Допущения

| # | Допущение | Статус подтверждения |
|---|---|---|
| A-01 | ... | Устные договорённости / Требует проверки / Подтверждено |

### 10.2 Риски

| # | Риск | Вероятность | Влияние | Митигация |
|---|---|---|---|---|
| R-01 | ... | Высокая/Средняя/Низкая | Высокое/Среднее/Низкое | Стратегия |

### 10.3 Открытые вопросы

| # | Вопрос | Ответственный | Срок | Статус |
|---|---|---|---|---|
| OQ-01 | ... | Имя/Роль | YYYY-MM-DD | Открыт / В работе / Закрыт |

### 10.4 Что требует исследования (Discovery)

| # | Область | Описание | Метод проверки |
|---|---|---|---|
| D-01 | ... | ... | Эксперимент / Прототип / Анализ данных / UX-тест |

---

## 11. Зависимости и ограничения

### 11.1 Технические зависимости

| # | Зависимость | Владелец | Критичность |
|---|---|---|---|
| DEP-01 | ... | Команда/Имя | Критическая / Высокая / Средняя |

### 11.2 Организационные зависимости
### 11.3 Юридические / регуляторные ограничения
### 11.4 Временные и бюджетные ограничения

---

## 12. MVP и эволюция

### 12.1 MVP
- **Scope:** ссылка на FR-01 — FR-XX
- **Обоснование:** почему именно этот набор (проверка какой гипотезы?)
- **Что намеренно отложено:** список с причинами
- **Клиентская база:** ожидаемый масштаб пилота

### 12.2 V1 — После успешного пилота

| # | Функциональность |
|---|---|
| V1-01 | ... |

### 12.3 V2 — Масштабирование

| # | Функциональность |
|---|---|
| V2-01 | ... |

---

## 13. Приложения

### 13.1 Глоссарий

| Термин | Определение |
|---|---|
| ... | ... |

### 13.2 Ссылки

| # | Документ | Статус | Источник |
|---|---|---|---|
| REF-01 | ... | Есть / Ожидается | Кто предоставит |

### 13.3 Лог решений (Decision Log)

| Дата | Решение | Участники |
|---|---|---|
| YYYY-MM-DD | Что решили | Кто принял решение |

---

## Notes for Next Iteration

Для перевода из ЧЕРНОВИК в ФИНАЛ необходимо:
1. [Перечисли конкретные пробелы, которые нужно закрыть]

Минимальные требования к глубине

Именно этот раздел отличает полноценный PRD от поверхностного скелета. При генерации PRD проверяй каждый пункт как чеклист.

Раздел	Минимум	Пояснение
Executive Summary	3-5 абзацев	Полноценное повествование с цифрами
Problem Statement	3 подраздела + таблица масштаба	Суть + кто + масштаб + допущения
Первичные пользователи	2+ персоны	С характеристиками, не просто «ИП и юрлица»
JTBD	3 формулировки	Разные контексты использования
Альтернативы	4+ альтернативы	Включая «ничего не делать»
Функциональные требования	10+ FR	Нумерованные в таблице, каждый — одно предложение
Out-of-scope	5+ исключений	Каждое с обоснованием
Happy path	5+ шагов	С примерами текстов для пользователя
Edge cases	3+ сценариев	В таблице: сценарий + ожидаемое поведение
Failure scenarios	3+ сценариев	Отдельно от edge cases — это сбои
NFR	6+ строк	Включая Privacy и Compliance отдельно
Метрики	3+ метрики	С пометкой «гипотеза» или «факт»
Acceptance criteria	5+ критериев	Формат: «Если [условие], то [поведение]»
Допущения	3+	С указанием статуса подтверждения
Риски	5+	С probability / impact / mitigation
Open questions	5+	С ответственным и статусом
Discovery	2+ пункта	Эксперименты, которые нужно провести
Зависимости	3+	С владельцем и критичностью
Глоссарий	8+ терминов	Все аббревиатуры и доменные термины
Decision log	3+ решений	С датой и участниками

Если данных из интервью не хватает для минимума — заполни то что знаешь и явно пометь пробелы в разделе "Notes for Next Iteration". Лучше честный пробел, чем выдуманный контент.

Примеры: хорошо vs плохо

Функциональные требования

Плохо:

Система должна показывать данные клиенту

Хорошо:

| FR-04 | При первом входе клиента: если данные не получены в течение допустимого таймаута (~10 сек), система должна продолжить получение в фоновом режиме (асинхронно), не блокируя сессию клиента и не показывая ложное сообщение «данных нет» |

Риски

Плохо:

Есть риск задержки от внешней системы

Хорошо:

| R-01 | Задержка ответа внешней системы (SLA — до 3 суток) | Средняя | Высокое — данные неактуальны | Асинхронная модель + дисклеймер о сроках |

Open questions

Плохо:

Надо уточнить механизм подписки

Хорошо:

| OQ-01 | Точный механизм подписки: pub/sub или polling? Частота, лимиты, rate limits | J. Smith / Backend Lead | 2026-04-20 | Открыт |

JTBD

Плохо:

Пользователь хочет видеть информацию

Хорошо:

JTBD-3: «Когда денег на оплату сейчас нет, я хочу получить напоминание позже и ближе к критическому сроку, чтобы вернуться к оплате, когда деньги появятся.»

Самопроверка перед финализацией

После генерации PRD пройди по этому чеклисту. Если хотя бы один пункт не выполнен — доработай.

• Каждый раздел содержит не меньше минимума из таблицы выше
• Все FR пронумерованы (FR-01, FR-02, ...) и оформлены в таблицу
• Все риски имеют вероятность, влияние и стратегию митигации
• Все open questions имеют ответственного
• Все метрики помечены как «факт», «гипотеза» или «TBD»
• Все out-of-scope имеют обоснование
• Decision log содержит дату и участников
• Глоссарий покрывает все аббревиатуры в документе
• JTBD — минимум 3 формулировки в разных контекстах
• Edge cases и failure scenarios — отдельные таблицы (это разные вещи)
• Privacy и Compliance — отдельные строки в NFR
• Раздел Discovery (эксперименты) заполнен
• Notes for Next Iteration перечисляет конкретные пробелы
• Нет weasel words без измеримых критериев

Integration Checkpoint (после генерации PRD)

Если в PRD заполнена секция §6A «Внешние системы и границы ответственности» и таблица «Смежные системы» (§6A.2) содержит хотя бы одну строку:

Автоматически добавь в §10.3 "Открытые вопросы" по одному OQ на каждую смежную систему, у которой статус контракта ≠ "Согласован":

#	Вопрос	Ответственный	Срок	Статус
OQ-NN	Контракт с [система] согласован? Если да — где документ?	[владелец из §6A.2]	[+2 недели]	Открыт
OQ-NN	Кто контактное лицо по интеграции с [система]?	PM	[+1 неделя]	Открыт
OQ-NN	[система] уже в продакшне или параллельно дорабатывается?	[владелец из §6A.2]	[+1 неделя]	Открыт

Не добавлять вопросы для систем со статусом "Согласован". Если §6A отсутствует или все системы standalone — пропустить чекпоинт.

Правила оформления

• Ясный, деловой язык
• Никакого маркетингового буллшита
• Никаких спекулятивных утверждений без пометки «допущение» или «гипотеза»
• Если что-то неизвестно — пиши что неизвестно и кто должен это выяснить
• PRD должен быть понятен новому человеку в команде без дополнительного контекста

Формат вывода

═══════════════════════════════════════════
PRD СОЗДАН
═══════════════════════════════════════════

ID: PRD-001
Название: [Название]
Файл: docs/prd/PRD-001-slug.md
Статус: ready
Тип: Крупная инициатива

Краткое содержание:
• Проблема: [1-2 предложения]
• Решение: [1-2 предложения]
• Приоритет: P1

Следующий шаг:
   → /polisade:spec PRD-001 для технической спецификации
   → /polisade:continue для автономной работы
═══════════════════════════════════════════

Важно

• PRD — это для крупных инициатив, не для каждой фичи
• Задавай вопросы по одному
• Если PM описывает что-то простое — предложи /polisade:feature вместо PRD
• Для транскрибаций: можно пропустить интервью и генерировать сразу, дозадав точечные вопросы
• После каждого ответа продакта решай: задать ещё вопросы или генерировать PRD
• Явно обозначай когда PRD — ЧЕРНОВИК, а когда ФИНАЛ
• После генерации PRD спроси: "Хотите что-то изменить или дополнить?"