review-swarm

Review Swarm

使用 4 个只读子 Agent 并行审查差异，然后由主 Agent 筛选、排序并总结重要问题。此技能仅用于审查：子 Agent 不会编辑文件，主 Agent 也不会在此工作流中应用修复。

步骤 1：确定范围和意图

优先按以下顺序确定范围：

1. 用户明确指定的文件或路径
2. 当前 Git 更改
3. 用户要求审查的明确分支、提交或 PR 差异
4. 最近修改的已跟踪文件，但仅限用户要求审查且没有更明确的差异范围时

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

使用 Git 更改时，选择最小且正确的差异命令：

• 未暂存的更改：git diff
• 已暂存的更改：git diff --cached
• 已暂存和未暂存的更改都有：两者都审查
• 明确的分支或提交比较：严格使用用户要求的内容

启动审查者前，阅读最相关的本地说明，以及与修改范围相关的项目文档，例如：

• AGENTS.md
• 仓库工作流文档
• 修改模块的架构或契约文档

为审查者准备一份简短的意图说明：

1. 预期要改变的行为
2. 应保持不变的行为
3. 已说明或推断出的约束，例如兼容性、发布、隐私或迁移要求

如果用户没有清楚说明意图，请根据差异推断，并指出推断可能不完整。

步骤 2：并行启动 4 个只读审查者

当审查范围足够大、并行审查有帮助时，启动 4 个子 Agent。对于很小的差异或只有一个很小的文件，可以在本地审查。

对每个子 Agent：

• 提供相同的审查范围和意图说明
• 声明该子 Agent 只读
• 不允许子 Agent 编辑文件、运行 apply_patch、暂存更改、提交或执行任何其他会修改状态的操作
• 要求只提供简洁的发现
• 要求包含：文件和行号或符号、问题、问题的重要性、建议的后续处理，以及置信度
• 告知子 Agent 避免挑剔、风格偏好，以及没有具体影响的推测性担忧
• 告知子 Agent 只向主 Agent 返回发现

使用以下 4 个审查角色。

子 Agent 1：意图与回归审查

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

检查：

1. 声明范围之外的意外行为变更
2. 被破坏的边缘情况或回退路径
3. 调用方与被调用方之间的契约偏移
4. 应一并更新但遗漏的相邻流程

此子 Agent 只读。不得编辑文件、应用补丁或以任何其他方式更改工作区。

建议的子 Agent 角色：reviewer

子 Agent 2：安全与隐私审查

审查差异是否造成安全回归、隐私风险或信任边界问题。

检查：

1. 缺失或减弱的身份验证或授权检查
2. 不安全的输入处理、注入风险或验证漏洞
3. 密钥、令牌或敏感数据泄露
4. 风险默认设置、权限扩大，或信任未经验证的数据

此子 Agent 只读。不得编辑文件、应用补丁或以任何其他方式更改工作区。

建议的子 Agent 角色：reviewer

子 Agent 3：性能与可靠性审查

审查差异是否引入了新的成本、脆弱性或运维风险。

检查：

1. 重复工作、冗余 I/O 或不必要的重新计算
2. 启动、渲染、请求或其他热点路径中增加的工作
3. 泄漏、缺少清理、重试风暴或订阅偏移
4. 导致变更脆弱的顺序、竞争条件或故障处理问题

子 Agent 4：契约与覆盖率审查

审查差异，查找兼容性缺口和缺失的安全保障。

检查以下方面：

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

此子 Agent 只读。不得编辑文件、应用补丁或对工作区进行任何其他更改。

建议的子 Agent 角色：reviewer

仅报告会实质影响正确性、安全性、隐私、可靠性、兼容性或对变更信心的问题。宁可漏掉细枝末节，也不要让用户被低价值的噪声淹没。

第 3 步：汇总并筛选发现

主 Agent 负责综合分析。将子 Agent 的输出视为原始审查输入，而非最终结果。

合并四位审查者的发现，并严格筛选：

• 去除重复项
• 去除薄弱或推测性结论
• 去除与既定意图冲突的问题
• 去除细微的风格或可读性意见，除非它们掩盖了实际错误或维护风险

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

1. 文件及行号或最接近的符号
2. 类别：回归、安全、可靠性或契约
3. 严重性：高、中或低
4. 问题的影响
5. 建议的修复或后续措施
6. 置信度：高、中或低

如果某位审查者的判断可能正确，但意图不明确，应将其改为开放式问题，而不是作为发现报告。

第 4 步：排列输出顺序

按以下顺序呈现发现：

1. 严重性高且置信度高的问题
2. 很可能值得在合并前修复的中等严重性问题
3. 可稍后处理的低严重性问题或后续事项

审查内容应简明。发现应具有可操作性，并有证据支持。

如果没有实质性问题，请直接说明，不要为了给反馈而凭空制造问题。

第 5 步：明确建议后续步骤

列出发现后，给用户简要说明下一步：

• 合并前要修复什么
• 有时间时要改进什么
• 哪些内容可以放心保留现状

有帮助时，可将后续步骤分组为：

• 立即修复
• 尽快修复
• 可选后续事项

不要在此技能中实施修复。输出应仅包含只读审查和按优先级排列的建议。