菜单
Применяй для конвертации фрагментарных legacy-знаний (код, doc.go, docs/, git history, интервью) в структурированные .feature файлы
用 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.
Применяй на этапе планирования фичи: PRD → бизнес-интервью → драфт .feature → RFP разработке → разбор вопросов → готовые сценарии
Применяй при подключении, обновлении или кастомизации Ant Design во frontend: AntD v6, Tailwind CSS v4, cascade layers, scoped `.ant-*` overrides через `@layer components` и локальные Tailwind utilities в JSX
| name | x-bdd-knowledge-harvest |
| description | Применяй для конвертации фрагментарных legacy-знаний (код, doc.go, docs/, git history, интервью) в структурированные .feature файлы |
Этот skill — канонический владелец reverse-engineering потока: как извлекать бизнес-сценарии из существующего кода и документов.
Он не владеет layout/naming .feature и не владеет dev RGB-циклом. За это отвечают x-bdd-api и x-bdd-dev-workflow.
doc.go, docs/, git history и знаниями команды.Не применяй для:
x-bdd-product-workflowx-doc-gox-bdd-dev-workflowВыбери модуль, поток или пользовательскую задачу. Цель — восстановить бизнес-наблюдаемое поведение, а не переписать устройство системы.
Рекомендуемый порядок:
doc.go и публичные API*_test.godocs/ и другие текстовые артефактыdoc.go и публичные APIdoc.go; в .feature уходит только наблюдаемое поведениеПравило трансляции:
Arrange → GivenAct → WhenAssert → ThenПример:
func TestLogin_InvalidPassword(t *testing.T) {
user := createUser(t, "user@example.com", "correct")
_, err := service.Login(ctx, "user@example.com", "wrong")
require.ErrorIs(t, err, ErrInvalidCredentials)
}
Scenario: 02_reject_invalid_password
Given зарегистрирован пользователь "user@example.com"
When пользователь вводит "user@example.com" и неверный пароль
Then система отвечает ошибкой "неверные учётные данные"
docs/ и markdown-артефактыПолезные команды:
git log --grep="fix" --oneline --all
git show <sha>
git log --follow path/to/file.go
Спрашивай:
Arrange / Act / Assert из тестов превращаются в Given / When / Thenfeatures/NN_epic/NN_story.feature@api или @browser; политику выбора канала смотри в x-bdd-api@api по умолчанию@api @browser, фиксируй вопрос или разделяй intent вместо автоматического двойного тегаx-bdd-apix-bdd-product-workflowHarvest лучше завершать до крупного рефакторинга. Тогда полученный .feature становится контрактом текущего поведения, а дальнейшая реализация уходит в x-bdd-dev-workflow.
.feature каждый unit-тест подряд.feature готов к проверке по x-bdd-apix-bdd-apix-bdd-browserx-bdd-product-workflowx-bdd-dev-workflowx-doc-go