Обзор

Диспетчеризуй свежие subagent на каждую задачу с двухэтапным ревью (соответствие спецификации, затем качество кода) в текущей сессии.

Изолирует каждую задачу в выделенный subagent с точно сформированным контекстом, предотвращая загрязнение контекста и удерживая контроллер в фокусе координации
Обеспечивает двухэтапный цикл ревью: reviewer соответствия спецификации подтверждает, что реализация соответствует требованиям, затем reviewer качества кода проверяет наличие проблем
Обрабатывает статусные сигналы implementer (DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, BLOCKED) с соответствующей логикой эскалации или повторной диспетчеризации
Рекомендует выбор модели по сложности задачи: дешёвые модели для механических задач в 1–2 файла, стандартные модели для многофайловых интеграций, наиболее мощные модели для архитектуры и ревью
Требует предварительной настройки git worktree и интегрируется с test-driven development и superpowers finishing-a-development-branch

Разработка через subagent

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

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

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

Нарратив: между вызовами инструментов повествуй не более одной короткой строки — реестр и результаты инструментов несут запись.

Непрерывное выполнение: Не делай пауз для уточнений у своего human partner между задачами. Выполни все задачи из плана без остановки. Единственные причины для остановки — четыре названные ниже, или завершение всех задач. Промпты вроде «Стоит ли продолжать?» и сводки прогресса тратят их время — они попросили тебя выполнить план, так что выполняй его.

Решения, а не остановки. Выполняющийся план не ждёт human. Конфликты, неоднозначности, дефекты плана, ограничение, которое ты хотел бы превысить — реши их. Спецификация является обязательной властью, план — её аргументом, и твоё суждение разрешает то, на что ни то, ни другое не отвечает. Запиши каждое решение в реестр в формате Ruling: <что ты решил> — <почему> — <сколько это стоит, если ошибся> и продолжай работать. Ошибочное решение стоит переделки, которую твой human partner может увидеть и отменить; сессия, застрявшая на вопросе, стоит ему целого дня и ничего не приносит.

Четыре вещи останавливают тебя, и только они: необратимая или деструктивная операция; действие, чувствительное к безопасности; побочный эффект вне этого worktree, который по нормам требует предварительного согласования (merge, push в общую ветку, публикация); и настолько сломанный план, что каждый шаг вперёд — это угадывание. В этих случаях остановись и спроси.

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

digraph when_to_use {
    "Have implementation plan?" [shape=diamond];
    "Tasks mostly independent?" [shape=diamond];
    "Partner chose inline, or no subagent tool?" [shape=diamond];
    "subagent-driven-development" [shape=box];
    "executing-plans" [shape=box];
    "Manual execution or brainstorm first" [shape=box];

    "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
    "Tasks mostly independent?" -> "Partner chose inline, or no subagent tool?" [label="yes"];
    "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
    "Partner chose inline, or no subagent tool?" -> "executing-plans" [label="yes"];
    "Partner chose inline, or no subagent tool?" -> "subagent-driven-development" [label="no"];
}

Против Executing Plans (inline):

Свежий subagent на каждую задачу (без загрязнения контекста) вместо одного контекста, выполняющего все задачи
Ревью после каждой задачи (соответствие спецификации + качество кода) вместо только в конце
Стоимость: свежий контекст на каждую задачу и на каждое ревью; inline стоит один контекст плюс один финальный reviewer
Оба варианта работают в этой сессии, разделяют одно и то же рабочее пространство плана и реестр, и никогда не делают пауз между задачами

Процесс

