Subagent-Driven Development

Выполнение плана через запуск отдельного подагента-исполнителя на каждую задачу, ревью после каждой задачи (соответствие спецификации + качество кода) и широкое ревью всей ветки в конце.

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

Ключевой принцип: Свежий подагент на каждую задачу + ревью задачи (спецификация + качество) + широкое финальное ревью = высокое качество, быстрая итерация

Непрерывное выполнение: Не останавливайтесь для проверки с партнёром между задачами. Единственные причины остановиться: статус BLOCKED, реальная неоднозначность или завершение всех задач.

Когда использовать

• Есть план реализации
• Задачи в основном независимы
• Выполнение в текущей сессии

Vs. Executing Plans (параллельные сессии): та же сессия · свежий подагент на задачу · автоматические контрольные точки ревью · быстрая итерация без ожидания

Процесс

Подготовка

1. Прочитать план, записать контекст и глобальные ограничения, создать задачи
2. Предварительный обзор плана на конфликты — задачи, противоречащие друг другу или ограничениям плана. Все находки — одним батч-вопросом до начала выполнения

На каждую задачу

1. Запустить scripts/task-brief PLAN_FILE N → получить путь к файлу брифа
2. Отправить подагента-исполнителя (по шаблону implementer-prompt.md)
3. Ответить на вопросы исполнителя (если есть)
4. Получить отчёт исполнителя со статусом
5. Запустить scripts/review-package BASE HEAD → получить путь к файлу
6. Отправить подагента-ревьюера задачи (по шаблону task-reviewer-prompt.md)
7. Если ревьюер нашёл Critical/Important — отправить подагента-исправителя, повторить ревью
8. Отметить задачу завершённой в списке задач и журнале прогресса

После всех задач

1. Запустить scripts/review-package MERGE_BASE HEAD
2. Отправить финального ревьюера всей ветки
3. Использовать superpowers:finishing-a-development-branch

Выбор модели

Используйте наименее мощную модель, способную справиться с ролью.

Всегда указывайте модель явно при отправке подагента. Пропущенная модель наследует модель сессии — часто самую мощную и дорогую.

Количество шагов важнее цены токена. Дешёвые модели делают в 2–3× больше шагов на многоэтапных задачах — итоговая стоимость выше.

Обработка статусов исполнителя

• DONE: Сгенерировать пакет ревью, отправить ревьюера задачи
• DONE_WITH_CONCERNS: Прочитать замечания до продолжения. Если они о корректности — устранить до ревью
• NEEDS_CONTEXT: Предоставить недостающий контекст, повторно отправить
• BLOCKED: Оценить блокировку: добавить контекст / повысить модель / разбить задачу / эскалировать к человеку

Никогда не игнорируйте эскалацию и не перезапускайте ту же модель без изменений.

Обработка пунктов ⚠️ ревьюера

Ревьюер задачи может отметить «⚠️ Cannot verify from diff» — требования в неизменённом коде. Вы должны разрешить каждый такой пункт самостоятельно до отметки задачи завершённой. Если подтверждаете реальный пробел — вернуть исполнителю.

Составление промптов для ревьюеров

• Не добавляйте открытые директивы без конкретной причины
• Не просите ревьюера перезапускать тесты, которые исполнитель уже запустил
• Не предрешайте находки — никогда не инструктируйте «не помечать» или «игнорировать» конкретную проблему
• Блок глобальных ограничений — это линза внимания ревьюера: копируйте требования дословно
• Передавайте дифф как файл: scripts/review-package BASE HEAD
• Промпт отправки описывает одну задачу, а не историю сессии
• Для Critical и Important — отправляйте подагентов-исправителей; Minor — записывайте в журнал
• Каждый промпт исправления содержит контракт: подагент повторно запускает покрывающие тесты и сообщает результаты
• После финального ревью — один подагент-исправитель для всех находок, не по одному на каждую

Передача файлов

Всё, что вставляется в промпт отправки, остаётся в вашем контексте на всю сессию. Передавайте артефакты как файлы:

• Бриф задачи: scripts/task-brief PLAN_FILE N → уникальный файл с полным текстом задачи
• Файл отчёта: имя по образцу брифа (task-N-brief.md → task-N-report.md). Исполнитель пишет отчёт туда, возвращает только статус, коммиты и краткое резюме тестов
• Входные данные ревьюера: три пути — бриф, отчёт, пакет ревью + глобальные ограничения

Постоянный прогресс

Память разговора не переживает компакцию. Отслеживайте прогресс в файле-журнале, а не только в задачах.

• При старте скилла проверить журнал: cat "$(git rev-parse --show-toplevel)/.superpowers/sdd/progress.md". Задачи, отмеченные как complete — ВЫПОЛНЕНЫ, не перезапускайте их
• После чистого ревью задачи добавлять строку: Task N: complete (commits <base7>..<head7>, review clean)
• Журнал — ваша карта восстановления: после компакции доверяйте журналу и git log, а не своим воспоминаниям

Шаблоны промптов

• implementer-prompt.md — отправка подагента-исполнителя
• task-reviewer-prompt.md — отправка ревьюера задачи
• Финальное ревью ветки: superpowers:requesting-code-review / code-reviewer.md

Запрещено

• Начинать реализацию в ветке main/master без явного согласия пользователя
• Пропускать ревью задачи или принимать отчёт без обоих вердиктов (соответствие спецификации И качество задачи)
• Продолжать с неисправленными проблемами
• Запускать несколько подагентов-исполнителей параллельно
• Давать подагенту читать весь файл плана (передавайте бриф через scripts/task-brief)
• Не отвечать на вопросы подагента или спешить его к реализации
• Говорить ревьюеру, что не помечать, или заранее оценивать серьёзность находки
• Отправлять ревьюера задачи без файла диффа
• Переходить к следующей задаче при открытых Critical/Important проблемах
• Повторно отправлять задачу, которую журнал прогресса уже помечает завершённой

Интеграция

Необходимые скиллы рабочего процесса:

• superpowers:using-git-worktrees — изолированное рабочее пространство
• superpowers:writing-plans — создание плана для выполнения этим скиллом
• superpowers:requesting-code-review — шаблон финального ревью ветки
• superpowers:finishing-a-development-branch — завершение разработки после всех задач

Подагенты должны использовать: superpowers:test-driven-development

Альтернатива: superpowers:executing-plans — для параллельной сессии вместо выполнения в той же сессии