一键导入
test-driven-development
Use when fixing bugs or writing code in processing/, API/, statistics/, ML-infrastructure — write a failing test before fixing
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when fixing bugs or writing code in processing/, API/, statistics/, ML-infrastructure — write a failing test before fixing
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Используй, когда пользователь просит: «закрой этап», «создай отчёт этапа», «напиши отчёт», «синхронизируй report/changelog/handoff»
Используй по просьбе: «обнови документацию», «обнови документацию для <path>», «обнови MODULE_INDEX.md»
Use when working with the project wiki layer — new reports in docs/reports/ are not yet covered in wiki/index.md, a new concept needs to be saved, session needs wiki context, or pages may be stale
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when executing implementation plans with independent tasks in the current session
基于 SOC 职业分类
| name | test-driven-development |
| description | Use when fixing bugs or writing code in processing/, API/, statistics/, ML-infrastructure — write a failing test before fixing |
Обязательно (детерминированная логика с контрактом):
data_loader, feature builder, metric, benchmark runner, profile validationprocessing/, API/, statistics/, ML/-инфраструктура)Не применять (результат измеряется PF/AUC, не unit-тестом):
Для багфикса: тест должен падать на текущем коде, воспроизводя баг. Для новой функции: тест описывает ожидаемое поведение.
pytest tests/test_<module>.py -k "test_<specific_case>" -v
Тест должен упасть ровно по той причине, которую ты фиксишь (не по опечатке, не по импорту).
Пишешь минимальный код, чтобы тест прошёл. Без рефакторинга «заодно» (правило AGENTS.md: «для bugfix не делать рефакторинг "заодно"»).
pytest tests/test_<module>.py -k "test_<specific_case>" -v # должен пройти
pytest tests/ -x --tb=short # остальные не сломаны
После зелёного теста — убрать дублирование, улучшить имена. Без добавления нового поведения.
Оригинальный скилл требовал: «никакого кода без падающего теста». Это правило не применяется к ML/-экспериментам, где результат измеряется PF на validation/test, а не unit-тестом.
Для processing/API/statistics — дисциплина тестов обязательна как часть контракта docs/methodology/03-feature-contract-leakage.md и общей практики проекта (каталог tests/).
При написании тестов с моками (особенно для data_loader, валидаторов,
benchmark runner) — загружай справочник testing-anti-patterns.md:
5 паттернов с Python-примерами из проектной ML-инфраструктуры.