---
name: review-swarm
description: "对当前 git diff 或明确的文件范围进行并行只读多智能体审查，以发现行为回归、安全或隐私风险、性能或可靠性问题，以及合约或测试覆盖率差距。当用户要求进行 review swarm、并行审查、diff 审查、回归审查、安全审查，或者希望在不编辑文件的情况下获得高信号问题及优先级修复路径时使用。"
---

# Review Swarm

并行使用四个只读子智能体审查 diff，然后由主智能体过滤、排序并总结仅重要的问题。此技能仅限审查：子智能体不编辑文件，主智能体在此工作流中也不执行修复。

## 第 1 步：确定范围和意图

优先采用��下范围顺序：

1. 用户明确命名的文件或路径
2. 当前 git 变更
3. 用户要求的明确分支、提交或 PR diff
4. 最近修改的已跟踪文件（仅当用户要求审查且没有更明确的 diff 时）

如果没有明确的审查范围，请停止并简要说明。

使用 git 变更时，选择最小且正确的 diff 命令：

- 未暂存的工作：`git diff`
- 已暂存的工作：`git diff --cached`
- 混合已暂存和未暂存的工作：两者都审查
- 明确的分支或提交比较：完全按照用户的要求使用

在启动审查者之前，阅读受影响区域最近的本地指令和任何相关的项目文档，例如：

- `AGENTS.md`
- 仓库工作流文档
- 受影响模块的架构或合约文档

为审查者构建一个简短的意图包：

1. 预期改变的行为
2. 应保持不变的行为
3. 任何声明或推断的约束，如兼容性、发布、安全或迁移预期

如果用户没有清楚地说明意图，请从 diff 中推断，并说明该推断可能不完整。

## 第 2 步：并行启动四个只读审查者

当范围足够大，并行审查有帮助时，启动四个子智能体。对于极小的 diff 或一个非常小的文件，可以改为在本地审查。

对于每个子智能体：

- 提供相同的范围和相同的意图包
- 声明子智能体是只读的
- 不允许子智能体编辑文件、运行 `apply_patch`、暂存更改、提交或执行任何其他改变状态的操作
- 仅要求简洁的发现
- 要求提供：文件和行号或符号、问题、重要性、建议的后续行动以及置信度
- 告诉子智能体避免琐碎细节、风格偏好以及没有具体影响的推测性担忧
- 告诉子智能体仅将发现发送回主智能体

使用这四个审查角色。

### 子智能体 1：意图和回归审查

审查 diff 是否符合预期的行为变更，且未引入额外的行为偏差。

检查：

1. 声明范围之外的非预期行为变更
2. 损坏的边缘情况或回退路径
3. 调用者与被调用者之间的合约偏差
4. 缺少应同步变更的相邻流程更新

此子智能体是只读的。它不得编辑文件、应用补丁或进行任何其他工作区更改。

推荐的子智能体角色：`reviewer`

### 子智能体 2：安全和隐私审查

审查 diff 中的安全回归、隐私风险和信任边界错误。

检查：

1. 缺失或削弱的 authn 或 authz 检查
2. 不安全的输入处理、注入风险或验证漏洞
3. 密钥、令牌或敏感数据泄露
4. 风险默认值、权限扩展或对未验证数据的信任

此子智能体是只读的。它不得编辑文件、应用补丁或进行任何其他工作区更改。

推荐的子智能体角色：`reviewer`

### 子智能体 3：性能和可靠性审查

审查 diff 中的新成本、脆弱性或运营风险。

检查：

1. 重复工作、冗余 I/O 或不必要的重新计算
2. 在启动、渲染、请求或其他热路径上增加的工作量
3. 泄漏、缺失清理、重试风暴或订阅偏差
4. 使变更变得脆弱的顺序、竞争或失败处理问题

此子智能体是只读的。它不得编辑文件、应用补丁或进行任何其他工作区更改。

推荐的子智能体角色：`reviewer`

### 子智能体 4：合约和覆盖率审查

审查 diff 中的兼容性差距和缺失的安全网。

检查：

1. API、架构、类型、配置或功能标志不匹配
2. 迁移或向后兼容性影响
3. 针对变更行为的缺失或薄弱测试
4. 缺失的日志、指标、断言或错误路径，导致回归更难检测

此子智能体是只读的。它不得编辑文件、应用补丁或进行任何其他工作区更改。

推荐的子智能体角色：`reviewer`

仅报告实质性影响正确性、安全性、隐私性、可靠性、兼容性或变更置信度的问题。宁可漏掉琐碎细节，也不要让用户淹没在低价值的噪音中。

## 第 3 步：汇总并过滤发现

主智能体负责综合。将子智能体的输出视为原始审查输入，而非最终输出。

合并所有四个审查者的发现并进行严格过滤：

- 删除重复项
- 删除薄弱或推测性的主张
- 删除与声明意图冲突的问题
- 删除次要的风格或可读性注释，除非它们隐藏了真正的错误或维护风险

将保留的发现规范化为以下形式：

1. 文件和行号或最近的符号
2. 类别：回归、安全、可靠性或合约
3. 严重程度：高、中或低
4. 重要性
5. 建议的修复或后续行动
6. 置信度：高、中或低

如果审查者可能是正确的但意图不明确，请将其转变为开放式问题而非发现。

## 第 4 步：对输出进行排序

按此顺序呈现发现：

1. 高严重程度、高置信度的问题
2. 可能值得在合并前修复的中等严重程度问题
3. 较低严重程度的问题或可以等待的后续行动

保持审查简洁。发现应具有可操作性并有证据支持。

如果没有实质性问题，请直接说明，不要捏造反馈。

## 第 5 步：推荐清晰的后续路径

在发现之后，为用户提供一条简短的后续路径：

- 合并前需要修复的内容
- 如果时间允许需要改进的内容
- 可以安全搁置的内容

在有帮助时，将后续路径分组为：

- `fix now` (立即修复)
- `fix soon` (尽快修复)
- `optional follow-up` (可选后续行动)

不要将实施修复作为此技能的一部分。输出是只读审查加上优先级建议。