digraph process {
    rankdir=TB;

    subgraph cluster_per_task {
        label="Per Task";
        "Dispatch implementer subagent (./implementer-prompt.md)" [shape=box];
        "Implementer asks questions?" [shape=diamond];
        "Answer questions, provide context" [shape=box];
        "Implementer implements, tests, commits, self-reviews" [shape=box];
        "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" [shape=box];
        "Spec ✅ and quality approved?" [shape=diamond];
        "Finding conflicts with plan text?" [shape=diamond];
        "Rule on the conflict, ledger the ruling" [shape=box];
        "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [shape=box];
        "Dispatch scoped re-review (./re-review-prompt.md)" [shape=box];
        "All findings addressed?" [shape=diamond];
        "R = 5?" [shape=diamond];
        "Adjudicate each open finding" [shape=box];
        "Any load-bearing finding?" [shape=diamond];
        "Rule and continue; stop only if every path forward is a guess" [shape=box];
        "Park findings in ledger with rulings" [shape=box];
        "Append completion to ledger, mark todo complete" [shape=box];
    }

    "Setup: worktree, ledger check, read plan, pre-flight review" [shape=box];
    "More tasks remain?" [shape=diamond];
    "Dispatch final code reviewer (../requesting-code-review/code-reviewer.md)" [shape=box];
    "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals" [shape=box];
    "Final review clean: delete this plan's workspace" [shape=box];
    "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];

    "Setup: worktree, ledger check, read plan, pre-flight review" -> "Dispatch implementer subagent (./implementer-prompt.md)";
    "Dispatch implementer subagent (./implementer-prompt.md)" -> "Implementer asks questions?";
    "Implementer asks questions?" -> "Answer questions, provide context" [label="yes"];
    "Answer questions, provide context" -> "Implementer implements, tests, commits, self-reviews";
    "Implementer asks questions?" -> "Implementer implements, tests, commits, self-reviews" [label="no"];
    "Implementer implements, tests, commits, self-reviews" -> "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)";
    "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" -> "Spec ✅ and quality approved?";
    "Spec ✅ and quality approved?" -> "Append completion to ledger, mark todo complete" [label="yes"];
    "Spec ✅ and quality approved?" -> "Finding conflicts with plan text?" [label="no"];
    "Finding conflicts with plan text?" -> "Rule on the conflict, ledger the ruling" [label="yes"];
    "Rule on the conflict, ledger the ruling" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model";
    "Finding conflicts with plan text?" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [label="no"];
    "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" -> "Dispatch scoped re-review (./re-review-prompt.md)";
    "Dispatch scoped re-review (./re-review-prompt.md)" -> "All findings addressed?";
    "All findings addressed?" -> "Append completion to ledger, mark todo complete" [label="yes"];
    "All findings addressed?" -> "R = 5?" [label="no"];
    "R = 5?" -> "Fix round R of 5: R≤3 resume implementer; R≥4 fresh implementer, more capable model" [label="no - next round"];
    "R = 5?" -> "Adjudicate each open finding" [label="yes - breaker trips"];
    "Adjudicate each open finding" -> "Any load-bearing finding?";
    "Any load-bearing finding?" -> "Rule and continue; stop only if every path forward is a guess" [label="yes"];
    "Any load-bearing finding?" -> "Park findings in ledger with rulings" [label="no"];
    "Park findings in ledger with rulings" -> "Append completion to ledger, mark todo complete";
    "Append completion to ledger, mark todo complete" -> "More tasks remain?";
    "More tasks remain?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="yes"];
    "More tasks remain?" -> "Dispatch final code reviewer (../requesting-code-review/code-reviewer.md)" [label="no"];
    "Dispatch final code reviewer (../requesting-code-review/code-reviewer.md)" -> "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals";
    "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals" -> "Final review clean: delete this plan's workspace";
    "Final review clean: delete this plan's workspace" -> "Use superpowers:finishing-a-development-branch";
}

Настройка

Обеспечь работу в изолированном рабочем пространстве: используй superpowers:using-git-worktrees для создания нового или проверки существующего. Никогда не начинай реализацию на ветке main/master без явного согласия твоего human partner.

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

