bro-review-code

Независимое ревью изменений исходного кода, тестов, конфигурации, инфраструктуры и программных контрактов. Скилл можно вызвать напрямую или из промпта субагента другого скилла.

Результат — только доказательные замечания по текущим изменениям. Не исправляй код, не создавай патчи и не подменяй ревью реализацией.

READONLY

Разрешено читать репозиторий, историю и diff, искать использования, изучать тесты и конфигурацию, а также запускать безопасные недеструктивные проверки.

Запрещено:

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

Вход ревью

Сначала определи:

Объект ревью — явно указанный diff, диапазон коммитов, ветка, PR или набор файлов.
Базу сравнения — явно указанную базу либо merge-base текущей и основной веток.
Контекст задачи — пользовательский результат, рамки, критерии приемки, ограничения и план, если они переданы.

Если объект не указан:

при наличии незакоммиченных изменений проверяй их вместе с относящимися к ним коммитами текущей задачи, если граница задачи понятна;
иначе проверяй текущую ветку относительно merge-base с основной веткой;
если значимых изменений нет или граница неоднозначна, остановись и запроси объект ревью.

Если постановка задачи не передана, всё равно проверяй корректность, безопасность, производительность и тесты, но явно укажи, что соответствие исходной задаче оценено с ограниченной уверенностью.

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

Выбор режима

Правила выбора тира и семейства модели описаны в subagent-model-tiers.

Для requirements, correctness, performance и tests используй тир senior.
Для security-review-prompt используй тир critical. Ревью безопасности на
```
critical
```
обязательно при любом профильном ревью; не подменяй его другими профилями и не понижай до
```
senior
```
.

Профильное ревью запускается только для сложных, широких или высокорисковых изменений.

Комплексное ревью

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

Если есть поверхности безопасности (auth, секреты, недоверенный ввод, границы доверия) — не оставайся в комплексном режиме: переходи к профильному.

Профильное ревью

Запускай применимые профильные проверки параллельно, если изменение:

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

Доступные проверки:

requirements-review-prompt — соответствие задаче и рамкам;
correctness-review-prompt — корректность и регрессии;
security-review-prompt — безопасность (обязательно, тир
```
critical
```
);
performance-review-prompt — производительность;
tests-review-prompt — качество и полнота тестов.

Для широкого изменения запускай все применимые проверки. Для локального, но высокорискового изменения запускай только относящиеся к риску профильные проверки вместе с проверкой корректности. security-review-prompt на

critical

запускай всегда при профильном ревью.

Не запускай профиль, если его предмет заведомо отсутствует в изменениях.

Если текущий harness не поддерживает запуск вложенных субагентов, не останавливай ревью и не сокращай его область: самостоятельно последовательно примени все выбранные профильные промпты в текущем контексте, а затем собери единый отчёт по тем же правилам.

Во все промпты подставляй один и тот же полный контекст:

text

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

Не передавай субагентам ссылки на файлы этого скилла: текст выбранного промпта и контекст должны полностью находиться в

Task

Объединение результатов

После профильного ревью самостоятельно собери единый отчёт:

Удали дубли, оставив наиболее точное доказательство и минимальное исправление.
Объедини замечания с одной корневой причиной.
Не повышай серьёзность только потому, что проблему нашли несколько субагентов.
Отбрось замечания без достижимого сценария, конкретного места и проверяемого доказательства.
При противоречии проверь код самостоятельно либо явно снизь
```
confidence
```
.
Сгруппируй findings по критериям, а внутри каждого критерия отсортируй по серьёзности, затем по влиянию.

Серьёзность:

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

Итоговый формат

Начни с раздела

## Результаты ревью

. Создай раздел для каждого критерия и используй фиксированные заголовки:

requirements

→

### Соответствие требованиям

;

```
correctness
```
→
```
### Корректность
```
;
```
security
```
→
```
### Безопасность
```
;

performance

→

### Производительность

;

```
tests
```
→
```
### Тесты
```
.

Если профиль применялся, помести в его раздел findings либо явный вывод об их отсутствии. Если профиль не применялся, всё равно создай его раздел и укажи, почему ревью по этому критерию не проводилось.

Для каждого finding выдай:

Заголовок четвёртого уровня в формате
```
#### [severity] Краткое название
```
, где
```
severity
```
—
```
critical
```
,
```
high
```
или
```
medium
```
.
```
**Где:**
```
файл и строка, символ либо точный участок логики.
```
**Проблема:**
```
конкретный дефект.
```
**Последствие:**
```
наблюдаемое последствие и затронутый сценарий.
```
**Доказательство:**
```
доказательство из кода, контракта, diff или теста.
```
**Исправление:**
```
минимальное осмысленное исправление.
```
**Уверенность:**
```
```
высокая
```
,
```
средняя
```
или
```
низкая
```
; для средней и низкой укажи причину.

Не повторяй критерий внутри finding: он задан заголовком раздела. Если в проверенном критерии findings нет, напиши под его заголовком:

Существенных проблем не найдено

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

После результатов добавь:

Краткое резюме

что просмотрено;
какие проверки или команды использованы;
какие риски остались непроверенными и почему;
нужна ли дополнительная проверка человеком.

Отвечай на русском языке. Не включай черновые рассуждения и отдельные необработанные отчёты профильных субагентов.

Quality Control

Перед завершением проверь:

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

bro-review-code

NPX Install

Tags

SKILL.md Content

bro-review-code

READONLY

Вход ревью

Выбор режима

Комплексное ревью

Профильное ревью

Объединение результатов

Итоговый формат

Краткое резюме

Quality Control