Bro Review Code

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 не поддерживает запуск вложенных субагентов, не останавливай ревью и не сокращай его область: самостоятельно последовательно примени все выбранные профильные промпты в текущем контексте, а затем собери единый отчёт по тем же правилам.

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

Объект ревью: <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 нет, напиши под его заголовком: Существенных проблем не найдено.

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

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

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

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

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

Quality Control

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

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