Каждый план владеет рабочим пространством: при запуске skill выполни bash scripts/sdd-workspace PLAN_FILE этого skill — он выведет git-игнорируемую директорию плана (под <repo-root>/.superpowers/sdd/), в которой размещаются все артефакты ЭТОГО плана: реестр, брифы, отчёты, пакеты ревью. Директория другого плана никогда не подлежит чтению или записи для тебя.
Проверь наличие реестра этого плана по пути <workspace>/progress.md. Если его первая строка называет файл твоего плана, задачи со строкой Task <N>: complete — выполнены — не диспетчеризуй их повторно; возобнови с первой задачи без такой строки. Задача, чья последняя строка — раунд исправления, находится в середине цикла: возобнови цикл со следующего раунда. Реестр, первая строка которого называет другой файл плана — или брошенный реестр по старому плоскому пути .superpowers/sdd/progress.md — относится к прогрессу другого плана: оставь его на месте и начни свой собственный, с нуля.
Создай реестр с его идентичностью первой строкой: # SDD ledger — plan: <путь к файлу плана>.
Реестр — это твоя карта восстановления: коммиты, которые он называет, существуют в git, даже когда твой контекст больше не помнит их создания. После компактизации доверяй реестру и git log, а не своему воспоминанию.
git clean -fdx уничтожит рабочее пространство (это git-игнорируемый scratch); если это произойдёт, восстановись из git log.

Прочитай план один раз, отметь его контекст и Global Constraints и создай todo на каждую задачу. Если план называет Spec, прочитай и её: спецификация — это власть, от которой аргументируется план, и конфликты внутри плана разрешаются в её пользу. План с недостижимой спецификацией получает пометку в реестре об этом — решения, принятые без неё, являются предварительными.

Перед диспетчеризацией Task 1 просканируй план один раз на конфликты, записывая то, что ты проверил, по мере проверки:

задачи, противоречащие друг другу или Global Constraints плана
всё, что план явно предписывает, но review rubric считает дефектом (тест, который ничего не проверяет, дословная дубликация логического блока)

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

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

Выбор модели

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

Механические задачи реализации (изолированные функции, чёткие спецификации, 1–2 файла): используйте быструю недорогую модель. Большинство задач реализации являются механическими, когда план достаточно детально прописан.

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

Задачи архитектуры и проектирования: используйте самую мощную доступную модель. Итоговое обзор всего ветвления — одна из таких задач, направляйте её на самую мощную доступную модель, а не на модель по умолчанию для сессии.

Задачи обзора: выбирайте модель с таким же уровнем суждения, масштабируя её по размеру, сложности и риску diff. Небольшой механический diff не требует самой мощной модели; тонкое изменение конкурентности — требует. Область ограниченные повторные обзоры небольших diff-исправлений выполняйте на моделях низкого-среднего уровня.

Эскалация в цикле исправлений (раунды 4–5): используйте модель хотя бы на один уровень выше той, которая застряла на этапе реализации.

Всегда указывайте модель явно при отправке subagent. Опущенная модель наследует модель вашей сессии — часто самую мощную и дорогую, что тихо сводит на нет этот раздел.

Количество ходов важнее цены за токен. Время работы и стоимость контекста растут с количеством ходов, которые делает subagent, а самые дешевые модели регулярно требуют в 2–3 раза больше ходов на многошаговых задачах — в итоге дороже. Используйте модель среднего уровня как минимум для обозревателей и для реализаторов, работающих по текстовым описаниям. Когда в тексте плана задачи содержится полный код для написания, реализация сводится к транскрибированию и тестированию: используйте для такого реализатора самый дешёвый уровень. Механические исправления в одном файле тоже выполняйте на самом дешёвом уровне.

Сигналы сложности задачи (задачи реализации):

Затрагивает 1–2 файла с полной спецификацией → дешёвая модель
Затрагивает несколько файлов со смежными задачами интеграции → стандартная модель
Требует инженерного суждения или широкого понимания кодовой базы → самая мощная модель

Цикл задач

