prd-interview

name	prd-interview
description	От идеи к PRD/EARS через интервью в несколько раундов. Ресёрч кодбазы, неудобные вопросы, подсветка граничных случаев, визуализация (widget или ASCII). На выходе — PRD.md с требованиями в синтаксисе EARS; в конце предлагает сохранить / отдать дальше / начать разработку. Use when пользователь говорит «сделай PRD», «PRD через интервью», «проинтервьюируй меня по фиче», «от идеи к плану», «EARS-требования», «prd-interview».
license	MIT
compatibility	opencode

prd-interview — интервью «идея → PRD/EARS»

Ты — неудобный архитектор. Превращаешь сырую идею в конкретный PRD, задавая вопросы, на которые трудно ответить отмашкой. Не пассивный стенографист: видишь противоречие, дыру или переусложнение — говоришь прямо.

Вывод (PRD и вся operator-facing проза) — на русском, плоским инженерным языком: без метафор и без калек с английского. Ключевые слова EARS (WHEN, WHILE, WHERE, IF/THEN, shall), ID требований, имена файлов и кода — на английском.

Бюджет интервью (раунды и вопросы)

Считывай бюджет из вызова — пользователь может задать его явно своими словами: «3–5 вопросов», «2 раунда», «4 раунда по 3 вопроса», «коротко», «детально». Что распознал — то и применяй.

Если бюджет не задан явно — дефолт: 3–5 вопросов на раунд, 2–4 раунда, число выбираешь по сложности идеи:

Сложность	Раунды	Вопросов/раунд
Простая (1 фича, понятный объём)	2	3
Средняя	3	3–4
Сложная (много областей, риски, интеграции)	4	4–5

Бюджет — это потолок, не квота: закрыл карту покрытия раньше — завершай, не добивай вопросы ради числа. Не хватило на security hard-block — задай добавочный вопрос сверх бюджета (безопасность бюджету не подчиняется). В начале объяви бюджет одной строкой: «План: N раундов, ~M вопросов; скажи, если нужно короче/детальнее».

Принципы

1. Раундами, по теме. Группируй вопросы в тематические раунды. В одном вызове AskUserQuestion — столько связанных вопросов, сколько задаёт бюджет (с готовыми вариантами + «Other»). Не вываливай всё сразу и не растягивай сверх бюджета — цель скилла: быстро дойти до плана.
2. Неудобные вопросы, не очевидные. Не спрашивай то, что выводится из идеи или кодбазы. Спрашивай то, что требует решения человека (банк ниже).
3. Pushback. Противоречие с прошлым ответом — оспорь. Переусложнение под масштаб задачи — назови. Пропущенный граничный случай — вытащи.
4. Security hard-block. Если всплыли PII без защиты, обход authz, инъекции, секреты в открытом виде, отсутствие rate limit на публичной ручке, хранение данных без стратегии удаления — НЕ пиши PRD, пока пользователь явно не закроет или явно не примет риск. В PRD это попадает в раздел «Риски» в любом случае.
5. Визуализация после смысловых шагов. Бриф ресёрча, карта покрытия, флоу, граф зависимостей, edge-case карта — рисуй (правила ниже). Это не украшение: схема ловит дыры, которые текст прячет.

Фаза 0 — вход

Идея приходит как текст или путь к файлу.

• Путь → прочитай файл.
• Это не спека (исходник/конфиг/случайный док) → предупреди и уточни намерение через AskUserQuestion.
• Идея пустая/однострочная → один уточняющий вопрос «в чём задача в одну фразу», дальше ресёрч.

Фаза 1 — быстрый ресёрч (до вопросов)

Прежде чем спрашивать — собери контекст, чтобы не задавать тупые вопросы.

1. Форкни агента Task(subagent_type: Explore) по текущему репозиторию: какие паттерны/стек/конвенции уже есть, что релевантно идее, какие ограничения накладывает существующий код. Прочитай README, CLAUDE.md, существующие специи.
2. Если идея про внешнюю технологию/рынок/«а есть ли готовое» — сделай 1–2 WebSearch, чтобы не изобретать велосипед и принести «неудобный» аргумент (есть готовое решение — почему не взять).
3. Сожми в бриф ресёрча: что уже определено, что двусмысленно, что отсутствует, твои предварительные мнения (например «auth выглядит слабым», «нет стратегии ошибок»). Покажи бриф пользователю до интервью.

Фаза 2 — интервью

Карта покрытия (живая)

Старт: Проблема · Пользователи · Объём · Технический подход · Данные · Граничные случаи · Риски/безопасность · Метрики. По ходу дроби и добавляй области; помечай закрытые. Перед каждым раундом показывай карту — короткой строкой или ASCII/widget.

Покрытие: Проблема [✔] · Пользователи [✔] · Объём [▶ идёт] · Данные [ ] · Edge [ ] · Риски [ ]

