bro-do-it

bro-do-it

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

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

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

Выбор режима

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

plan

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

autopilot

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

Тир разработки

• Начальный тир developer выбирай по subagent-model-tiers как минимальный достаточный. Тир senior бери только как исключение — при высокой сложности, неопределённости или риске по этому словарю, не «на всякий случай».
• Перед каждой новой итерацией после ошибок быстрых проверок, незакрытых пунктов closer, обязательных замечаний ревью или вердикта verifier NEEDS_WORK повысь тир на одну ступень: junior → middle → senior. Выше senior тир не повышай.
• Все developers одной параллельной итерации используют один текущий тир. Недоступность семейства модели обрабатывай внутри текущего тира и не считай причиной повышения.

Контекст developer

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

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

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

В Task для developer передай полный текст developer-prompt. Подставь контекст назначения вместо <контекст назначения> и полный текст гигиены реализации вместо <гигиена реализации>. Не ссылайся на файлы скилла.

Субагенты

Правила выбора тира и семейства модели — subagent-model-tiers. Тир и модель выбирай до запуска. Текст промпта и контекст проверки полностью передай в Task, без ссылок на файлы скилла. Подставь сформированный контекст вместо <контекст проверки> в промпте.

closer

READONLY-проверка: закрыл ли diff после точки последнего ревью каждое обязательное замечание из открытого списка. Это не ревью кода.

• prompt: closer-prompt
• model: senior

Не запускай closer, если список пуст. Запускай после успешных быстрых проверок и до /bro-review-code, если список не пуст.

В контекст проверки передай:

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

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

Если остались незакрытые пункты, оставь в списке только их, верни developer в исходной формулировке и не вызывай /bro-review-code.

verifier

READONLY-проверка готовности задачи: тесты, критерии приемки и изменённые ветви. Это не повторное ревью кода.

• prompt: verifier-prompt
• model: senior

Запускай после ревью без обязательных замечаний.

В контекст проверки передай:

• объект проверки и исходную базу задачи;
• критерии приемки;
• результаты ревью и быстрых проверок.

При NEEDS_WORK передай findings без смыслового пересказа в контекст соответствующего назначения. При BLOCKED устрани блокер автономно и повтори verifier либо выполни защитную остановку. При PASS переходи к итогу и /bro-remember-it.

Ограничения

• Не изменяй исходный код самостоятельно, не изменяй входной план или спецификацию. Коммит уже сделанных изменений этим запретом не считается.
• Не запускай developer, пока в промпте Task не подставлен полный текст гигиены реализации вместо <гигиена реализации>.
• Не запускай параллельно developers с пересекающимися файлами или зависимыми результатами. Одновременно запущенная независимая группа считается одной итерацией; каждый последующий запуск — новой.
• Не передавай субагенту весь разговор, глобальный контекст без отбора или сведения, не относящиеся к его назначению.
• Не используй --amend и не включай в коммит файлы вне текущего назначения.
• Не вызывай closer и ревью, пока в git-репозитории есть незакоммиченные изменения задачи.
• Не отправляй на повторное /bro-review-code все изменения задачи относительно исходной базы, если точка последнего ревью уже сдвинута.
• Не подменяй публичный вызов /bro-review-code проверкой closer.
• Не отправляй на ревью заведомо сломанный результат.
• Не пропускай публичный вызов /bro-remember-it после verifier PASS и не подменяй его собственной записью знаний. Не оставляй его записи незакоммиченными.
• Не объявляй задачу выполненной при падающих проверках, неподтверждённых критериях, изменениях вне рамок или открытых critical, high и блокирующих приемку medium замечаниях.
• Не сбрасывай счётчик итераций после ревью или тестов и не продолжай цикл без подтверждённого прогресса.

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

1. Выбери режим по правилам выше, сформируй контекст задачи и до изменений зафиксируй исходную базу задачи. Точку последнего ревью поставь равной этой базе, список обязательных замечаний — пустым.
2. Установи счётчик Итерация разработки: 0/10 и начальный тир разработки по правилам тира.
3. Перед запуском developer проверь счётчик. Если использованы десять итераций, перейди к шагу 9. Иначе увеличь счётчик, явно зафиксируй Итерация разработки: N/10 и текущий тир, выдели независимые назначения и запусти одного developer либо одновременно независимую группу.
4. Собери изменения и выполни быстрые релевантные проверки. Если остались незакоммиченные изменения назначения, считай это ошибкой. При ошибках добавь их в контекст соответствующего назначения, примени правила повышения тира выше и перейди к шагу 3.
5. Если список обязательных замечаний не пуст, запусти closer. Если остались незакрытые пункты, примени правила повышения тира выше и перейди к шагу 3. Если список пуст или все пункты закрыты, перейди к шагу 6.
6. Напрямую вызови /bro-review-code по изменениям после точки последнего ревью, передав этот объект, эту базу, контекст задачи и результаты проверок. Обнови точку последнего ревью на текущий HEAD. При обязательных замечаниях или невыполненных критериях замени ими список, добавь их в контекст соответствующего назначения, примени правила повышения тира выше и перейди к шагу 3. Иначе очисти список и перейди к шагу 7.
7. Запусти verifier. При NEEDS_WORK примени правила повышения тира выше и перейди к шагу 3. При BLOCKED перейди к шагу 9, если блокер нельзя устранить автономно. При PASS перейди к шагу 8.
8. Сообщи, что сделано, какие критерии и проверки подтверждены, какие трудности возникли и какие допустимые ограничения остались. Дополнительно напиши как можно проверить результат самому человеку. Напрямую вызови /bro-remember-it, передав краткую выжимку итога реализации, затем закоммить его записи по правилам коммита.
9. Выполни защитную остановку: явно назови задачу незавершённой и перечисли оставшиеся критерии, проверки, замечания и причину остановки.