Скил subagent-driven-development — свежий контекст на каждую задачу

Когда агент выполняет длинный план реализации в одной сессии, контекст накапливается. Детали ранних задач смешиваются с поздними, и решения агента на пятой задаче испытывают влияние шума задач с первой по четвёртую. Скил subagent-driven-development решает это, назначая свежего изолированного агента на каждую задачу и передавая ему ровно тот контекст, который нужен, — и ничего больше.

Скил применяется при наличии готового плана реализации, когда задачи в этом плане в основном независимы друг от друга и среда выполнения поддерживает dispatch изолированных агентов. При этих условиях он превосходит инлайн-выполнение в одной сессии по качеству и скорости: по качеству — потому что каждый агент стартует чисто, по скорости — потому что контроллер не останавливается между задачами для отчётов о прогрессе.

Цикл выполнения одной задачи

Прежде чем что-то назначать, контроллер один раз читает полный файл плана, извлекает все задачи с полным текстом и окружающим контекстом, и формирует рабочий трекер. Это извлечение заранее — намеренное: агенты-реализаторы никогда не должны перечитывать файл плана самостоятельно, потому что прямая передача полного текста быстрее и исключает загрязнение контекста.

Каждая задача следует одному и тому же циклу. Агент-реализатор назначается с текстом задачи, контекстом для ориентирования и шаблоном промпта из ./implementer-prompt.md. Если реализатор задаёт вопросы до начала работы — это корректное поведение — контроллер отвечает на них, прежде чем разрешить приступать. Реализатор реализует, тестирует, проводит self-review и делает коммит. Затем назначается spec-compliance ревьюер. Только после подтверждения соответствия спецификации запускается code-quality ревьюер. Оба review должны пройти до отметки задачи как завершённой. Смена порядка — запуск code quality до spec compliance — явно указана в скиле как красный флаг.

Обработка статусов реализатора

Агенты-реализаторы возвращают один из четырёх статусов. DONE переходит к review. DONE_WITH_CONCERNS тоже переходит к review, но контроллер сначала читает замечания: замечания о корректности или скоупе устраняются до review, наблюдения о размере файла или стиле фиксируются и пропускаются дальше. NEEDS_CONTEXT означает, что контроллер предоставляет недостающую информацию и повторно назначает того же агента. BLOCKED требует, чтобы контроллер оценил блокер: если это проблема контекста — предоставить больше контекста; если проблема рассуждений — повторно назначить с более мощной моделью; если задача слишком велика — разбить её; если сам план неверен — эскалировать к человеку.

Скил явно запрещает игнорировать эскалацию или повторять попытку с той же моделью без изменений. Реализатор, сообщивший о блокировке, говорит правду.

Выбор модели

Скил определяет выбор модели по роли и сложности задачи, а не использует по умолчанию самую мощную модель везде. Механические задачи реализации — изолированные функции с полной спецификацией, затрагивающие один-два файла — используют самую дешёвую модель. Задачи интеграции, координирующие несколько файлов, используют стандартную модель. Задачи архитектуры, дизайна и review используют самую мощную из доступных. Это удерживает стоимость выполнения полного плана пропорциональной тому, что каждая задача реально требует.

Завершение плана

После того как все задачи отмечены завершёнными, агент финального code-review проходит по всей ветке реализации. Этот финальный проход выявляет межзадачные проблемы, которые пертасочные ревьюеры не могли увидеть изолированно: дрейф общих интерфейсов, непоследовательность в паттернах обработки ошибок или скоуп, который располз по нескольким задачам, не превысив порог ни одной из них. Затем ветка переходит к скилу finishing-a-development-branch.

Скил является одним из четырёх обязательных workflow-скилов. Он зависит от using-git-worktrees для изолированного рабочего пространства, от writing-plans для выполняемого плана и от requesting-code-review для шаблонов промптов ревьюеров. Когда среда выполнения не поддерживает dispatch изолированных агентов, запасной вариант — скил executing-plans, работающий инлайн в одном потоке.

Читайте что такое Datarim для понимания общего контекста пайплайна, или изучите скил stage-snapshot-writer, чтобы узнать, как чекпойнты сохраняются между этапами пайплайна, в которые ведёт этот скил.