# Review Swarm

> 并行只读多智能体审查当前 git diff 或指定文件范围，发现行为回归、安全或隐私风险、性能或可靠性问题，以及契约或测试覆盖缺口。当用户要求审查集群、并行审查、diff 审查、代码审查集群、review swarm、parallel review、diff review 时使用。

- Skill: `kscz0000/review-swarm` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kscz0000/review-swarm`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/review-swarm/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/review-swarm

---


# 审查集群
## 何时使用

当需要对当前 git diff 或指定文件范围进行并行只读多智能体审查，以发现行为回归、安全或隐私风险、性能或可靠性问题，以及契约或测试覆盖缺口时使用此技能。当用户要求审查集群、并行审查、diff 审查时使用。


用四个只读子智能体并行审查一个 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. 缺失或削弱的认证或授权检查
2. 不安全的输入处理、注入风险或验证缺口
3. 密钥、令牌或敏感数据暴露
4. 危险的默认值、权限扩大或对未验证数据的信任

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

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

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

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

检查：

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

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

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

### 子智能体 4：契约与覆盖审查

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

检查：

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

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

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

仅报告对正确性、安全性、隐私、可靠性、兼容性或对变更的信心有实质性影响的问题。宁可漏掉一个小问题，也不要用低价值噪音淹没用户。

## 步骤 3：汇总和过滤发现

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

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

- 去除重复项
- 去除薄弱或推测性的断言
- 去除与声明意图冲突的问题
- 去除次要的风格或可读性意见，除非它们掩盖了真正的 bug 或维护风险

将存活的发现规范化为此格式：

1. 文件和行号或最近符号
2. 类别：regression、security、reliability 或 contracts
3. 严重程度：high、medium 或 low
4. 为何重要
5. 建议的修复或后续操作
6. 置信度：high、medium 或 low

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

## 步骤 4：排序输出

按以下顺序呈现发现：

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

保持审查简洁。发现应当可操作且有证据支撑。

如果没有实质性问题，直接说明，而非制造反馈。

## 步骤 5：推荐明确的前进路径

在发现之后，给用户简短的前进路径：

- 合并前必须修复的
- 如果时间允许应改进的
- 可以安全搁置的

适当时将前进路径分组为：

- `fix now`
- `fix soon`
- `optional follow-up`

不要在此技能中实施修复。输出是只读审查加优先级推荐。

## 局限性

- 仅当任务明确匹配其上游来源和本地项目上下文时使用此技能。
- 在应用变更之前，验证命令、生成的代码、依赖项、凭证和外部服务行为。
- 不要将示例替代为环境特定的测试、安全审查或用户对破坏性或高成本操作的批准。