bro-do-it

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

bro-do-it

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

自主完成已确认的任务，未取得可验证结果前不得终止工作。

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

通用规则

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

计划与规格说明是不可更改的依据。在
```
plan
```
模式下，严格遵循指定的实现方式与顺序；在
```
specification
```
模式下，自主确定达成结果的方式。
所有实现变更仅由developer子代理根据developer-prompt执行。需在启动前根据subagent-model-tiers及下文的层级提升规则选择模型层级及系列。
完成一轮变更迭代后，直接调用
```
/bro-review-code
```
；无需单独调用reviewer子代理。
评审通过后，根据verifier-prompt启动verifier子代理。其使用的模型层级不得低于当前开发层级，且不得低于middle。
遵循自主执行与终止规则。
任务成功需满足所有验收标准、无评审强制意见且verifier给出
```
PASS
```
verdict。

Выбор режима

模式选择

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

任务工件文件指包含计划、规格说明或需求的文档。请求中提及的代码、配置、数据及日志文件本身不属于任务工件。
无任务工件文件时，使用inline模式。
若至少一个已确认工件的名称与内容明确指定了实现方式或顺序，使用plan模式；其余工件可补充结果与验收标准。
所有工件仅定义最终结果与验收标准，未指定实现方式时，使用specification模式。
工件名称与内容相互矛盾、存在冲突或对模式选择存疑时，停止执行并向用户提出一个明确问题。

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

开发层级选择与提升

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

在
```
plan
```
模式下，从junior层级开始。
若
```
plan
```
涉及安全、数据完整性或迁移、并发、关键公共契约或多个紧密关联的子系统，从middle层级开始。
在
```
specification
```
与
```
inline
```
模式下，从middle层级开始。
每次快速检查出错、收到评审强制意见或verifier给出
```
NEEDS_WORK
```
verdict后，在下一轮迭代前将层级提升一级：
```
junior
```
→
```
middle
```
→
```
senior
```
。不得提升至senior以上层级。
同一并行迭代中的所有developer子代理使用当前同一层级。模型系列不可用时，在当前层级内处理，不得作为层级提升的理由。

Контекст developer

Developer子代理上下文

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

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

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

为每个developer子代理仅传递与其任务相关的完整上下文：

任务总体目标；
与其领域相关的范围、限制及验收标准；
具体工作单元及变更边界；
重要接口与其他部分的依赖关系；
当前迭代的快速检查错误、评审强制意见及verifier发现的问题。

仅传递工件路径用于追踪：该路径不会扩展任务范围，也不能替代上下文中包含的明确要求。不得让developer子代理自行从整个工件中提取工作范围。不得用修复列表替代原始要求。在下一轮迭代中，保留与任务相关的原始上下文并添加新的错误与意见。

Ограничения

限制条件

Не изменяй исходный код самостоятельно, не создавай plan-артефакт для inline-задачи и не изменяй входной план или спецификацию, включая служебные статусы.
Не отклоняйся от содержательной части
```
plan
```
. Если его невозможно выполнить как написано, запроси решение человека.
Не запускай параллельно developers с пересекающимися файлами или зависимыми результатами. Одновременно запущенная независимая группа считается одной итерацией; каждый последующий запуск — новой.
Не передавай субагенту весь разговор, глобальный контекст без отбора или сведения, не относящиеся к его назначению.
Не отправляй на ревью заведомо сломанный результат и не подменяй публичный вызов
```
/bro-review-code
```
собственным сокращённым ревью.
Не объявляй задачу выполненной при падающих проверках, неподтверждённых критериях, изменениях вне рамок или открытых
```
critical
```
,
```
high
```
и блокирующих приемку
```
medium
```
замечаниях.
Не сбрасывай счётчик итераций после ревью или тестов и не продолжай цикл без подтверждённого прогресса.