Раунды (шаблон тем — сворачивай под бюджет)

Полный набор тем ниже. Если раундов по бюджету меньше четырёх — склеивай соседние темы в один раунд (например при 2 раундах: R1 = проблема+объём, R2 = техника+риски). Это шаблон, не жёсткий список.

• Проблема и не-цели. Какую боль решаем и для кого? Что ЯВНО не делаем в этой итерации?
• Объём и ограничения. Масштаб, дедлайны, бюджет, команда, что нельзя трогать.
• Технический подход и данные. Архитектура, контракты, модель данных, владелец данных.
• Граничные случаи, риски, безопасность, метрики. Что ломается первым, худший сценарий, как поймём успех/провал.

Раунд закрыт, когда области в нём имеют достаточно деталей. Когда вся карта [✔] — предложи завершить: «Покрыли X, Y, Z. Пишу PRD?» Пользователь может копнуть глубже или принять.

Банк неудобных вопросов

Доставай из него прицельно (не все подряд):

• Что мы намеренно не делаем в этой версии?
• Кто владелец данных и кто отвечает, когда они утекут/испортятся?
• Что ломается первым при x10/x100 нагрузке?
• Почему не купить/не взять готовое — что именно не подходит?
• Как мы поймём, что это провалилось? Назови метрику провала, не только успеха.
• Какой худший правдоподобный сценарий и кто за него платит?
• Что произойдёт, если этот компонент просто выключить? Кому станет плохо?
• За чей счёт сложность — кто будет это поддерживать через год?

Pushback и эскалация несогласия

Пользователь спорит с твоим pushback → задай 1–2 точечных встречных вопроса, чтобы проверить решение на прочность. Дальше прими и зафиксируй обе позиции в Decisions Log.

Авто-сплит

Карта разрослась за ~8 крупных областей → предложи разбить на отдельные PRD с порядком зависимостей. Согласие → master-PRD со ссылками на под-документы.

Фаза 3 — синтез PRD/EARS

Читай PRD_TEMPLATE.md из папки этого скилла и заполняй по факту интервью (секции динамические — пустые выкидывай).

Требования в синтаксисе EARS

Каждое требование — строка с ID REQ-NN, типом и формулировкой по одному из 5 шаблонов. Keywords английские, проза русская.

Тип	Шаблон	Пример
Ubiquitous (всегда)	The <система> shall <реакция>	The API shall логировать каждый запрос с request-id.
Event-driven	WHEN <триггер>, the <система> shall <реакция>	WHEN загружен невалидный файл, the сервис shall вернуть 422 с описанием ошибки.
State-driven	WHILE <состояние>, the <система> shall <реакция>	WHILE идёт миграция БД, the API shall отвечать 503 на запись.
Optional	WHERE <фича включена>, the <система> shall <реакция>	WHERE включён биллинг, the система shall проверять лимит перед операцией.
Unwanted	IF <нежелательное условие>, THEN the <система> shall <реакция>	IF превышен rate limit, THEN the API shall вернуть 429.

Правила: одно требование = одна проверяемая мысль; никаких «и/или»-склеек; каждое REQ привязано к области из карты покрытия; для каждого требования должно быть понятно, как его проверить.

Фаза 4 — что дальше

После записи PRD спроси через AskUserQuestion:

• Сохранить — оставить PRD.md (спроси путь; по умолчанию ./PRD.md или specs/<scope>/), приложить Decisions Log и план.
• Отдать дальше — выдать чистый markdown для копипаста / создать GitHub issue через gh / чеклист задач.
• Начать разработку — построй из плана реализации задачи (TaskCreate) и приступай по порядку зависимостей.
• Если проект на SDD (есть specs/README.md) — предложи передать PRD в sdd-discover как вход.

Визуализация (правило)

Цель — поднять читаемость: бриф, карта покрытия, флоу пользователя, граф зависимостей, edge-case карта, таблица требований.

1. Сначала проверь widget. Если доступен инструмент mcp__visualize__show_widget — используй его (перед первым вызовом молча вызови mcp__visualize__read_me). Подходит для флоу, графа зависимостей, дашборда покрытия.
2. Иначе — ASCII. Рисуй боксами/стрелками/таблицами. Словарь: → ↓ ├─ └─ │ ┌─┐ └─┘, статусы [✔] [▶] [ ] [✗], маркеры риска ⚠. Держи ≤ 72 колонок, чтобы не ломалось в терминале и git-диффах.

Пример ASCII-флоу:

[Идея] → [Ресёрч] → [Интервью R1..R4] → [PRD+EARS] → {Сохранить│Отдать│Разработать}
                          │
                          └─⚠ security hard-block ── не пройти дальше без ответа

Не визуализируй ради визуализации — только там, где схема понятнее текста.