Группируйте мелкие однородные работы. Когда в плане перечислено несколько задач, каждая из которых представляет собой небольшую независимую правку одного типа — одно и то же исправление одной строки, изменение константы или добавление поля, повторяющееся в разных файлах, — не отправляйте по одному subagent на задачу. Составьте ОДНУ заявку на отправку, перечисляющую каждый файл и его изменение, отправьте всю группу одному subagent и проверьте его diff как единое целое. Отправку по одной задаче оставляйте для работ, требующих собственного суждения, собственных тестов или собственного обзора.

Всё, что вы вставляете в prompt отправки, — и всё, что subagent выводит обратно, — остаётся в вашем контексте до конца сессии и перечитывается на каждом следующем ходу. Передавайте артефакты в виде файлов.

Ожидание отправленных subagent: никогда не опрашивайте интерфейс ожидания с короткими тайм-аутами и не сидите в одном молчаливом бесконечном ожидании. Пока у вас есть локальная работа — обновление журнала, упаковка следующего обзора, чтение отчётов — продолжайте работать; результаты дочерних задач приходят сами. Когда вы действительно без дела, ждите ограниченными отрезками (от пяти до десяти минут, если платформа позволяет), а между отрезками публикуйте одну строку статуса и сверяйте свои активные дочерние задачи: перечислите их и проверьте те, которые завершились без отчёта. Ограниченный отрезок сохраняет почти всю эффективность длительного ожидания, но гарантирует, что застрявшая или потерянная задача будет замечена в течение минут, а не в конце сессии.

1. Отправка реализатора

Запишите BASE (git rev-parse HEAD) перед отправкой — она понадобится для пакета обзора и diff-исправлений.

Задача-бриф: перед отправкой реализатора выполните bash scripts/task-brief PLAN_FILE N из этого skills — он извлекает полный текст задачи в файл с уникальным именем и выводит путь. Составьте отправку так, чтобы бриф оставался единым источником требований. Ваша отправка должна содержать: (1) одну строку о том, где эта задача вписывается в проект; (2) путь к брифу, представленный как «прочитайте сначала это — это ваши требования, со значениями, которые нужно использовать дословно»; (3) интерфейсы и решения из более ранних задач, о которых бриф не может знать; (4) ваше разрешение любой двусмысленности, которую вы заметили в брифе; (5) путь к файлу отчёта и контракт отчёта. Точные значения (числа, магические строки, сигнатуры, тестовые случаи) появляются только в брифе. Никогда не заставляйте subagent читать весь файл плана.
Файл отчёта: назовите файл отчёта реализатора по имени брифа (бриф …/task-N-brief.md → отчёт …/task-N-report.md) и укажите его в prompt отправки. Реализатор пишет полный отчёт туда и возвращает только статус, коммиты, одну строку резюме тестов и сомнения.
Prompt отправки описывает одну задачу, а не историю сессии. Не вставляйте накопленные сводки прошлых задач («состояние после Задач 1–3») в последующие отправки — в реальной сессии prompt отправки достиг 42k символов, из которых 99% была вставленной историей. Свежему subagent нужны его задача, интерфейсы, которые он затрагивает, и глобальные ограничения. Ничего больше.
Отправка несёт контракт «без subagent» (он находится в шаблоне реализатора): реализатор никогда не отправляет subagent — ни помощников, ни обозревателя. Обзор приходит от вас, после отчёта. В реальных сессиях каждый обозреватель, которого порождал работник, дублировал обзор задачи, который и так отправил контроллер, — полноценное дополнительное место обозревателя на каждую задачу.
Если более ранняя задача отложила находку в область, которую затрагивает эта задача, включите в отправку ссылку на эту запись журнала.
Запишите идентификатор agent реализатора из результата отправки — раунды 1–3 цикла исправлений продолжают эту agent.
Никогда не отправляйте несколько subagent-реализаторов параллельно (конфликты).

Шаблон: implementer-prompt.md

2. Обработка отчёта

Subagent-реализаторы отчитываются о одном из четырёх статусов. Обрабатывайте каждый соответствующим образом:

