Prd

Skill daniil2711/claude-vibe-workflows/skills/prd

Run a structured PRD interview before writing any code, then produce a clean PRD.md. Use at the start of a new product/feature, or whenever the user wants to define requirements ("новый проект", "хочу сделать приложение", "давай сделаем продукт", "PRD", "ТЗ"). Based on the Sukharev vibe-coding almanac.From its SKILL.md

Install

npx -y skills add daniil2711/claude-vibe-workflows --skill prd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.0 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it

PRD-интервью (метод альманаха ЙЙ)

Цель: до единой строчки кода получить чёткое продуктовое ТЗ в PRD.md. Код пишется только после того, как ТЗ согласовано и проверено.

Когда применять

Новый продукт / новая крупная фича.
Пользователь формулирует идею, а не конкретную задачу.
НЕ нужно для мелкого багфикса или однострочной правки — там сразу к делу.

Процесс

Шаг 1 — Интервью (это окно)

Веди интервью по одному вопросу за раз, с вариантами ответа, чтобы пользователю (он vibe coder / продакт, а не разработчик) было легко отвечать. Дословный паттерн из альманаха:

Давай сделаем ТЗ продукта X. Идея в Y и Z. Задаю вопросы по одному, с вариантами ответа. Ты отвечаешь. Когда вопросов не останется — пишу PRD.md в корне проекта. В PRD.md не будет размышлений и открытых вопросов: только чёткое ТЗ.

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

Один вопрос — один ответ. Не вываливай список из 10 вопросов сразу.
Каждый вопрос даёт 2–4 варианта + «другое». Рекомендуй вариант, если он очевиден.
Спрашивай с продуктовой точки зрения (что умеет, для кого, какую проблему решает, границы MVP, на чём НЕ фокусируемся), а не про технические детали реализации.
Покрой минимум: проблема и аудитория, ключевые сценарии, объём MVP vs «потом», данные/сущности, авторизация, платежи (если есть), нефункциональные требования (нагрузка, 152-ФЗ/приватность), что осознанно НЕ делаем.
Когда вопросы кончились — напиши PRD.md в корень проекта. Только чёткое ТЗ: никаких «возможно», «надо обсудить», открытых вопросов.

Шаг 2 — Независимая проверка (новый чистый контекст)

Альманах настаивает: проверять PRD надо в новом окне с чистым контекстом, иначе модель подыгрывает себе.

Запусти отдельного саб-агента (Agent tool) с задачей read-only:

Прочитай PRD.md. Найди: открытые вопросы, противоречия, дыры в сценариях, нерешённые края (edge cases), всё что осталось неоднозначным. Верни список проблем. Ничего не меняй.

Затем обнови PRD.md по найденным замечаниям (с согласия пользователя по продуктовым решениям).

Шаг 3 — Разбивка на задачи

Только после согласованного PRD: попроси разбить работу на этапы и задачи в TASKS.md (по одной задаче — одна строка, трекаемо). Перед реализацией каждой задачи — отдельно обсудить подводные камни и включить Plan Mode (это уже зона /bug-review и обычного цикла).

Что НЕ делать

Не начинать с кода.
Не писать в PRD.md рассуждения и «todo: уточнить».
Не проверять PRD в том же окне, где его писал.

Стек по умолчанию (если спросят, из альманаха)

TS + Hono + Bun (backend), Expo/React Native (mobile), React/Vite CSR (web, SSR только если нужен SEO), Postgres + Prisma, Electron (desktop). Проектировать под ~10k юзеров, без микросервисов/k8s на старте. Под 152-ФЗ — Яндекс Облако. Готовый шаблон: github.com/di-sukharev/vibe.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.