Task decomposer

Task Decomposer

Разбивает крупную задачу на куски правильного «агентского» размера. Неправильный размер куска — главная причина плохой работы агента: слишком крупно — агент молча принимает архитектурные решения, дрейфует от цели и ломает много сразу; слишком мелко — пользователь тонет в микроменеджменте.

Критерий агентского куска

Кусок имеет правильный размер, если проходит тест одного захода — все пять пунктов:

1. Один заход — выполняется в одной сессии без смены направления посередине.
2. Проверяемый результат — по завершении можно объективно ответить «готово или нет»: тесты зелёные, команда отрабатывает, элемент виден на странице. «Стало лучше» — не результат.
3. Зелёный финал — проект в конце куска компилируется, тесты проходят, состояние коммитабельно. Никаких кусков, оставляющих проект сломанным «до следующего шага».
4. Нет развилок внутри — все решения, требующие мнения пользователя, приняты ДО куска. Если внутри прячется «а тут посмотрим» — это два куска и точка контроля между ними.
5. Ограниченная область — заранее понятно, какие файлы/модули затрагиваются. «Пройтись по всему проекту» — не кусок, а серия кусков.

Порядок работы

Шаг 1. Конечный результат — одним предложением. Сформулируй, что будет по завершении всей задачи, в проверяемых терминах. Если не получается — сначала уточни у пользователя, это дешевле пяти неправильных кусков.

Шаг 2. Выдели неизвестности → разведка отдельно. Всё, что нужно узнать (как устроен модуль X, где живут данные Y, какая библиотека уже есть), — отдельные read-only recon-куски В НАЧАЛЕ плана. Разведка никогда не смешивается с изменениями: агент, который одновременно изучает и правит, изучает плохо и правит наугад.

Шаг 3. Режь по швам, вертикальными срезами. Предпочитай срез «узкая фича целиком» (модель → логика → интерфейс для одного сценария) слою «все модели, потом вся логика»: срез даёт проверяемый результат, слой — нет. Типовые швы: за данные / за логику / за отображение; по сценарию пользователя; по модулю; «сначала расширить, потом переключить, потом удалить старое» (expand/contract).

Шаг 4. Карточка на каждый кусок:

### N. [Название куска в 3-5 слов]
- Цель: [что появится/изменится]
- Область: [файлы/модули; что НЕ трогать]
- DoD: [объективный критерий готовности]
- Проверка: [команда/действие, которым агент докажет DoD]
- Зависит от: [номера кусков или «—»]

Шаг 5. Упорядочи. Правила порядка:

• рискованное и неясное — вперёд (провалиться дёшево лучше рано);
• разведка → скелет → мясо → полировка;
• после кусков с необратимыми или дорогими последствиями (миграции БД, удаление кода, внешние API) — точка контроля: пользователь смотрит перед продолжением;
• зависимости — только назад по списку, циклов нет.

Шаг 6. Самопроверка плана:

• Каждый кусок проходит тест одного захода (5 пунктов)?
• Разведка отделена от изменений?
• После каждого куска проект в зелёном состоянии?
• Отмечены точки контроля после рискованных кусков?
• Кусков ≤ 8? Если больше — задача уровня спеки: сначала spec-writer (режим plan), потом декомпозиция первой фазы.

Выход

Markdown-план с чек-боксами и карточками кусков. Пиши его в файл (например, PLAN.md или файл задачи в трекере пользователя), а не только в диалог — план переживёт компактификацию контекста и смену сессии. Каждая карточка сформулирована так, чтобы работать готовым промтом для нового захода; если пользователь просит развернуть карточку в полный промт — применяй clarify-prompt.

Исполнение

• 1–3 куска — выполняй в текущей сессии, по одному, с проверкой DoD после каждого.
• 4+ кусков или работа на несколько сессий — новая сессия на кусок (план в файле — точка синхронизации) либо передай план в goal-pipeline для автономного прогона с гейтами.
• Кусок забуксовал (агент ходит кругами, правки разрастаются) — стоп; это сигнал, что кусок был велик: вернись сюда и разрежь его.

Границы навыка

Формулировка одного куска как чистого промта — clarify-prompt. Документ-план с оценками и рисками — spec-writer. Автономное исполнение фаз — goal-pipeline. Оптимизация одной метрики циклом — ratchet-loop. План коммитов по уже сделанным изменениям — git-commit-planner.