x-bdd-product-workflow

name	x-bdd-product-workflow
description	Применяй на этапе планирования фичи: PRD → бизнес-интервью → драфт .feature → RFP разработке → разбор вопросов → готовые сценарии

BDD Product Workflow

Этот skill — канонический владелец продуктового пути от требований к готовому .feature.

Он не владеет layout, naming и numbering BDD-файлов. За это отвечает x-bdd-api.

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

• Планируешь новую фичу до начала кодинга.
• Пересобираешь требования перед крупной переработкой поведения.
• Формализуешь бизнес-правила, которые должны попасть в .feature после интервью со стейкхолдерами.

Не применяй для:

• синтаксиса и физической структуры .feature → x-bdd-api
• red/green/blue реализации → x-bdd-dev-workflow
• reverse-engineering legacy-поведения → x-bdd-knowledge-harvest

Core workflow

1. Собери продуктовый вход

Вход обычно состоит из PRD, аналитики, stakeholder prompt или уже существующего списка user stories. Технические детали на этом этапе не фиксируй в .feature.

2. Проведи бизнес-интервью по одной функции за раз

Для каждой user story:

• сформулируй Как / Я хочу / Чтобы
• зафиксируй happy path как первый сценарий
• уточни альтернативы, ограничения и отказы как отдельные сценарии
• определи тип проекта: monorepo, backend-only или frontend-only
• для monorepo определи каналы исполнения сценариев: API или browser

По каждой функции спроси:

• Что пользователь видит, если всё прошло хорошо?
• Что считается ошибкой ввода?
• Какие скрытые бизнес-правила влияют на исход?
• Какие пограничные случаи важны для бизнеса?
• Что должно произойти при отказе внешней системы?

3. Собери черновик .feature

• файл создаётся в features/NN_epic/NN_story.feature
• структура файла, naming и numbering берутся из x-bdd-api
• шаги пишутся на бизнес-языке
• технические решения не подмешиваются в сценарии
• в monorepo каждый Scenario получает один execution tag: @api или @browser; политику выбора канала задаёт x-bdd-api
• @api @browser не предлагай как обычный вариант: двойной тег допустим только как явно обоснованное исключение
• в backend-only/frontend-only execution tags не добавляй без отдельной причины

Минимальный шаблон драфта:

Feature: Вход пользователя

  Как зарегистрированный пользователь
  Я хочу войти по email и паролю
  Чтобы получить доступ к своему кабинету

  @browser
  Scenario: 01_successful_login_with_valid_credentials
    Given зарегистрирован пользователь "[e-mail]"
    When пользователь вводит корректный логин и пароль
    Then пользователь получает доступ к личному кабинету

Структуру имени файла и сценариев проверяй по x-bdd-api.

4. Проведи RFP с разработкой

Разработчики читают .feature и возвращают вопросы двух типов:

• продуктовые вопросы возвращаются в .feature
• технические вопросы уходят в ADR, doc.go или другой инженерный контракт

На RFP:

• собрать вопросы frontend/backend по готовому .feature
• для monorepo уточнить, какие сценарии исполняются через @api или @browser
• если бизнес хочет поставить два execution tags на один сценарий, сначала разделить intent или зафиксировать причину исключения
• продуктовые ответы внести в сценарии
• технические ответы увести в ADR, doc.go или другой инженерный документ

5. Передай feature в разработческий цикл

Файл готов для x-bdd-dev-workflow, когда:

• в нём закрыты продуктовые вопросы
• согласованы happy path и ключевые альтернативы
• naming и numbering проверены по x-bdd-api
• в monorepo у каждого сценария есть один execution tag или явно обоснованное исключение
• в backend-only/frontend-only execution tags не добавлены без отдельной причины

Короткий чек-лист

• есть ясный user story блок
• happy path выделен первым базовым сценарием
• альтернативы и edge cases вынесены в отдельные сценарии
• в шагах нет HTTP, SQL, JSON и других реализационных деталей
• открытые технические вопросы вынесены из .feature

Антипаттерны

• писать .feature раньше, чем понятна бизнес-цель
• смешивать несколько проверок в одном сценарии
• оставлять технические детали в шагах
• закрывать технические вопросы прямо в .feature
• использовать @ui или @ui-only вместо @browser
• добавлять execution tags в single-runner проект без причины

Смежные skills

• x-bdd-api
• x-bdd-browser
• x-bdd-dev-workflow
• x-bdd-knowledge-harvest
• x-doc-go