Публикую свой скилл TDD — он помогает кодить без багов, потому что заставляет агента писать тесты по-честному

Метод программирования TDD придумал Кент Бек в конце 1990-х, и с тех пор он считается одной из самых надёжных инженерных практик. Идея в том, чтобы сначала писать тест, потом код. Метод отлично подходит автономным агентам — тесты становятся объективным доказательством, что код делает то, что нужно. Но есть ловушка

Коротко, метод работает так: красный тест → зелёный код → рефакторинг. Тесты обязаны упасть до того, как написан код. Но, если просто поручить агенту «работай по TDD», он будет генерировать тесты, подогнанные под код, потому что генерирует их в одном окне контекста. Bias будет неизбежно толкать его мухлевать, как ни уговаривай. Баги такие тесты ловят плохо, потому что написаны уже зная реализацию

Мой скил написан так, чтобы надёжно изолировать написание тестов, кода и рефакторинг. Агент-тестировщик не видит код. Агент-разработчик видит тесты, но не может их менять — и не знает, из какого ТЗ они выросли

Ещё я встроил «детектор противоречий». Если ТЗ содержит правила, которые противоречат друг другу, скилл останавливается и говорит об этом, а не молча кодирует баг

Я писал и итеративно улучшал этот скил последние два месяца в рамках практики «затачивания инструмента». Сейчас он уже в версии 2.0. Получился офигенный тул, который мой Клод использует каждый день — на всех задачах, где пишется новый функционал. А я — кайфую

Пример такого улучшения. Я решил проверить справедливость собственных ощущений о том, что скилл работает. Собрал эвал — набор заранее заготовленных заданий, где правильный ответ известен. Типа как краш-тест для машины. Среди заданий было одно намеренно отравленное — с правилом доступа, которое тихо противоречило собственному описанию. Первая версия скилла невозмутимо выдала 19 зелёных тестов поверх настоящей дыры: гейт пустил бы неоплатившего юзера туда, куда ему нельзя. Вторая версия увидела противоречие в самом ТЗ и остановилась. Без эвала я бы считал, что первая версия работает — она ведь выглядела убедительно

Сейчас с этим скилом я запускаю объёмные задачи на многие часы, и результат регулярно меня удивляет. Свежий пример: я поручил Клоду написать версию Букова под Андроид на основе кода и документации iOS и веб приложений. Он работал несколько вечеров почти фоном (я иногда давал какие-то разрешения или говорил go ahead) и выдал приложение с основными функциями — каждая покрыта тестами, каждая проверена автоматически. Дизайн я сознательно вынес в отдельную итерацию, но функционально всё работает именно потому, что TDD-цикл не дал агенту срезать углы. Без этого скилла приложение тоже было бы написано, но с кучей багов и многие функции просто не работали бы

Писать и обновлять фичи внутри существующих продуктов тоже лучше с этим скилом — без тестов агент легко ломает соседний код, и ты узнаёшь об этом только когда пользователь напишет

Чтобы установить себе, дайте агенту ссылку на репозиторий и попросите установить скилл в систему (опционально: и адаптировать под ваши проекты). Он написан для Claude Code, но любой другой агент легко адаптирует его под себя

github.com/kirillgreen/skills/tree/main/tdd