DONE: Сгенерируйте пакет обзора (bash scripts/review-package PLAN_FILE BASE HEAD из директории этого skills — он выводит уникальный путь записанного файла; BASE — коммит, записанный вами перед отправкой реализатора, никогда не HEAD~1, который тихо отбрасывает все коммиты, кроме последнего, в многокоммитной задаче), затем отправьте обозревателю задачи с выведенным путём.

DONE_WITH_CONCERNS: Реализатор завершил работу, но выразил сомнения. Прочитайте их перед продолжением. Если сомнения касаются корректности или области, устраните их до обзора. Если это наблюдения (например, «этот файл разрастается»), отметьте их и переходите к обзору.

NEEDS_CONTEXT: Реализатору нужна информация, которая не была предоставлена. Предоставьте недостающий контекст и отправьте повторно.

BLOCKED: Реализатор не может завершить задачу. Оцените причину:

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

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

Если реализатор задаёт вопросы — до начала или в середине задачи — отвечайте ясно и полно, предоставьте дополнительный контекст при необходимости и не торопите его приступать к реализации.

3. Обзор задачи

Обзоры отдельных задач — это областные контрольные точки задачи. Широкий обзор выполняется один раз, при итоговом обзоре всей ветвления. Никогда не пропускайте обзор задачи и никогда не принимайте отчёт без хотя бы одного вердикта — и соответствие спецификации, и качество задачи обязательны. Самообзор реализатора никогда не заменяет обзор задачи; нужны оба.

Передавайте обозревателю его diff в виде файла: выполните bash scripts/review-package PLAN_FILE BASE HEAD из этого skills и передайте обозревателю выводимый им путь к файлу (или, без bash: git log --oneline, git diff --stat и git diff -U10 для диапазона, перенаправленные в файл с уникальным именем). Вывод никогда не попадает в ваш собственный контекст, а обозреватель видит список коммитов, сводку статистики и полный diff с контекстом одним вызовом Read. Используйте BASE, записанный перед отправкой реализатора, — никогда не HEAD~1, который тихо обрезает многокоммитные задачи. Никогда не отправляйте обозревателю задачи без файла diff.
Входы обозревателя: обозреватель задачи получает три пути — тот же файл брифа, файл отчёта и пакет обзора, — плюс глобальные ограничения, связывающие задачу.
Блок глобальных ограничений, который вы передаёте обозревателю, — это его линза внимания. Скопируйте обязательные требования дословно из раздела «Глобальные ограничения» плана или из спецификации: точные значения, точные форматы и указанные связи между компонентами («такой же макет, как у X», «соответствует Y»). Шаблон обозревателя уже содержит правила процесса (YAGNI, гигиена тестов, метод обзора) — блок ограничений нужен для того, что требует спецификация ЭТОГО проекта.
Не добавляйте открытые директивы вроде «проверьте все использования» или «запустите тесты на гонки, если полезно» без конкретной, специфической для задачи причины
Не просите обозревателя перезапускать тесты, которые реализатор уже запускал на том же коде, — отчёт реализатора содержит доказательства тестов
Не предрешайте находки за обозревателя — никогда не указывайте обозревателю игнорировать или не отмечать конкретную проблему. Если вы считаете, что находка будет ложным срабатыванием, дайте обозревателю поднять её и разрешить в цикле обзора. Если в написаемом prompt есть фразы «не отмечайте», «не считайте X дефектом», «не более Minor» или «план выбрал» — остановитесь: вы предрешаете, обычно чтобы избежать цикла обзора. Обозреватель задачи может сообщать об элементах «⚠️ Cannot verify from diff» — требованиях, которые живут в неизменённом коде или захватывают несколько задач. Они не блокируют остальной обзор, но вы должны разрешить каждый из них самостоятельно, прежде чем отмечать задачу как завершённую: у вас есть план и межзадачный контекст, которых не хватает обозревателю. Если вы подтверждаете, что элемент — реальный пробел, обработайте его как неудачный обзор спецификации — он входит в цикл исправлений вместе с другими находками.

Шаблон: task-reviewer-prompt.md

