Review Swarm 是一个代码审查技能，采用“四个只读子智能体并行审查 + 主智能体汇总”的方式，对一次代码变更给出聚焦、可执行的审查意见。整个流程是只读的：子智能体不编辑文件，主智能体也不在本工作流中应用修复。
用途
它用于审查一段代码变更（diff）或用户显式指定的文件范围，目的是发现行为回归、安全或隐私风险、性能与可靠性问题，以及契约兼容与测试覆盖缺口。
工作流程
第一步：确定范围与意图。范围优先级为：用户显式指定的文件或路径；当前 git 变更；用户指定的分支、提交或 PR diff；只有在用户要求审查且没有更清晰 diff 时，才考虑最近修改过的受跟踪文件。若没有清晰的审查范围，应直接说明并停止。使用 git 变更时选择最小且正确的 diff 命令：未暂存工作用 git diff，已暂存工作用 git diff --cached，两者混合则都审查；分支或提交比较严格按用户要求执行。启动审查者前，阅读被触及区域最近的本地说明和相关项目文档，如 AGENTS.md、仓库工作流文档、被触及模块的架构或契约文档。随后构建一个简短的意图包，说明哪些行为应当改变、哪些行为应保持不变，以及兼容性、发布、安全或迁移等约束；如果用户未清楚说明意图，则从 diff 推断并注明推断可能不完整。
第二步：并行启动四个只读审查者。当范围足够大、并行审查有价值时启动四个子智能体；对于很小的 diff 或单个很小的文件，也可以在本地审查。每个子智能体应获得相同的范围和相同的意图包，并被告知自己是只读的：不得编辑文件、运行 apply_patch、暂存更改、提交或执行任何改变状态的行动。要求只给出简洁的发现，包含文件与行号或符号、问题、为何重要、建议的后续动作和置信度；避免细枝末节、风格偏好以及没有具体影响的推测性担忧；发现只回传给主智能体。四个审查角色分别是：一、意图与回归审查，检查 diff 是否匹配预期行为变化而未引入额外行为漂移，关注超出声明范围的意外行为变化、损坏的边界情况或回退路径、调用方与被调用方之间的契约漂移、应同步修改却缺失的相邻流程更新。二、安全与隐私审查，关注缺失或削弱的认证与授权检查、不安全的输入处理、注入风险或验证缺口、机密令牌或敏感数据暴露、危险默认值、权限扩大或对未验证数据的信任。三、性能与可靠性审查，关注重复工作、冗余 I/O 或不必要的重复计算，在启动、渲染、请求等热路径上新增的工作，泄漏、缺少清理、重试风暴或订阅漂移，以及使变更变脆弱的顺序、竞态或失败处理问题。四、契约与覆盖审查，关注 API、模式、类型、配置或特性开关不匹配，迁移或向后兼容影响，变更行为缺少或薄弱的测试，以及缺失的日志、指标、断言或错误路径，这些会让回归更难被发现。只报告对正确性、安全、隐私、可靠性、兼容性或变更信心有实质影响的问题；宁可漏掉细枝末节，也不要让用户淹没在低价值噪音中。
第三步：汇总与过滤发现。主智能体负责综合，把子智能体输出视为原始审查输入而非最终输出。跨四个审查者合并发现并积极过滤：去掉重复项、去掉薄弱或推测性主张、去掉与所述意图冲突的问题、去掉除非隐藏真实缺陷或维护风险否则属于次要风格或可读性的评论。保留的发现规范化为以下形状：文件与行号或最近符号；类别（回归、安全、可靠性或契约）；严重程度（高、中、低）；为何重要；建议修复或后续动作；置信度（高、中、低）。如果某个审查者可能正确但意图不清楚，则将其转为开放问题而不是发现。
第四步：排序输出。按以下顺序呈现发现：高严重度且高置信度的问题；中严重度且很可能值得在合并前修复的问题；较低严重度或可等待的后续事项。审查应保持简洁，发现应可执行且有证据支撑。若没有实质性问题，直接说明，不要制造反馈。
第五步：建议明确的后续路径。在发现之后给出简短路径：合并前应修复什么、有时间可改进什么、什么可以安全地保持不变。必要时把路径划分为立即修复、尽快修复、可选后续。
限制
该技能不实现修复，输出仅为只读审查加优先级建议。分类和适用场景说明：它面向代码审查场景，可与仓库工作流配合使用。资料未提供具体安装命令、支持平台、收费方式或性能数据，这些信息暂未提供。