Prd

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

Метод вайб-кодинга из альманаха Сухарева, упакованный в скиллы и авто-подсказчик для Claude Code: /prd, /bug-review, /sec-audit

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.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

5.0 KB, 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.