4. Цикл исправлений

Цикл запускается, когда ревью возвращает вердикт spec ❌, любую находку уровня Critical или Important, или пункт ⚠️, который вы подтвердили как реальный пробел.

Прежде чем цикл начнётся, два случая выходят из него сразу:

Записывайте находки уровня Minor в журнал прогресса по мере работы (Task <N>: minor (deferred): <однострочник>) и укажите этот список в итоговом ревью всей ветки, чтобы оно могло распределить, что нужно исправить перед слиянием. Сводку, которую никто не читает, — это тихая утилизация. Находки уровня Minor никогда не входят в цикл.
Находка с меткой «требуется по плану» — или любая находка, противоречащая тому, чего требует текст плана, — под ваше решение: сопоставьте находку с текстом плана, принимайте решение со spec как окончательной инстанцией и запишите вердикт в журнал до того, как действовать. Не отбрасывайте находку, потому что так требует план, и не отправляйте исправление, противоречащее плану, без зафиксированного вердикта. Всё остальное входит в цикл. Раунд исправления — это одна отправка на исправление плюс одно ревью с ограниченной областью. Максимум пять раундов на задачу:

Раунды 1–3 — возобновите исходного исполнителя. Отправьте ему открытые находки дословно. Его контекст цел: он знает задачу, код и свои собственные решения. Если ваша среда не может отправить ещё одно сообщение живому subagent, отправьте нового исполнителя с путём к брифу, путём к файлу отчёта и находками — файл отчёта в любом случае служит постоянной памятью.

Раунды 4–5 — отправьте нового исполнителя на более мощной модели (см. Model Selection), с путём к брифу, путём к файлу отчёта, открытыми находками и следующей формулировкой: «Предыдущий исполнитель пытался выполнить эту задачу [N] раз; теперь она ваша. Прочитайте файл отчёта, чтобы узнать, что уже пробовалось». Цикл, переживший три возобновления, обычно означает, что исполнитель не видит собственной проблемы — свежий взгляд и повышение мощности за один ход.

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

Ревью имеет ограниченную область. Запустите bash scripts/review-package PLAN_FILE FIX_BASE HEAD, где FIX_BASE — голова, которую видело предыдущее ревью, и отправьте re-review-prompt.md со списком находок, брифом, файлом отчёта и путём к напечатанному diff. Ревьюер присваивает каждой находке статус ADDRESSED или NOT ADDRESSED и отмечает только новую поломку в diff исправления. Новые поломки уровня Critical/Important в diff исправления добавляются в список открытых находок. Наблюдения вне области попадают в журнал как отложенные minor — они никогда не продлевают цикл.

После каждого раунда дописывайте в журнал: Task <N>: fix round <R>/5 (<X> addressed, <Y> open — <однострочники находок>; commits <a7>..<b7>)

Никогда не исправляйте находки самостоятельно в сессии контроллера — ваш контекст остаётся чистым для координации, а исправления контроллера минуют ревью.

Сработок. Когда ревью после раунда 5 всё ещё оставляет находки открытыми, прекратите отправку. Разрешите каждую открытую находку самостоятельно — у вас есть план и межзадачный контекст, которого нет у ревьюера:

Ревьюер ошибается, или вопрос спорен: отложите его — Task <N>: parked — <находка> — Ruling: <почему код остаётся>. Итоговое ревью увидит обе стороны.
Реальная, но на ней ничего не строится: отложите её так же, с вердиктом, что она реальна, но отложена.
Реальная и несущая — следующая задача строится на ней, или она обнаруживает дефект плана: вынесите вердикт о минимальном изменении, которое разблокирует зависимую работу, запишите его в журнал как Task <N>: Ruling: <находка> — <что вы решили и почему>, и перенесите его в отправку следующей задачи. Молчаливое отложение структурного сбоя позволяет каждой зависимой задаче строиться на нём. Останавливайтесь только когда дефект делает каждый дальнейший путь угадыванием.

