القائمة
Применяй на этапе планирования фичи: PRD → бизнес-интервью → драфт .feature → RFP разработке → разбор вопросов → готовые сценарии
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Применяй при написании или правке API BDD через godog: общий каталог `features/`, теги `@api` в monorepo, layout API runner-а, TestMain, State, step definitions и testcontainers
Применяй при написании или правке browser BDD: `features/` Gherkin-сценарии, `@browser` в monorepo, playwright-bdd поверх Playwright Test, TypeScript steps, fixtures и page objects
Применяй при реализации функционала по готовому .feature: скелет шагов (red) → реализация до green → рефакторинг (blue)
Применяй при ревью или реализации BDD steps на godog или playwright-bdd, когда нужно выявить FAKE GREEN: stateful-заглушки, no-op шаги, self-fulfilling Then, локальную подстановку ошибок, When без observable effect и сценарии, которые проходят без проверки реальной реализации. Используй каждый раз при аудите BDD на честность, при переводе undefined/pending в green и в bdd-reviewer.
Применяй для конвертации фрагментарных legacy-знаний (код, doc.go, docs/, git history, интервью) в структурированные .feature файлы
Применяй при подключении, обновлении или кастомизации Ant Design во frontend: AntD v6, Tailwind CSS v4, cascade layers, scoped `.ant-*` overrides через `@layer components` и локальные Tailwind utilities в JSX
| name | x-bdd-product-workflow |
| description | Применяй на этапе планирования фичи: PRD → бизнес-интервью → драфт .feature → RFP разработке → разбор вопросов → готовые сценарии |
Этот skill — канонический владелец продуктового пути от требований к готовому .feature.
Он не владеет layout, naming и numbering BDD-файлов. За это отвечает x-bdd-api.
.feature после интервью со стейкхолдерами.Не применяй для:
.feature → x-bdd-apix-bdd-dev-workflowx-bdd-knowledge-harvestВход обычно состоит из PRD, аналитики, stakeholder prompt или уже существующего списка user stories. Технические детали на этом этапе не фиксируй в .feature.
Для каждой user story:
Как / Я хочу / ЧтобыПо каждой функции спроси:
.featurefeatures/NN_epic/NN_story.featurex-bdd-apiScenario получает один execution tag: @api или @browser; политику выбора канала задаёт x-bdd-api@api @browser не предлагай как обычный вариант: двойной тег допустим только как явно обоснованное исключениеМинимальный шаблон драфта:
Feature: Вход пользователя
Как зарегистрированный пользователь
Я хочу войти по email и паролю
Чтобы получить доступ к своему кабинету
@browser
Scenario: 01_successful_login_with_valid_credentials
Given зарегистрирован пользователь "user@example.com"
When пользователь вводит корректный логин и пароль
Then пользователь получает доступ к личному кабинету
Структуру имени файла и сценариев проверяй по x-bdd-api.
Разработчики читают .feature и возвращают вопросы двух типов:
.featuredoc.go или другой инженерный контрактНа RFP:
.feature@api или @browserdoc.go или другой инженерный документФайл готов для x-bdd-dev-workflow, когда:
x-bdd-api.feature.feature раньше, чем понятна бизнес-цель.feature@ui или @ui-only вместо @browserx-bdd-apix-bdd-browserx-bdd-dev-workflowx-bdd-knowledge-harvestx-doc-go