| name | bro-review-code |
| description | Проводит независимое READONLY-ревью изменений кода: соответствие задаче, корректность, безопасность, производительность и тесты. |
| disable-model-invocation | true |
bro-review-code
Независимое ревью изменений исходного кода, тестов, конфигурации, инфраструктуры и программных контрактов. Скилл можно вызвать напрямую или из промпта субагента другого скилла.
Результат — только доказательные замечания по текущим изменениям. Не исправляй код, не создавай патчи и не подменяй ревью реализацией.
READONLY
Разрешено читать репозиторий, историю и diff, искать использования, изучать тесты и конфигурацию, а также запускать безопасные недеструктивные проверки.
Запрещено:
- изменять или создавать файлы;
- форматировать код, применять автоисправления, создавать коммиты;
- выполнять миграции и команды, меняющие данные или внешние системы;
- предлагать крупный рефакторинг, если риск устраняется локально;
- сообщать стилистические предпочтения и недоказанные предположения как findings.
Вход ревью
Сначала определи:
- Объект ревью — явно указанный diff, диапазон коммитов, ветка, PR или набор файлов.
- Базу сравнения — явно указанную базу либо merge-base текущей и основной веток.
- Контекст задачи — пользовательский результат, рамки, критерии приемки, ограничения и план, если они переданы.
Если объект не указан:
- при наличии незакоммиченных изменений проверяй их вместе с относящимися к ним коммитами текущей задачи, если граница задачи понятна;
- иначе проверяй текущую ветку относительно merge-base с основной веткой;
- если значимых изменений нет или граница неоднозначна, остановись и запроси объект ревью.
Если постановка задачи не передана, всё равно проверяй корректность, безопасность, производительность и тесты, но явно укажи, что соответствие исходной задаче оценено с ограниченной уверенностью.
Изучай не только diff: читай окружающую реализацию, вызывающий код, типы, тесты, конфигурацию и контракты, необходимые для проверки достижимости риска.
Выбор режима
Правила выбора тира и семейства модели описаны в subagent-model-tiers. Для всех reviewer-субагентов используй тир code-reviewer.
Комплексное ревью
Если изменение ограничено одним понятным сценарием и подсистемой, а также не затрагивает высокорисковые границы, не запускай вложенных субагентов. Самостоятельно проведи все направления проверки по комплексному ревью в текущем контексте.
Профильное ревью
Запускай применимые профильные проверки параллельно, если изменение:
- затрагивает несколько подсистем или независимых пользовательских сценариев;
- меняет публичные контракты, хранение или преобразование данных;
- касается аутентификации, авторизации, секретов или других границ доверия;
- находится в горячем пути, выполняет запросы к данным или внешние вызовы;
- содержит значительную тестовую поверхность, конкурентность, повторы или частичные сбои.
Доступные проверки:
Для широкого изменения запускай все пять проверок. Для локального, но высокорискового изменения запускай только относящиеся к риску профильные проверки вместе с проверкой корректности. Не запускай профиль, если его предмет заведомо отсутствует в изменениях.
Если текущий harness не поддерживает запуск вложенных субагентов, не останавливай ревью и не сокращай его область: самостоятельно последовательно примени все выбранные профильные промпты в текущем контексте, а затем собери единый отчёт по тем же правилам.
Во все промпты подставляй один и тот же полный контекст:
Объект ревью: <diff, диапазон, ветка, PR или файлы>
База сравнения: <base>
Задача и критерии: <переданный контекст либо «не переданы»>
Ограничения проекта: <релевантные правила>
Известные проверки: <что уже запускалось и с каким результатом>
Не передавай субагентам ссылки на файлы этого скилла: текст выбранного промпта и контекст должны полностью находиться в Task.
Объединение результатов
После профильного ревью самостоятельно собери единый отчёт:
- Удали дубли, оставив наиболее точное доказательство и минимальное исправление.
- Объедини замечания с одной корневой причиной.
- Не повышай серьёзность только потому, что проблему нашли несколько субагентов.
- Отбрось замечания без достижимого сценария, конкретного места и проверяемого доказательства.
- При противоречии проверь код самостоятельно либо явно снизь
confidence.
- Отсортируй findings по серьёзности, затем по влиянию.
Серьёзность:
critical — достижимая потеря или массовая утечка данных, полный обход критической защиты, удалённое выполнение кода либо системная недоступность;high — нарушение ключевого пользовательского сценария, обход авторизации, существенная регрессия данных или производительности;medium — реальный дефект или пробел проверки с ограниченным влиянием и доказуемым сценарием;- стилистика, необязательные улучшения и гипотетические оптимизации не являются findings.
Итоговый формат
Сначала выдай findings. Для каждого укажи:
severity: critical / high / medium;criterion: requirements / correctness / security / performance / tests;where: файл и строка, символ либо точный участок логики;problem: конкретный дефект;impact: наблюдаемое последствие и затронутый сценарий;evidence: доказательство из кода, контракта, diff или теста;suggestion: минимальное осмысленное исправление;confidence: high / medium / low с причиной, если уверенность не высокая.
Если findings нет, напиши: Существенных проблем не найдено.
После findings добавь:
Краткое резюме
- что просмотрено;
- какие проверки или команды использованы;
- какие риски остались непроверенными и почему;
- нужна ли дополнительная проверка человеком.
Отвечай на русском языке. Не включай черновые рассуждения и отдельные необработанные отчёты профильных субагентов.
Quality Control
Перед завершением проверь:
- объект и база ревью указаны однозначно;
- выбран самостоятельный комплексный режим либо обоснованный набор профильных субагентов;
- каждый finding относится к изменённому коду и подтверждён достижимым сценарием;
- дубли объединены, серьёзность нормализована;
- код и файлы не изменялись;
- итог содержит только объединённые findings и краткое резюме.
