bro-review-code

bro-review-code

Independent review of changes to source code, tests, configuration, infrastructure, and software contracts. The skill can be invoked directly or from the subagent prompt of another skill.

The result is only evidence-based findings on the current changes. Do not fix the code, do not create patches, and do not substitute implementation for review.

READONLY

It is permitted to read the repository, history, and diff, search for usages, study tests and configuration, and run safe non-destructive checks.

Prohibited:

modifying or creating files;
formatting code, applying autofixes, creating commits;
running migrations and commands that change data or external systems;
proposing large-scale refactoring if the risk can be eliminated locally;
reporting stylistic preferences and unproven assumptions as findings.

Review input

First determine:

Review object — an explicitly specified diff, commit range, branch, PR, or set of files.
Comparison base — an explicitly specified base or the merge-base of the current and main branches.
Task context — the user's result, scope, acceptance criteria, constraints, and plan, if provided.

If the object is not specified:

if there are uncommitted changes, review them together with the commits related to the current task, if the task boundary is clear;
otherwise review the current branch relative to the merge-base with the main branch;
if there are no significant changes or the boundary is ambiguous, stop and request the review object.

If the task statement is not provided, still check correctness, security, performance, and tests, but explicitly state that compliance with the original task was assessed with limited confidence.

Study not only the diff: read the surrounding implementation, calling code, types, tests, configuration, and contracts needed to verify the reachability of the risk.

Mode selection

The rules for selecting the tier and model family are described in subagent-model-tiers.

For requirements, correctness, performance и tests use tier senior.
For security-review-prompt use tier critical. Security review on critical is mandatory for any profile review; do not substitute it with other profiles and do not downgrade it to senior.

Profile review is launched only for complex, broad, or high-risk changes.

Comprehensive review

If the change is limited to one clear scenario and subsystem, and also does not affect high-risk boundaries, do not launch nested subagents. Independently conduct all review areas according to comprehensive review in the current context.

If there are security surfaces (auth, secrets, untrusted input, trust boundaries) — do not remain in comprehensive mode: switch to profile mode.

Profile review

Launch applicable profile checks in parallel, if the change:

affects multiple subsystems or independent user scenarios;
changes public contracts, data storage, or data transformation;
concerns authentication, authorization, secrets, or other trust boundaries;
is on a hot path, performs data queries or external calls;
contains a significant test surface, concurrency, retries, or partial failures.

Available checks:

requirements-review-prompt — compliance with the task and scope;
correctness-review-prompt — correctness and regressions;
security-review-prompt — security (required, tier critical);
performance-review-prompt — performance;
tests-review-prompt — quality and completeness of tests.

For a broad change, run all applicable checks. For a local but high-risk change, run only the risk-related profile checks together with the correctness check. security-review-prompt on critical run always during profile review.

Do not run a profile if its subject is clearly absent from the changes.

If the current harness does not support running nested subagents, do not stop the review or narrow its scope: independently and sequentially apply all selected profile prompts in the current context, and then compile a single report according to the same rules.

Substitute the same full context into all prompts:

Объект ревью: <diff, диапазон, ветка, PR или файлы>
База сравнения: <base>
Задача и критерии: <переданный контекст либо «не переданы»>
Ограничения проекта: <релевантные правила>
Известные проверки: <что уже запускалось и с каким результатом>

Do not pass subagents links to files of this skill: the text of the selected prompt and the context must be fully contained in Task.

Merging results

After the profile review, independently compile a single report:

Remove duplicates, keeping the most precise evidence and the minimal fix.
Merge findings with the same root cause.
Do not raise severity just because several subagents found the problem.
Discard findings without a reachable scenario, a specific location, and verifiable evidence.
If there is a contradiction, verify the code yourself or explicitly lower confidence.
Group findings by criteria, and within each criterion sort by severity, then by impact.

Severity:

critical — reachable loss or mass data leak, complete bypass of critical protection, remote code execution, or system unavailability;
high — violation of a key user scenario, authorization bypass, significant data or performance regression;
medium — a real defect or verification gap with limited impact and a demonstrable scenario;
style, optional improvements, and hypothetical optimizations are not findings.

Final format

Start with the section ## Результаты ревью. Create a section for each criterion and use fixed headings:

requirements → ### Соответствие требованиям;
correctness → ### Корректность;
security → ### Безопасность;
performance → ### Производительность;
tests → ### Тесты.

If the profile was applied, place findings in its section or an explicit statement that there are none. If the profile was not applied, still create its section and state why a review against this criterion was not performed.

For each finding, provide:

A fourth-level heading in the format #### [severity] Краткое название, where severity — critical, high or medium.
**Где:** file and line, character, or the exact logic location.
**Проблема:** the specific defect.
**Последствие:** the observed consequence and the affected scenario.
**Доказательство:** evidence from the code, contract, diff, or test.
**Исправление:** the minimal meaningful fix.
**Уверенность:** высокая, средняя or низкая; for medium and low, state the reason.

Do not repeat the criterion inside the finding: it is set by the section heading. If there are no findings for the reviewed criterion, write under its heading: Существенных проблем не найдено.

Format the result according to the example final report, preserving the specificity and scope needed for the current review.

After the results, add:

Brief summary

what was reviewed;
which checks or commands were used;
which risks remained unverified and why;
whether additional human review is needed.

Respond in Russian. Do not include draft reasoning or separate raw reports from profile subagents.

Quality Control

Before finishing, check:

the object and basis of the review are stated unambiguously;
a standalone comprehensive mode or a justified set of profile subagents was chosen;
each finding relates to changed code and is confirmed by a reachable scenario;
duplicates merged, severity normalized, findings grouped by verified criteria;
code and files were not modified;
for each criterion a section was created with findings, an explicit conclusion that they are absent, or the reason why the review was not conducted;
the summary contains only grouped findings and a brief summary.