Шаблон PRD, который агент читает как инструкцию: 8 блоков и файл в корне проекта

Одна страница вместо тридцати

Первое, что делает агент в новой сессии — сканирует корень проекта. Если там лежит PRD.md, дальше объяснять почти ничего не приходится: он видит, что за продукт, на какой стадии, какие фичи закрыты и почему стек выбран именно такой. Без этого файла каждая сессия начинается с моего пересказа по памяти.

Тридцатистраничное ТЗ агент тоже прочитает, но большая часть контекста уйдёт на текст, который к текущей задаче отношения не имеет. Одна страница попадает в контекст целиком и остаётся там до конца работы.

Шаблон

Скопируйте в корень проекта как PRD.md и заполните.

# [Название] — PRD

## Что это
[2-3 предложения: что делает продукт и для кого]

## Статус
[В разработке / MVP / Работает / Заброшен]

## Фичи
- [x] Фича которая есть
- [x] Ещё одна готовая
- [ ] Планируется
- [ ] Когда-нибудь

## Аудитория
[Кто пользуется или будет пользоваться]

## Монетизация
[Как зарабатывает или планирует. "Нет" тоже ответ]

## Ключевые решения
[Почему выбран этот стек/подход/архитектура — то что не очевидно из кода]

## Обновлено
[Дата последнего обновления]

Почему агент читает это как инструкцию

Статус задаёт режим работы. «MVP» означает, что можно резать углы. «Работает» — что любое изменение рискует сломать живых пользователей, и агент сам начинает спрашивать про обратную совместимость.

Фичи с чекбоксами — машиночитаемый бэклог. Разметка - [x] и - [ ] разбирается однозначно, граница между сделанным и планами видна сразу. Просьба «доделай следующую фичу» перестаёт быть загадкой.

Ключевые решения — самый ценный блок и единственный, который нельзя восстановить из кода. Код показывает, что выбран Astro. Он умалчивает, что Astro взят ради статики и скорости, потому что терять позиции в выдаче нельзя. Без этой строки агент однажды предложит «просто переписать на Next.js».

Аудитория и монетизация отсекают лишнее. Если пользователей трое и все внутри команды, предложений про мультиязычность и систему ролей не будет.

На живом проекте

Neon Boutique — переезд магазина с Тильды на Astro + Medusa.js. В «Ключевых решениях» у меня стоит примерно следующее: контентные страницы живут в Astro Content Collections, товары тянутся из Medusa Store API, интерактив (корзина, чекаут) — React-острова с состоянием в Nano Stores, оплата через ЮKassa, nginx-реверс-прокси на VPS. И отдельной строкой: текущие позиции в Google терять нельзя.

Дальше это работает само. Заходит разговор про корзину — агент сразу предлагает остров со стором. Появляется новая страница — он уточняет, идёт она в коллекцию контента или тянется из Medusa. Повторных объяснений архитектуры за сессию ноль.

Отдельно по этому проекту у меня лежат ТЗ (цели, текущее состояние, таблица позиций по запросам) и план реализации по задачам. Роли разные: PRD — карта, в которую агент смотрит всегда; ТЗ и план открываются под конкретную работу.

Правила эксплуатации

• Обновлять в конце сессии. Минута работы: переставить чекбоксы, поправить дату. Устаревший PRD хуже отсутствующего, потому что агент верит написанному.
• Писать причины. Что сделано — видно из кода. Почему сделано именно так — только отсюда.
• Держать одну страницу. Как только файл начинает разрастаться, детали выносятся в отдельный документ со ссылкой.
• Заполнять честно. «Заброшен» в статусе и «Нет» в монетизации — нормальные ответы. Агент принимает их как факты.

Что меняется на практике

Эффект складывается из мелочей. Пропадает вступительный пересказ проекта. Агент перестаёт тащить библиотеки, которые вы уже сознательно отвергли. Вопрос «что дальше?» получает ответ прямо из списка фич.

Побочный эффект достаётся человеку. Когда садишься заполнять «Ключевые решения», выясняется, что часть выборов сделана по инерции и объяснить их нечем. Пустое поле заставляет проговорить.