القائمة
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-инфраструктуры.