Back to Details

review-swarm

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review Swarm

评审群（Review Swarm）

Review a diff with four read-only sub-agents in parallel, then have the main agent filter, order, and summarize only the issues that matter. This skill is review-only: sub-agents do not edit files, and the main agent does not apply fixes as part of this workflow.
通过四个只读子Agent并行评审diff，再由主Agent筛选、排序并仅汇总重要问题。本技能仅用于评审：子Agent不会编辑文件，主Agent也不会在该工作流中应用修复。

Step 1: Determine Scope and Intent

步骤1：确定评审范围与意图

Prefer this scope order:
  1. Files or paths explicitly named by the user
  2. Current git changes
  3. An explicit branch, commit, or PR diff requested by the user
  4. Most recently modified tracked files, only if the user asked for a review and there is no clearer diff
If there is no clear review scope, stop and say so briefly.
When using git changes, choose the smallest correct diff command:
  • unstaged work: 
    git diff
  • staged work: 
    git diff --cached
  • mixed staged and unstaged work: review both
  • explicit branch or commit comparison: use exactly what the user requested
Before launching reviewers, read the closest local instructions and any relevant project docs for the touched area, such as:
  • AGENTS.md
  • repo workflow docs
  • architecture or contract docs for the touched module
Build a short intent packet for the reviewers:
  1. What behavior is meant to change
  2. What behavior should remain unchanged
  3. Any stated or inferred constraints, such as compatibility, rollout, security, or migration expectations
If the user did not state the intent clearly, infer it from the diff and say that the inference may be incomplete.
优先按以下顺序确定范围：
  1. 用户明确指定的文件或路径
  2. 当前git变更
  3. 用户要求的指定分支、提交或PR diff
  4. 仅当用户明确要求评审且无更明确diff时，选择最近修改的已跟踪文件
如果没有明确的评审范围，直接简短告知用户即可。
使用git变更时，选择最简适配的diff命令：
  • 未暂存的工作：
    git diff
  • 已暂存的工作：
    git diff --cached
  • 暂存与未暂存混合的工作：两者都评审
  • 指定分支或提交对比：完全按照用户要求使用命令
启动评审前，先阅读本地最相关的说明和所修改内容对应的项目文档，例如：
  • AGENTS.md
  • 仓库工作流文档
  • 所修改模块的架构或合约文档
为评审者构建简短的意图包：
  1. 计划修改的行为是什么
  2. 哪些行为应该保持不变
  3. 任何明确或推断出的约束，例如兼容性、上线、安全或迁移预期
如果用户未明确说明意图，可从diff中推断，但需说明推断可能不完整。

Step 2: Launch Four Read-Only Reviewers in Parallel

步骤2：并行启动四个只读评审Agent

Launch four sub-agents when the scope is large enough for parallel review to help. For a tiny diff or one very small file, it is acceptable to review locally instead.
For every sub-agent:
  • give the same scope and the same intent packet
  • state that the sub-agent is read-only
  • do not let the sub-agent edit files, run 
    apply_patch
    , stage changes, commit, or perform any other state-mutating action
  • ask for concise findings only
  • ask for: file and line or symbol, issue, why it matters, recommended follow-up, and confidence
  • tell the sub-agent to avoid nits, style preferences, and speculative concerns without concrete impact
  • tell the sub-agent to send findings back to the main agent only
Use these four review roles.
当评审范围足够大、并行评审可提升效率时，启动四个子Agent。如果是极小的diff或单个很小的文件，也可以直接本地评审。
对每个子Agent：
  • 提供相同的评审范围和相同的意图包
  • 明确告知子Agent是只读模式
  • 禁止子Agent编辑文件、运行
    apply_patch
    、暂存变更、提交或执行任何其他修改状态的操作
  • 仅要求输出简洁的发现结果
  • 要求返回内容包含：文件与行号/符号、问题、影响、建议后续动作、置信度
  • 告知子Agent无需输出细枝末节的优化建议、风格偏好、无具体影响的推测性问题
  • 告知子Agent仅将发现结果返回给主Agent
使用以下四个评审角色：

Sub-Agent 1: Intent and Regression Review

子Agent 1：意图与回归评审

Review whether the diff matches the intended behavior change without introducing extra behavior drift.
Check for:
  1. Unintended behavior changes outside the stated scope
  2. Broken edge cases or fallback paths
  3. Contract drift between callers and callees
  4. Missing updates to adjacent flows that should change together
This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.
Recommended sub-agent role: 
reviewer
评审diff是否符合预期的行为变更，且未引入额外的行为偏移。
检查项：
  1. 超出指定范围的非预期行为变更
  2. 损坏的边缘场景或兜底路径
  3. 调用方与被调用方之间的合约偏移
  4. 应该同步修改的关联流程未更新
该子Agent为只读模式，不得编辑文件、应用补丁或修改任何工作区内容。
推荐子Agent角色：
reviewer

Sub-Agent 2: Security and Privacy Review

子Agent 2：安全与隐私评审

Review the diff for security regressions, privacy risks, and trust-boundary mistakes.
Check for:
  1. Missing or weakened authn or authz checks
  2. Unsafe input handling, injection risks, or validation gaps
  3. Secret, token, or sensitive data exposure
  4. Risky defaults, permission expansion, or trust of unverified data
