bro-do-it

Общие правила

• План и спецификация — неизменяемые источники истины. В режиме

  plan

  строго соблюдай заданные способ и порядок реализации; в режиме

  specification

  самостоятельно определяй способ достижения результата.
• Все изменения реализации выполняют только developer-субагенты по developer-prompt. Тир и семейство модели выбирай до запуска по subagent-model-tiers и правилам повышения тира ниже.
• После готовой итерации изменений напрямую вызывай

  /bro-review-code

  ; отдельный reviewer-субагент не нужен.
• После успешного ревью запускай verifier-субагента по verifier-prompt. Используй для него тир не ниже текущего тира разработки и не ниже middle.
• Следуй правилам автономности и остановки.
• Успех требует выполнения всех критериев приемки, отсутствия обязательных замечаний ревью и вердикта verifier

  PASS

  .

Выбор режима

• Файл-артефакт задачи — документ с планом, спецификацией или требованиями. Упомянутые в запросе файлы кода, конфигурации, данных и журналов сами по себе артефактами задачи не являются.
• Нет файла-артефакта задачи — используй inline.
• Хотя бы один из согласованных артефактов по имени и содержимому задаёт способ или порядок реализации — используй plan; остальные артефакты могут дополнять результат и критерии.
• Все артефакты задают только конечный результат и критерии, но не способ реализации — используй specification.
• Имена и содержимое артефактов противоречат друг другу, между артефактами есть конфликт либо режим вызывает сомнение — остановись и задай человеку один явный вопрос.

Выбор и повышение тира разработки

• В режиме

  plan

  начинай с junior.
• Если

  plan

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

  specification

  и

  inline

  начинай с middle.
• Перед каждой новой итерацией после ошибок быстрых проверок, обязательных замечаний ревью или вердикта verifier

  NEEDS_WORK

  повысь тир на одну ступень:

  junior

  →

  middle

  →

  senior

  . Выше senior тир не повышай.
• Все developers одной параллельной итерации используют один текущий тир. Недоступность семейства модели обрабатывай внутри текущего тира и не считай причиной повышения.

Контекст developer

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

Ограничения

• Не изменяй исходный код самостоятельно, не создавай plan-артефакт для inline-задачи и не изменяй входной план или спецификацию, включая служебные статусы.
• Не отклоняйся от содержательной части

  plan

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

  /bro-review-code

  собственным сокращённым ревью.
• Не объявляй задачу выполненной при падающих проверках, неподтверждённых критериях, изменениях вне рамок или открытых

  critical

  ,

  high

  и блокирующих приемку

  medium

  замечаниях.
• Не сбрасывай счётчик итераций после ревью или тестов и не продолжай цикл без подтверждённого прогресса.

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

1. Выбери режим по правилам выше, прочитай только соответствующий workflow, сформируй контекст задачи и зафиксируй базу сравнения до изменений.
2. Установи счётчик

   Итерация разработки: 0/5

   и начальный тир разработки по выбранному режиму и риску задачи.
3. Перед запуском developer проверь счётчик. Если использованы пять итераций, перейди к шагу 8. Иначе увеличь счётчик, явно зафиксируй

   Итерация разработки: N/5

   и текущий тир, выдели независимые назначения и запусти одного developer либо одновременно независимую группу.
4. Собери изменения и выполни быстрые релевантные проверки. При ошибках добавь их в контекст соответствующего назначения, повысь тир разработки по правилам выше и перейди к шагу 3.
5. Напрямую вызови

   /bro-review-code

   по всем изменениям задачи относительно базы, передав контекст задачи и результаты проверок. При обязательных замечаниях или невыполненных критериях добавь их в контекст соответствующего назначения, повысь тир разработки по правилам выше и перейди к шагу 3.
6. Запусти verifier по его промпту, передав объект и базу проверки, критерии приемки, результаты ревью и быстрых проверок. При

   NEEDS_WORK

   передай его findings без смыслового пересказа в контекст соответствующего назначения, повысь тир разработки по правилам выше и перейди к шагу 3. При

   BLOCKED

   устрани блокер автономно и повтори шаг 6 либо перейди к шагу 8. При

   PASS

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