Скил writing-plans — полные планы для инженеров без контекста кодовой базы
Как скил writing-plans структурирует планы реализации в виде небольших TDD-задач с точными путями к файлам, полным кодом и ожидаемым выводом команд — чтобы инженер без предварительного контекста мог выполнять план без догадок.
План реализации, в котором написано «добавьте подходящую обработку ошибок» или «напишите тесты для вышеизложенного», — это не план, а список решений, отложенных на исполнителя. Скил writing-plans определяет, как должны писаться планы: полный код в каждом шаге, точные пути к файлам, точные команды с ожидаемым выводом и никаких заглушек.
Целевая аудитория плана, написанного по этому скилу, — инженер, который является квалифицированным разработчиком, но почти ничего не знает о конкретной кодовой базе или предметной области. План содержит всё необходимое, включая дизайн тестов, потому что и это предположение нельзя считать само собой разумеющимся.
Структура файлов до задач
До любого списка задач план описывает файловую структуру: какие файлы будут созданы или изменены, и за что каждый из них отвечает. Здесь фиксируются решения о декомпозиции. Каждый файл должен иметь одну чёткую ответственность. Файлы, которые изменяются вместе, должны жить рядом — разделение происходит по ответственности, а не по техническому слою. В существующей кодовой базе план следует установленным паттернам, а не реструктурирует их в одностороннем порядке.
Если спецификация охватывает несколько независимых подсистем, которые не были разделены в процессе брейнсторминга, скил помечает это и предлагает разбить на отдельные планы. Каждый план должен производить работающее, тестируемое ПО самостоятельно.
Гранулярность небольших задач
Каждый шаг в задаче — это одно действие на две-пять минут: «написать падающий тест», «запустить его и убедиться, что он падает», «реализовать минимальный код, который заставит тест пройти», «запустить тесты», «сделать коммит». TDD-цикл red-green описывается не прозой — он показывается конкретными командами с ожидаемым выводом. Инженер, читающий задачи не по порядку, должен получить всё необходимое из самой задачи, поэтому повторяющийся контекст — это не избыточность, а требование.
Каждый план начинается с фиксированного заголовка: название фичи, цель в одном предложении, архитектура в двух-трёх предложениях и технологический стек. Агентные исполнители получают явную инструкцию в этом заголовке использовать скил subagent-driven-development или executing-plans для выполнения.
Самопроверка и передача
После написания полного плана скил требует прохода самопроверки с тремя проверками: покрытие спецификации (можно ли указать задачу для каждого требования?), поиск заглушек по запрещённым паттернам и согласованность типов (соответствуют ли сигнатуры методов в поздних задачах тому, что определено в ранних?). Найденные пробелы исправляются на месте — для коротких планов до пяти задач отдельный ревью-агент не нужен.
Планы для проектов под управлением Datarim сохраняются по пути datarim/plans/<TASK-ID>-plan.md. Для других проектов путь следует соглашениям проекта или предлагается и подтверждается до записи. После сохранения скил предлагает выбор варианта выполнения: субагентный (отдельный агент на каждую задачу с ревью между ними) или инлайн-выполнение с контрольными точками.
Общая картина — в посте что такое Datarim. О том, как прозаический контент проходит параллельный пайплайн, рассказывает пост о скиле writing.