This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.
Recommended sub-agent role: 
reviewer
评审diff中的安全回归、隐私风险、信任边界错误。
检查项：
  1. 缺失或被削弱的身份验证/授权检查
  2. 不安全的输入处理、注入风险、验证缺口
  3. 密钥、Token或敏感数据泄露
  4. 高风险默认配置、权限放大、信任未验证数据
该子Agent为只读模式，不得编辑文件、应用补丁或修改任何工作区内容。
推荐子Agent角色：
reviewer

Sub-Agent 3: Performance and Reliability Review

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

Review the diff for new cost, fragility, or operational risk.
Check for:
  1. Duplicate work, redundant I/O, or unnecessary recomputation
  2. Added work on startup, render, request, or other hot paths
  3. Leaks, missing cleanup, retry storms, or subscription drift
  4. Ordering, race, or failure-handling problems that make the change brittle
This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.
Recommended sub-agent role: 
reviewer
评审diff引入的新成本、脆弱性或运维风险。
检查项：
  1. 重复工作、冗余I/O、不必要的重复计算
  2. 在启动、渲染、请求或其他热点路径上新增的负载
  3. 资源泄漏、缺失清理、重试风暴、订阅偏移
  4. 会导致变更不稳定的顺序问题、竞态条件、错误处理缺陷
该子Agent为只读模式，不得编辑文件、应用补丁或修改任何工作区内容。
推荐子Agent角色：
reviewer

Sub-Agent 4: Contracts and Coverage Review

子Agent 4：合约与覆盖度评审

Review the diff for compatibility gaps and missing safety nets.
Check for:
  1. API, schema, type, config, or feature-flag mismatches
  2. Migration or backward-compatibility fallout
  3. Missing or weak tests for the changed behavior
  4. Missing logs, metrics, assertions, or error paths that make regressions harder to detect
This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.
Recommended sub-agent role: 
reviewer
Report only issues that materially affect correctness, security, privacy, reliability, compatibility, or confidence in the change. It is better to miss a nit than to bury the user in low-value noise.
评审diff中的兼容性缺口和缺失的安全保障措施。
检查项：
  1. API、Schema、类型、配置、功能开关不匹配
  2. 迁移或向后兼容问题
  3. 变更行为的测试缺失或测试薄弱
  4. 会提高回归排查难度的日志、指标、断言、错误路径缺失
该子Agent为只读模式，不得编辑文件、应用补丁或修改任何工作区内容。
推荐子Agent角色：
reviewer
仅上报对正确性、安全、隐私、可靠性、兼容性或变更可信度有实质影响的问题。宁可遗漏细枝末节的问题，也不要给用户输出大量低价值噪音。

Step 3: Aggregate and Filter Findings

步骤3：汇总与筛选发现结果

The main agent owns synthesis. Treat sub-agent output as raw review input, not final output.
Merge findings across all four reviewers and filter aggressively:
  • drop duplicates
  • drop weak or speculative claims
  • drop issues that conflict with the stated intent
  • drop minor style or readability comments unless they hide a real bug or maintenance risk
Normalize surviving findings into this shape:
  1. File and line or nearest symbol
  2. Category: regression, security, reliability, or contracts
  3. Severity: high, medium, or low
  4. Why it matters
  5. Recommended fix or follow-up
  6. Confidence: high, medium, or low
If a reviewer may be correct but the intent is unclear, turn it into an open question instead of a finding.
主Agent负责结果合成，将子Agent的输出作为原始评审输入，而非最终输出。
合并四个评审者的发现结果并进行严格筛选：
  • 剔除重复项
  • 剔除可信度低或推测性的结论
  • 剔除与明确意图冲突的问题
  • 剔除次要的风格或可读性评论，除非它们隐藏了实际的bug或维护风险
将留存的发现结果标准化为以下格式：
  1. 文件与行号或最近的符号
  2. 类别：回归、安全、可靠性、合约
  3. 严重程度：高、中、低
  4. 影响说明
  5. 建议修复或后续动作
  6. 置信度：高、中、低
如果评审者的结论可能正确但意图不明确，将其转为开放性问题而非确定的发现结果。

Step 4: Order the Output

步骤4：排序输出

Present findings in this order:
  1. High-severity, high-confidence issues
  2. Medium-severity issues that are likely worth fixing before merge
  3. Lower-severity issues or follow-ups that can wait
Keep the review concise. Findings should be actionable and evidence-backed.
If there are no material issues, say that directly instead of manufacturing feedback.
按以下顺序呈现发现结果：
  1. 高严重程度、高置信度的问题
  2. 合并前大概率需要修复的中严重程度问题
  3. 可以延后处理的低严重程度问题或后续优化项
保持评审简洁，发现结果应当可落地、有证据支撑。
如果没有实质问题，直接告知即可，不要编造反馈。

Step 5: Recommend a Clear Path Forward

步骤5：给出明确的后续路径建议

After the findings, give the user a short path forward:
  • what to fix before merge
  • what to improve if time permits
  • what can safely be left alone
When helpful, group the path forward into:
  • fix now
  • fix soon
  • optional follow-up
Do not implement fixes as part of this skill. The output is a read-only review plus a prioritized recommendation.
在发现结果之后，给用户提供简短的后续路径：
  • 合并前需要修复的内容
  • 时间允许的话可以优化的内容
  • 可以放心忽略的内容
有帮助的情况下，可以将后续路径分组为：
  • 立即修复
  • 近期修复
  • 可选后续优化
本技能不实现修复，输出仅为只读评审结果和优先级建议。