# Bro Review Code

> Проводит независимое ревью изменений кода без их исправления. Используй, когда пользователь явно просит проверить код, коммит, ветку, pull request или diff на соответствие задаче, корректность, безопасность, производительность и качество тестов. Не используй, когда пользователь просит изменить код, реализовать задачу или сначала найти причину проблемы.

- Skill: `irpsv/bro-review-code` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add irpsv/bro-review-code`
- Raw SKILL.md: https://api.skillmd.com/api/skills/irpsv/bro-review-code/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: irpsv (https://skillmd.com/u/irpsv)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/irpsv/bro-review-code

---


# bro-review-code

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

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

## READONLY

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

Запрещено:

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

## Вход ревью

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

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

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

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

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

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

## Выбор режима

Правила выбора тира и семейства модели описаны в [subagent-model-tiers](./references/subagent-model-tiers.md).

- Для [requirements](./subagents/requirements-review-prompt.md), [correctness](./subagents/correctness-review-prompt.md), [performance](./subagents/performance-review-prompt.md) и [tests](./subagents/tests-review-prompt.md) используй тир [senior](./references/subagent-model-tiers.md#senior).
- Для [security-review-prompt](./subagents/security-review-prompt.md) используй тир [critical](./references/subagent-model-tiers.md#critical). Ревью безопасности на `critical` **обязательно** при любом профильном ревью; не подменяй его другими профилями и не понижай до `senior`.

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

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

Если изменение ограничено одним понятным сценарием и подсистемой, а также не затрагивает высокорисковые границы, не запускай вложенных субагентов. Самостоятельно проведи все направления проверки по [комплексному ревью](./references/full-review.md) в текущем контексте.

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

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

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

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

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

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

Для широкого изменения запускай все применимые проверки. Для локального, но высокорискового изменения запускай только относящиеся к риску профильные проверки вместе с проверкой корректности. [security-review-prompt](./subagents/security-review-prompt.md) на `critical` запускай **всегда** при профильном ревью.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оформляй результат по [примеру итогового отчёта](./references/review-output-example.md), сохраняя конкретность и объём, необходимые для текущего ревью.

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

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

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

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

## Quality Control

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

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