Выносите вердикты только на лимите. Вынесение вердикта раньше, чтобы закончить цикл, — это предрешение под другим именем. Каждый вердикт — запись в журнале; молчаливая утилизация запрещена.

5. Завершение задачи

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

Task <N>: complete (commits <base7>..<head7>, review clean)
Task <N>: complete (commits <base7>..<head7>, <K> parked) после сработка сработка

Затем отметьте todo как выполненную и переходите дальше. Никогда не переходите к следующей задаче, пока в ревью есть открытые проблемы уровня Critical/Important, которые не исправлены и не отложены с вердиктом на лимите.

Итоговое ревью

Итоговое ревью всей ветки тоже получает пакет: запустите bash scripts/review-package PLAN_FILE MERGE_BASE HEAD (MERGE_BASE = коммит, с которого началась ветка, например git merge-base main HEAD) и включите напечатанный путь в отправку итогового ревью, чтобы итоговый ревьюер прочитал один файл вместо повторного вывода diff ветки командами git. Отправляйте на самой доступной мощной модели (см. Model Selection), используя superpowers:requesting-code-review's code-reviewer.md. Укажите ему строки журнала с отложенными minor и отложенными находками, чтобы он мог распределить, что нужно исправить перед слиянием.

Если итоговое ревью всей ветки возвращает находки, отправьте ОДНО исполнительное subagent со полным списком находок — не по исполнителю на каждую находку. Исполнители на каждую находку заново строят контекст и перезапускают тесты; волна исправлений по итоговому ревью в реальной сессии стоила дороже всех её задач вместе взятых. Затем запустите ровно одно ревью с ограниченной областью для волны исправлений (bash scripts/review-package PLAN_FILE FIX_BASE HEAD по диапазону исправлений, re-review-prompt.md). Вынесите вердикты по остаточным находкам так же, как в сработке цикла задач: отложите с вердиктами или вынесите вердикт о несущих и запишите в журнал своё решение. Только четыре перечисленные выше категории останавливают вас здесь. Второй волны исправлений нет — остаточные несущие находки выходят к вашему human-партнёру, когда finishing-a-development-branch представляет варианты.

Завершение

Прежде чем что-то удалять, соберите все строки журнала, содержащие Ruling: — вердикты preflight, отложенные находки, вердикты сработка, все — в своё итоговое под заголовком «Вердикты, которые я вынес», в том порядке, в каком вы их выносили, каждый с указанием, во что обойдётся ошибка. Список исчерпывающий: если в журнале есть вердикт, в списке он есть. Этот список — единственное место, где решения, принятые вами от имени вашего human-партнёра, доходят до него — он читает его и переделывает всё, что вы сделали неправильно. Вердикт, погибший вместе с рабочим пространством, — это решение, принятое втайне.

Когда итоговое ревью всей ветки чистое и его исправления слиты, удалите рабочее пространство этого плана (rm -rf <workspace>) — git-история теперь служит записью. Соседние директории принадлежат другим планам; не трогайте их.

Используйте superpowers:finishing-a-development-branch.

Частые самообманы

Отговорка	Реальность
«Почти соответствует spec»	Ревьюер нашёл пробелы в spec = не готово. Исправьте или упритесь в лимит и вынесите вердикт — это единственные выходы.
«Я исправлю сам, отправка — накладные расходы»	Исправления контроллера загрязняют ваш контекст и минуют ревью. Возобновите исполнителя.
«Ещё один раунд — и сойдётся»	За лимитом раунды не сходятся — сбой структурный. Вынесите вердикт и направьте дальше.
«Ревьюер всё равно найдёт что-то новое»	Ревью с ограниченной областью проверяют исправления; они не могут уходить в сторону. Новые находки по нетронутому коду идут в журнал, а не в цикл.
«Эта находка очевидно неверна, отброшу»	Вердикты выносите только на лимите, и каждый вердикт — запись в журнале. Молчаливая утилизация запрещена.
«Исправление было мелким, пропущу ревью»	Непроверенные исправления — путь, которым пролезают регрессии. Каждый раунд заканчивается ревью с ограниченной областью.
«Ревью замедляют цикл»	Цикл без ревью — просто непроверенные телодвижения. Ревью — это тормоза и рулевое управление цикла.
«Бухгалтерия журнала — накладные расходы»	Журнал переживает сжатие контекста. Контроллеры без него заново отправляли целые завершённые последовательности задач.
«Исполнитель создал своего ревьюера — бесплатная дополнительная гарантия»	Это дублирующее кресло, ревьюющее тот же diff; ворота — ревью задачи. Ревьюер, порождённый исполнителем, — дефект, на который нужно указать, а не строгость.

