메뉴
Применяй на этапе планирования фичи: 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