bro-do-it

bro-do-it

Autonomously implement the agreed-upon task and do not finish the work without a proven result.

General rules

• The input plan and specification are immutable sources of truth.
• All implementation changes are made only by developer subagents according to developer-prompt. Choose the model tier and family before launching according to subagent-model-tiers and the tier rules below.
• The developer commits its own edits according to the commit rules.
• Conduct the re-review according to the rules after the iteration. A separate reviewer subagent is not needed.
• Launch the closer and verifier according to the subagent rules.
• After the verdict verifier PASS directly call /bro-remember-it, then commit its records according to the commit rules.
• Follow the autonomy and stopping rules.
• Success requires fulfilling all acceptance criteria, the absence of mandatory review comments, and a verdict of verifier PASS.

Mode selection

If the task statement contains implementation steps, you must use the mode plan, otherwise use the mode autopilot.

plan

• You MUST follow the specified steps, order, technical approach, scope, and acceptance criteria.
• Independently choose only details that the plan does not define and that do not change its method of implementation.
• If the specified method or order cannot be carried out as written, stop and ask the human one specific question. Do not choose an alternative on your own.

autopilot

• Independently choose the minimal complete implementation method compatible with the existing code.

Development tier

• Choose the initial developer tier according to subagent-model-tiers as the minimal sufficient one. Tier senior take it only as an exception — when there is high complexity, uncertainty, or risk according to this dictionary, not "just in case".
• Before each new iteration after errors from quick checks, unresolved items closer, mandatory review remarks, or a verdict of verifier NEEDS_WORK raise the tier by one step: junior → middle → senior. Do not raise the tier above senior .
• All developers of one parallel iteration use one current tier. Handle the unavailability of a model family within the current tier and do not consider it a reason for raising.

Developer context

Pass to each developer only the full context of their assignment:

• the overall goal of the task;
• the scope, constraints, and acceptance criteria relevant to their area;
• the specific unit of work and the boundaries of changes;
• in mode plan — the mandatory method and order of the current unit of work;
• in mode autopilot — independently adopted assumptions that do not change the result;
• important interfaces and dependencies with other parts;
• the development iteration number;
• errors from quick checks, unresolved mandatory review remarks, and findings verifier of the current iteration.

Pass the path to the artifact only for tracing: it does not expand the assignment and does not replace the precise requirements included in the context. Do not instruct the developer to independently extract the scope of work from the entire artifact. Do not replace the original requirements with a list of fixes. In the next iteration, preserve the original context relevant to the assignment and add new errors and remarks.

В Task for the developer, pass the full text of developer-prompt. Substitute the assignment context for <контекст назначения> and the full text of implementation hygiene for <гигиена реализации>. Do not reference skill files.

Subagents

The rules for choosing the tier and model family are subagent-model-tiers. Choose the tier and model before launching. Pass the prompt text and verification context in full to Task, without references to skill files. Substitute the formed context in place of <контекст проверки> in the prompt.

closer

READONLY check: whether the diff after the last review point has closed every mandatory finding from the open list. This is not a code review.

• prompt: closer-prompt
• model: senior

Do not run closer if the list is empty. Run it after successful quick checks and before /bro-review-code, if the list is not empty.

Pass into the check context:

• the full open list of mandatory findings with identifiers;
• the object of the check — changes after the last review point;
• the comparison base — the last review point.

From the response, take only the verdicts on the items of this list. Consider a missing verdict не закрыт. Discard any new findings, recommendations, and paraphrasing. Do not consider an item closed without an explicit verdict закрыт.

If there are still unclosed items, leave only them in the list, return developer in the original wording, and do not call /bro-review-code.

verifier

READONLY task readiness check: tests, acceptance criteria, and changed branches. This is not a repeated code review.

• prompt: verifier-prompt
• model: senior

Run after a review without mandatory findings.

Pass into the check context:

• the object of the check and the task's original base;
• the acceptance criteria;
• the results of the review and quick checks.

On NEEDS_WORK pass findings without semantic paraphrasing into the context of the corresponding assignment. On BLOCKED eliminate the blocker autonomously and repeat verifier, or perform a protective stop. On PASS proceed to the summary and /bro-remember-it.

Constraints

• Do not modify the source code yourself, do not modify the input plan or specification, including service statuses. Committing changes already made does not count as a violation of this prohibition.
• Do not run developer while the prompt Task has not substituted the full text of implementation hygiene in place of <гигиена реализации>.
• Do not run developers in parallel with overlapping files or dependent results. A simultaneously running independent group counts as one iteration; each subsequent run counts as a new one.
• Do not pass the entire conversation, global context without selection, or information unrelated to its purpose to the subagent.
• Do not use --amend and do not include files outside the current purpose in the commit.
• Do not call closer and review while there are uncommitted task changes in the git repository.
• Do not send for a repeat /bro-review-code all task changes relative to the original base if the last review point has already moved.
• Do not substitute the public call /bro-review-code with a check closer.
• Do not send a knowingly broken result for review.
• Do not skip the public call /bro-remember-it after verifier PASS and do not substitute it with your own knowledge record. Do not leave its records uncommitted.
• Do not declare the task completed with failing checks, unconfirmed criteria, changes outside the scope, or open critical, high and blocking acceptance medium remarks.
• Do not reset the iteration counter after review or tests and do not continue the cycle without confirmed progress.

Work order

1. Choose the mode according to the rules above, form the task context and, before changes, record the original base of the task. Set the last review point equal to this base, and the list of mandatory remarks to empty.
2. Set the counter Итерация разработки: 0/10 and the initial development tier according to the tier rules.
3. Before launching developer, check the counter. If ten iterations have been used, go to step 9. Otherwise, increment the counter, explicitly record Итерация разработки: N/10 and the current tier, identify independent purposes and launch one developer or simultaneously an independent group.
4. Collect the changes and perform quick relevant checks. If there remain uncommitted assignment changes, consider this an error. On errors, add them to the context of the corresponding assignment, apply the tier escalation rules above, and go to step 3.
5. If the list of mandatory remarks is not empty, run closer. If there remain unclosed items, apply the tier escalation rules above and go to step 3. If the list is empty or all items are closed, go to step 6.
6. Directly call /bro-review-code on the changes after the last review point, passing this object, this base, the task context, and the check results. Update the last review point to the current HEAD. On mandatory remarks or unmet criteria, replace the list with them, add them to the context of the corresponding assignment, apply the tier escalation rules above, and go to step 3. Otherwise clear the list and go to step 7.
7. Run verifier. On NEEDS_WORK apply the tier escalation rules above and go to step 3. On BLOCKED go to step 9 if the blocker cannot be resolved autonomously. On PASS go to step 8.
8. Report what has been done, which criteria and checks are confirmed, what difficulties arose, and what acceptable limitations remain. Additionally, write how a human can verify the result themselves. Directly call /bro-remember-it, passing a brief summary of the implementation outcome, then commit its entries according to commit rules.
9. Perform defensive stop: explicitly declare the task incomplete and list the remaining criteria, checks, remarks, and the reason for stopping.