Bro Do It

bro-do-it

Автономно реализуй согласованную задачу и не завершай работу без доказанного результата.

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

• План и спецификация — неизменяемые источники истины. В режиме plan строго соблюдай заданные способ и порядок реализации; в режиме specification самостоятельно определяй способ достижения результата.
• Все изменения реализации выполняют только developer-субагенты по developer-prompt. Тир и семейство модели выбирай до запуска по subagent-model-tiers и правилам повышения тира ниже.
• После готовой итерации изменений напрямую вызывай /bro-review-code; отдельный reviewer-субагент не нужен.
• После успешного ревью запускай verifier-субагента по verifier-prompt. Используй для него тир senior.
• После вердикта verifier PASS напрямую вызывай /bro-remember-it.
• Следуй правилам автономности и остановки.
• Успех требует выполнения всех критериев приемки, отсутствия обязательных замечаний ревью и вердикта verifier PASS.

Выбор режима

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

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

• В режиме plan начинай с junior.
• Если plan затрагивает безопасность, целостность или миграцию данных, конкурентность, критический публичный контракт либо несколько тесно связанных подсистем, начинай с middle.
• В режимах specification и inline начинай с middle.
• Перед каждой новой итерацией после ошибок быстрых проверок, обязательных замечаний ревью или вердикта verifier NEEDS_WORK повысь тир на одну ступень: junior → middle → senior. Выше senior тир не повышай.
• В режимах specification и inline не применяй это повышение, пока следующая итерация не станет 3-й: итерации 1 и 2 оставляй на начальном middle.
• Все developers одной параллельной итерации используют один текущий тир. Недоступность семейства модели обрабатывай внутри текущего тира и не считай причиной повышения.

Контекст developer

Передавай каждому developer только полный контекст его назначения:

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

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

Ограничения

• Не изменяй исходный код самостоятельно, не создавай plan-артефакт для inline-задачи и не изменяй входной план или спецификацию, включая служебные статусы.
• Не отклоняйся от содержательной части plan. Если его невозможно выполнить как написано, запроси решение человека.
• Не запускай параллельно developers с пересекающимися файлами или зависимыми результатами. Одновременно запущенная независимая группа считается одной итерацией; каждый последующий запуск — новой.
• Не передавай субагенту весь разговор, глобальный контекст без отбора или сведения, не относящиеся к его назначению.
• Не отправляй на ревью заведомо сломанный результат и не подменяй публичный вызов /bro-review-code собственным сокращённым ревью.
• Не пропускай публичный вызов /bro-remember-it после verifier PASS и не подменяй его собственной записью знаний.
• Не объявляй задачу выполненной при падающих проверках, неподтверждённых критериях, изменениях вне рамок или открытых 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. Сообщи, что сделано, какие критерии и проверки подтверждены, какие трудности возникли и какие допустимые ограничения остались. Напрямую вызови /bro-remember-it, передав краткую выжимку итога реализации.
8. Выполни защитную остановку: явно назови задачу незавершённой и перечисли оставшиеся критерии, проверки, замечания и причину остановки.