bro-do-it

name	bro-do-it
description	Автономно реализует задачу из плана или прямо из диалога, проверяет результат и проводит обязательное ревью.
disable-model-invocation	true

bro-do-it

Автономная реализация поставленной задачи через субагентов — по готовому плану или без отдельного артефакта планирования. ОБЯЗАТЕЛЬНО используй субагентов для реализации исходного кода и ревью исполняемых изменений. ОБЯЗАТЕЛЬНО соблюдай порядок работы. ОБЯЗАТЕЛЬНО проверь результат работы по чеклисту.

STOP

ЗАПРЕЩЕНО менять исходный код без использования субагента developer. ЗАПРЕЩЕНО нарушать порядок работы. ЗАПРЕЩЕНО создавать план или другой артефакт планирования, если задача передана прямо из диалога. ЗАПРЕЩЕНО эскалировать человеку технические решения, которые не меняют пользовательский результат, безопасность, данные или публичный контракт.

Субагенты

Правила выбора тира и семейства модели для этого скилла описаны в subagent-model-tiers.

• developer — выполняет автономную реализацию поставленной задачи.
  • prompt: developer-prompt
  • model: coding
  • Подставь сформированный workflow task payload вместо <task payload> в промпте
• reviewer — изолирует ревью от контекста реализации и вызывает /bro-review-code.
  • prompt: reviewer-prompt
  • model: code-reviewer
  • Подставь тот же task payload вместо <task payload> в промпте

Принцип автономности

По умолчанию не спрашивай человека и не жди подтверждения. Самостоятельно:

• собирай контекст из разговора, плана и репозитория;
• выбирай консервативный подход, совместимый с существующим кодом;
• определяй минимальное полноценное изменение;
• выбирай и запускай уместные проверки;
• исправляй замечания ревью;
• фиксируй несущественные допущения в финальном отчете.

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

Эскалация допустима только если без решения человека:

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

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

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

1. Подготовка

Выбери workflow, сформируй task payload и определи тир/семейство модели для каждого запуска субагента.

Если указан stage-файл плана (frontmatter steps, разделы ## Шаг N), загрузи и следуй инструкциям из stage-plan Если указан другой файл плана, загрузи и следуй инструкциям из generic-plan Иначе загрузи и следуй инструкциям из inline-task

Workflow определяет содержимое <task payload> в промптах субагентов. Оркестратор не пересказывает задачу своими словами, если workflow уже сформировал payload. Тир и семейство модели выбирай по subagent-model-tiers.

2. Реализация

Реализуй задачу согласно task payload, полученному на этапе подготовка. ОБЯЗАТЕЛЬНО делегируй работу субагенту developer.

• определи, какие части payload можно выполнить в одном запуске developer; допустимо передать весь payload одному субагенту;
• определи порядок запусков и можно ли часть выполнить параллельно без пересечения изменяемых файлов;
• НЕ ПЕРЕДАВАЙ весь контекст разговора — только task payload и минимальный дополнительный контекст из workflow.

Если workflow требует синхронизацию артефакта плана, выполни её по инструкциям workflow до или после запуска developer, как указано там.

Если developer возвращает техническую неопределенность, сначала разреши ее по принципу автономности и при необходимости запусти developer повторно с уточненным payload.

После реализации всех частей payload переходи к ревью кода.

3. Ревью кода

Проведи ревью текущих правок после реализации. ОБЯЗАТЕЛЬНО делегируй работу субагенту reviewer, если изменилось исполняемое поведение, конфигурация, инфраструктура или пользовательский контракт. Reviewer ОБЯЗАТЕЛЬНО вызывает /bro-review-code по публичной команде и возвращает его объединённый отчёт; не подменяй этот вызов локальной копией правил ревью.

На ревью отправляй изменения исходного кода, тестов, конфигурации, инфраструктуры и пользовательских контрактов. Если изменились только документация или тексты инструкций без исполняемого поведения, отдельный reviewer не обязателен: самостоятельно проверь ссылки, структуру и требования репозитория.

Если после ревью есть critical или high замечания, переходи к правкам по ревью. Локальные, безопасные и явно полезные medium замечания также исправь. Остальные перечисли в финальном отчете. Если замечаний для исправления нет, переходи к проверке результата.

4. Правки по ревью

Внеси правки для устранения замечаний, выбранных после ревью. ОБЯЗАТЕЛЬНО делегируй работу субагенту developer.

Для правок по ревью сформируй отдельный task payload с перечнем замечаний reviewer.

5. Повторное ревью

Проведи ревью текущих правок после правок по ревью. ОБЯЗАТЕЛЬНО делегируй работу субагенту reviewer.

Если после повторного ревью опять есть critical или high замечания, продолжай цикл исправления и ревью, пока есть понятный безопасный путь. Остановись только при выполнении условий эскалации. Иначе переходи к проверке результата.

6. Проверка результата

Запусти минимально достаточные проверки, соответствующие изменению:

• релевантные тесты;
• линтер или статическую проверку, если она стандартна для проекта;
• сборку или проверку типов, если изменение затрагивает компиляцию;
• ручную проверку, если автоматической проверки нет.

Если проверку невозможно выполнить, явно зафиксируй причину и ближайший безопасный способ проверить результат.

7. Финализация

Опиши что реализовано и на что обратить внимание после реализации. Если есть неустраненные замечания после ревью, опиши их. Укажи выполненные проверки и их результат либо причину, по которой их не удалось выполнить. Зафиксируй важные допущения, если они были.

Если workflow требовал синхронизацию артефакта плана, убедись, что она выполнена.

Чеклист

• Выбран workflow и сформирован task payload.
• Для inline-задачи до правок дана краткая сводка пользовательского результата и не создан артефакт планирования.
• Для каждого запуска субагента выбраны тир и семейство модели по subagent-model-tiers.
• Вызван субагент developer для реализации задачи.
• Вызван субагент reviewer, если изменилось исполняемое поведение, конфигурация, инфраструктура или пользовательский контракт.
• Нет открытых critical и high замечаний от reviewer.
• Запущены релевантные проверки или описана причина, почему их нельзя выполнить.
• Синхронизация артефакта плана выполнена, если workflow это требовал.