不得自行修改原始代码，不得为inline任务创建plan工件，不得修改输入的计划或规格说明（包括服务状态）。
不得偏离
```
plan
```
的核心内容。若无法按计划执行，请请求用户解决。
不得并行启动涉及交叉文件或依赖结果的developer子代理。同时启动的独立组视为一轮迭代；后续每次启动视为新的迭代。
不得向子代理传递整个对话、未经筛选的全局上下文或与其任务无关的信息。
不得将明显存在问题的结果提交评审，不得用自行简化的评审替代公开调用
```
/bro-review-code
```
。
若检查未通过、验收标准未确认、变更超出范围或存在未解决的
```
critical
```
、
```
high
```
及阻碍验收的
```
medium
```
意见，不得宣布任务完成。
评审或测试后不得重置迭代计数器，未确认取得进展不得继续循环。

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

工作流程

Выбери режим по правилам выше, прочитай только соответствующий workflow, сформируй контекст задачи и зафиксируй базу сравнения до изменений.
Установи счётчик
```
Итерация разработки: 0/5
```
и начальный тир разработки по выбранному режиму и риску задачи.
Перед запуском developer проверь счётчик. Если использованы пять итераций, перейди к шагу 8. Иначе увеличь счётчик, явно зафиксируй
```
Итерация разработки: N/5
```
и текущий тир, выдели независимые назначения и запусти одного developer либо одновременно независимую группу.
Собери изменения и выполни быстрые релевантные проверки. При ошибках добавь их в контекст соответствующего назначения, повысь тир разработки по правилам выше и перейди к шагу 3.
Напрямую вызови
```
/bro-review-code
```
по всем изменениям задачи относительно базы, передав контекст задачи и результаты проверок. При обязательных замечаниях или невыполненных критериях добавь их в контекст соответствующего назначения, повысь тир разработки по правилам выше и перейди к шагу 3.
Запусти verifier по его промпту, передав объект и базу проверки, критерии приемки, результаты ревью и быстрых проверок. При
```
NEEDS_WORK
```
передай его findings без смыслового пересказа в контекст соответствующего назначения, повысь тир разработки по правилам выше и перейди к шагу 3. При
```
BLOCKED
```
устрани блокер автономно и повтори шаг 6 либо перейди к шагу 8. При
```
PASS
```
перейди к шагу 7.
Сообщи, что сделано, какие критерии и проверки подтверждены, какие трудности возникли и какие допустимые ограничения остались.
Выполни защитную остановку: явно назови задачу незавершённой и перечисли оставшиеся критерии, проверки, замечания и причину остановки.

根据上述规则选择模式，仅阅读对应工作流，构建任务上下文并记录变更前的基准版本。
设置计数器
```
开发迭代：0/5
```
，并根据所选模式及任务风险确定初始开发层级。
启动developer子代理前检查计数器。若已使用五次迭代，进入步骤8。否则增加计数器，明确记录
```
开发迭代：N/5
```
及当前层级，拆分独立任务并启动单个developer子代理或同时启动独立组。
收集变更并执行相关快速检查。若出现错误，将其添加至对应任务的上下文，根据上述规则提升开发层级，然后回到步骤3。
针对基准版本的所有变更直接调用
```
/bro-review-code
```
，传递任务上下文及检查结果。若收到强制意见或未满足验收标准，将其添加至对应任务的上下文，根据上述规则提升开发层级，然后回到步骤3。
根据verifier提示词启动verifier子代理，传递检查对象与基准版本、验收标准、评审结果及快速检查结果。若返回
```
NEEDS_WORK
```
，直接将其发现的问题添加至对应任务的上下文，根据上述规则提升开发层级，然后回到步骤3。若返回
```
BLOCKED
```
，自主排除阻塞因素后重复步骤6，或进入步骤8。若返回
```
PASS
```
，进入步骤7。
告知用户已完成的工作、已确认的验收标准与检查项、遇到的困难及剩余的可接受限制。
执行保护性终止：明确说明任务未完成，并列出剩余的验收标准、检查项、意见及终止原因。