bro-review-code

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

bro-review-code

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

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

独立审查源代码、测试、配置、基础设施和软件契约的变更。可直接调用该Skill，也可从其他Skill的Subagent提示词中调用。

审查结果仅包含针对当前变更的有依据的意见。请勿修改代码，不要创建补丁，也不要用实现工作替代审查。

READONLY

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

Запрещено:

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

允许读取仓库、历史记录和diff，查找用法，研究测试和配置，以及运行安全的非破坏性检查。

禁止：

修改或创建文件；
格式化代码、应用自动修复、创建commit；
执行迁移和会更改数据或外部系统的命令；
如果风险可在本地消除，建议进行大规模重构；
将风格偏好和无依据的假设作为findings上报。

Вход ревью

审查入口

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

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

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

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

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

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

首先确定：

审查对象 —— 明确指定的diff、提交范围、分支、PR或文件集。
对比基准 —— 明确指定的基准，或当前分支与主分支的merge-base。
任务上下文 —— 用户提供的预期结果、范围、验收标准、限制条件和计划（如果已提供）。

如果未指定审查对象：

若存在未提交的变更，且任务边界清晰，则检查这些变更及相关的当前任务提交；
否则，检查当前分支相对于与主分支merge-base的差异；
如果没有重大变更或边界不明确，请停止并请求用户指定审查对象。

如果未提供任务说明，仍需检查正确性、安全性、性能和测试，但需明确说明对原始任务的符合度评估存在一定局限性。

不仅要研究diff：还要阅读相关的实现代码、调用代码、类型定义、测试、配置和契约，这些是评估风险必要性的内容。

Выбор режима

模式选择

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

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

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

模型层级和系列的选择规则详见subagent-model-tiers。

针对requirements、correctness、performance和tests审查，使用senior层级。
针对security-review-prompt审查，使用critical层级。任何专业审查中，必须使用critical层级进行安全审查；不得用其他层级替代，也不得降级为senior层级。

仅针对复杂、范围广或高风险的变更启动专业审查。

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

综合审查

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

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

如果变更仅限于一个清晰的场景和子系统，且不涉及高风险边界，则无需启动Subagent。自行根据当前上下文，按照综合审查的所有检查方向完成审查。

如果存在安全相关场景（认证、密钥、不可信输入、信任边界）——请勿停留在综合模式：切换到专业模式。

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

专业审查

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

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

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

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

如果变更满足以下条件，并行启动适用的专业检查：

涉及多个子系统或独立的用户场景；
修改公共契约、数据存储或转换逻辑；
涉及认证、授权、密钥或其他信任边界；
位于核心路径、执行数据查询或外部调用；
包含大量测试场景、并发逻辑、重复代码或部分故障处理。

可用的检查类型：

requirements-review-prompt —— 符合任务要求和范围；
correctness-review-prompt —— 正确性和回归问题；
security-review-prompt —— 安全性（必须使用critical层级）；
performance-review-prompt —— 性能；
tests-review-prompt —— 测试质量和完整性。

对于范围广的变更，启动所有适用的检查。对于局部但高风险的变更，仅启动与风险相关的专业检查以及正确性检查。专业审查中必须始终启动critical层级的security-review-prompt。

如果变更中明显不存在某类检查的对象，则无需启动该专业检查。

如果当前环境不支持启动Subagent，请勿停止审查或缩小审查范围：自行依次在当前上下文中应用所有选定的专业提示词，然后按照相同规则生成统一报告。

在所有提示词中填入相同的完整上下文：

text

审查对象: <diff、范围、分支、PR或文件>
对比基准: <base>
任务和标准: <提供的上下文或“未提供”>
项目限制: <相关规则>
已完成的检查: <已执行的检查及结果>

请勿向Subagent传递本Skill的文件链接：选定的提示词文本和上下文必须完全包含在

Task

中。

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

结果合并

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

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

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

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

专业审查完成后，自行生成统一报告：

删除重复内容，保留最准确的依据和最小化的修复建议；
将同一根本原因的意见合并；
不要仅因为多个Subagent发现同一问题就提高严重程度；
丢弃没有可行场景、具体位置和可验证依据的意见；
如果出现矛盾，自行检查代码或明确降低
```
confidence
```
；
按检查标准对findings进行分组，同一标准内按严重程度排序，再按影响范围排序。

严重程度：

```
critical
```
—— 可能导致数据丢失或大规模泄露、完全绕过关键防护、远程代码执行或系统完全不可用；
```
high
```
—— 破坏核心用户场景、绕过授权、严重的数据或性能回归；
```
medium
```
—— 实际存在的缺陷或检查漏洞，影响范围有限且有可验证场景；
风格问题、非必要改进和假设性优化不属于findings。

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

最终格式

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

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

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

requirements

→

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

;

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

performance

→

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

;

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

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

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

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

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

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

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

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

以

## 审查结果

开头。为每个检查标准创建章节，并使用固定标题：

```
requirements
```
→
```
### 符合要求
```
；
```
correctness
```
→
```
### 正确性
```
；
```
security
```
→
```
### 安全性
```
；
```
performance
```
→
```
### 性能
```
；
```
tests
```
→
```
### 测试
```
。

如果已应用某类专业检查，在对应章节中列出findings或明确说明未发现问题。如果未应用某类检查，仍需创建对应章节并说明未进行该审查的原因。

每个finding需包含：

四级标题，格式为

#### [severity] 简要名称

，其中

severity

为

critical

、

high

或

medium

；

```
**位置:**
```
文件和行号、字符或精确逻辑段；
```
**问题:**
```
具体缺陷；
```
**影响:**
```
可观察到的后果及受影响的场景；
```
**依据:**
```
来自代码、契约、diff或测试的证据；
```
**修复建议:**
```
最小化的合理修复方案；
```
**置信度:**
```
```
高
```
、
```
中
```
或
```
低
```
；对于中、低置信度，需说明原因。

不要在finding内重复检查标准：标准已由章节标题指定。如果某类检查未发现问题，在对应章节下写：

未发现重大问题

。

按照最终报告示例格式化结果，保持当前审查所需的具体性和篇幅。

结果之后添加：

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

简要总结

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

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

审查了哪些内容；
使用了哪些检查或命令；
哪些风险未被检查及原因；
是否需要人工进一步审查。

请用中文回复。不要包含草稿思路和未处理的专业Subagent单独报告。

Quality Control

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

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

完成前检查：

审查对象和基准已明确指定；
已选择独立综合模式或有依据的专业Subagent组合；
每个finding均与变更代码相关，并由可行场景验证；
重复内容已合并，严重程度已标准化，findings按检查标准分组；
未修改代码和文件；
为每个检查标准创建了章节，包含findings、明确的无问题结论或未审查原因；
最终结果仅包含分组后的findings和简要总结。