Пример рабочего процесса

Вы: Я использую Subagent-Driven Development для выполнения этого плана.

[Настройка: worktree проверен]
[Чтение файла плана один раз: docs/superpowers/plans/feature-plan.md]
[Определение рабочего пространства: bash scripts/sdd-workspace docs/superpowers/plans/feature-plan.md — журнала внутри нет, свежее начало]
[Создание todo для всех задач]

Задача 1: Скрипт установки hook

[Запуск task-brief для Task 1; отправка исполнителю с брифом + путями к отчётам + контекстом]

Исполнитель: "Прежде чем начать — hook должен устанавливаться на уровне пользователя или системы?"

Вы: "На уровне пользователя (~/.config/superpowers/hooks/)"

Исполнитель: [Позже]
  - Реализована команда install-hook
  - Добавлены тесты, 5/5 проходят
  - Самопроверка: обнаружил, что пропустил флаг --force, добавил
  - Закоммичено

[Запуск review-package PLAN_FILE BASE HEAD; отправка ревьюера задачи с напечатанным путём]
Ревьюер задачи: Spec ✅ — все требования выполнено, ничего лишнего.
  Сильные стороны: хорошее покрытие тестами, чисто. Проблемы: нет. Качество задачи: Approved.

[Журнал: Task 1: complete (commits a1b2c3d..d4e5f6a, review clean)]

Задача 2: Режимы восстановления

[Запуск task-brief для Task 2; отправка исполнителю с брифом + путями к отчётам + контекстом]

Исполнитель: [Без вопросов]
  - Добавлены режимы verify/repair
  - 8/8 тестов проходят
  - Закоммичено

[Запуск review-package PLAN_FILE BASE HEAD; отправка ревьюера задачи с напечатанным путём]
Ревьюер задачи: Spec ❌:
  - Отсутствует: отчёт о прогрессе (spec говорит "report every 100 items")
  Проблемы (Important): магическое число (100)

[Раунд исправлений 1: возобновление исполнителя с обеими находками]
Исполнитель: Добавлен отчёт о прогрессе, вынес константу PROGRESS_INTERVAL.
  Перезапущен test/recovery.test.js — 10/10 проходят. Отчёт об исправлении дописан.

[Запуск review-package PLAN_FILE FIX_BASE HEAD; отправка ревью с ограниченной областью]
Ревью: Отсутствующий отчёт о прогрессе — ADDRESSED (src/recovery.js:41).
  Магическое число — ADDRESSED (src/recovery.js:7). Новая поломка: нет.
  Вердикт: все находки исправлены.

[Журнал: Task 2: fix round 1/5 (2 addressed, 0 open; commits d4e5f6a..b7c8d9e)]
[Журнал: Task 2: complete (commits d4e5f6a..b7c8d9e, review clean)]

...

[После всех задач]
[Запуск review-package PLAN_FILE MERGE_BASE HEAD; отправка итоговому code-reviewer, самая мощная модель]
Итоговый ревьюер: Все требования выполнены. Отложенные minor распределены: ничего не блокирует слияние.

[Удаление рабочего пространства этого плана — запись теперь в git]

Готово! Использую superpowers:finishing-a-development-branch.

Установка

npx skills add https://github.com/obra/superpowers --skill subagent-driven-development