# Prd From Context > Сформировать PRD на русском языке из текущего контекстного окна, а именно - уже обсужденных требований, решений, ограничений, пользовательских сценариев, технического контекста и понимания кодовой базы. Использовать, когда пользователь хочет получить PRD на основе уже имеющегося контекста без дополнительного интервью. - Skill: `madteacher/prd-from-context` (Agent Skill) - Install (CLI): `npx skillmds@latest add madteacher/prd-from-context` - Raw SKILL.md: https://api.skillmd.com/api/skills/madteacher/prd-from-context/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: MADTeacher (https://skillmd.com/u/madteacher) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/madteacher/prd-from-context --- Сформируй PRD на основе текущего контекстного окна. Не интервьюируй пользователя. Не задавай уточняющих вопросов. Не останавливайся из-за нехватки информации. Синтезируй PRD из того, что уже известно из диалога, предоставленных материалов, описания задачи, обсужденных решений и понимания кодовой базы. Если каких-то данных не хватает, явно зафиксируй это в разделах «Предположения» и «Открытые вопросы», но не придумывай неподтвержденные детали как факты. ## Процесс 1. Собери из текущего контекста все, что уже известно: - какую проблему нужно решить; - для кого создается решение; - какие пользовательские сценарии обсуждались; - какие требования уже сформулированы; - какие ограничения, зависимости и риски известны; - какие технические решения уже приняты; - какие части системы могут быть затронуты; - какие критерии готовности или проверки уже упоминались. 2. Используй уже имеющееся понимание кодовой базы, если оно есть. Если доступны файлы проекта, документация, тесты или другие материалы, и их изучение необходимо для точности PRD, изучи их самостоятельно. Не спрашивай пользователя о том, что можно выяснить из доступных материалов. 3. Определи крупные функциональные и технические блоки, которые потребуется создать или изменить для реализации. При этом ищи возможности выделить глубокие модули, которые можно тестировать изолированно. Глубокий модуль — это модуль, который инкапсулирует значимую функциональность за простым, устойчивым и тестируемым интерфейсом. 4. Зафиксируй проектные решения как решения, а неопределенности — как неопределенности. Не смешивай: - факты из контекста; - выводы на основе контекста; - предположения; - открытые вопросы. 5. Напиши PRD по шаблону ниже и сохрани в markdown-файл в в директории docs/prd/ в корневой директории проекта. Не включай конкретные пути к файлам и фрагменты кода. Они быстро устаревают и не должны быть частью PRD. ## Постановка проблемы Опиши проблему с точки зрения пользователя или заинтересованной стороны. Нужно объяснить: - какая боль или потребность существует; - почему текущее состояние неудовлетворительно; - какое влияние проблема оказывает на пользователя, продукт или процесс. ## Цель решения Опиши, какого результата нужно достичь. Нужно объяснить: - что должно измениться после реализации; - какую ценность получит пользователь; - какой результат будет считаться успешным. ## Контекст Опиши известный контекст задачи. Включи: - текущее состояние продукта или системы; - уже обсужденные ограничения; - важные зависимости; - связанные функции, процессы или компоненты; - релевантные технические или продуктовые вводные. ## Решение Опиши предлагаемое решение с точки зрения пользователя и продукта. Нужно объяснить: - как пользователь будет взаимодействовать с новой или измененной функциональностью; - какое поведение системы ожидается; - какие основные сценарии должны быть поддержаны; - какие изменения должны быть видимы пользователю. ## Пользовательские истории Составь подробный нумерованный список пользовательских историй. Формат каждой истории: 1. Я, как <роль или тип пользователя>, хочу <возможность или действие>, чтобы <ценность или результат>. Список должен быть достаточно полным и покрывать все существенные аспекты функции: - основные сценарии; - альтернативные сценарии; - крайние случаи; - ошибки; - права доступа; - состояния данных; - взаимодействие с существующей функциональностью; - ожидаемую обратную связь от системы. ## Функциональные требования Опиши, что система должна делать. Раздел должен включать: - основные функции; - правила поведения; - состояния и переходы; - обработку ошибок; - ограничения на действия пользователя; - ожидаемые системные реакции; - требования к интерфейсам, если они известны. ## Нефункциональные требования Опиши требования, которые не относятся напрямую к пользовательским сценариям, но важны для качества решения. Включи, если применимо: - производительность; - надежность; - безопасность; - приватность; - масштабируемость; - наблюдаемость; - совместимость; - доступность; - эксплуатационные ограничения. ## Решения по реализации Перечисли известные или выведенные из контекста решения по реализации. Можно включить: - какие модули нужно создать или изменить; - какие интерфейсы или контракты нужно определить; - какие данные или схемы нужно изменить; - какие API или интеграции затрагиваются; - какие архитектурные решения уже приняты; - какие компромиссы были выбраны; - какие зависимости между решениями существуют. Не включай конкретные пути к файлам и фрагменты кода. ## Решения по тестированию Опиши, как следует проверять реализацию. Включи: - какие модули или сценарии нужно покрыть тестами; - какие виды тестов подходят: модульные, интеграционные, end-to-end, регрессионные; - что считается хорошим тестом; - какие внешние поведения нужно проверять; - какие детали реализации не следует тестировать напрямую; - какие похожие тесты или подходы уже есть в проекте, если это известно из контекста. Хороший тест должен проверять наблюдаемое поведение системы, а не внутренние детали реализации. ## Критерии готовности Опиши, по каким признакам можно понять, что задача выполнена правильно. Включи: - пользовательские критерии приемки; - технические критерии; - критерии тестирования; - требования к документации, миграциям или релизу, если применимо. ## Вне рамок Опиши, что явно не входит в этот PRD. Включи: - функции, которые не нужно реализовывать сейчас; - сценарии, которые откладываются; - технические улучшения, которые не являются частью текущей задачи; - продуктовые вопросы, которые не решаются в рамках этой работы. ## Предположения Перечисли предположения, сделанные при составлении PRD. Каждое предположение должно быть сформулировано явно и отделено от подтвержденных фактов. ## Открытые вопросы Перечисли вопросы, на которые в текущем контексте нет надежного ответа. Не задавай эти вопросы пользователю в процессе составления PRD. Просто зафиксируй их как вопросы, которые нужно будет закрыть позже. ## Дополнительные заметки Добавь любые дополнительные наблюдения, риски, зависимости или рекомендации, которые помогут при реализации.