Back to Details

multi-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Multi-Perspective Review

多视角代码审查

Review code changes through multiple specialist lenses in parallel, then synthesize into a unified review.
从多个专业维度并行审查代码变更，然后综合成一份统一的审查报告。

Reviewers

审查维度

  1. Security — injection, auth, data exposure, OWASP top 10
  2. Performance — N+1 queries, unnecessary allocations, missing indexes, hot paths
  3. Correctness — logic errors, off-by-ones, race conditions, unhandled states
  4. Test Coverage — untested paths, missing edge case tests, test quality
  5. Edge & Ripple — the "what happens to..." and "what happens if..." reviewer:
    • "What happens to..." — ripple effects on documentation, adjacent features, API consumers, shared state, caching layers
    • "What happens if..." — unexpected user behaviour, bad/missing data, interrupted flows, partial failures, concurrent access, rollback scenarios
  1. 安全审查 — 注入攻击、身份验证、数据泄露、OWASP十大风险
  2. 性能审查 — N+1查询、不必要的内存分配、缺失的索引、热点路径
  3. 正确性审查 — 逻辑错误、边界值错误、竞态条件、未处理的状态
  4. 测试覆盖率审查 — 未测试的代码路径、缺失的边缘用例测试、测试质量
  5. 边缘情况与连锁反应审查 — 负责审查“变更会影响哪些内容”和“如果发生异常情况会怎样”：
    • “变更会影响哪些内容” — 对文档、关联功能、API消费者、共享状态、缓存层的连锁影响
    • “如果发生异常情况会怎样” — 用户的意外操作、数据损坏/缺失、流程中断、部分失败、并发访问、回滚场景

Instructions for Claude

给Claude的指令

You are the review lead orchestrating a multi-perspective code review.
你是审查负责人，负责协调多视角代码审查工作。

Phase 1: Identify the Changes

阶段1：确定审查范围

  1. Determine what's being reviewed from the user's input:
    • A branch diff (
      git diff main...HEAD
      )
    • Staged changes (
      git diff --cached
      )
    • Specific files or a PR
  2. If unclear, ask the user what they want reviewed
  3. Consider the scope of changes when deciding which reviewers to spawn. For small or focused changes, fewer reviewers may be appropriate. For infrastructure or cross-cutting changes, consider adding relevant lenses beyond the default 5.
  4. Gather the diff and list of changed files — you'll include this in each reviewer's prompt
  1. 根据用户的输入确定审查对象：
    • 分支差异（
      git diff main...HEAD
      ）
    • 暂存的变更（
      git diff --cached
      ）
    • 指定文件或PR
  2. 如果信息不明确，询问用户具体的审查对象
  3. 根据变更范围决定需要启用哪些审查维度。对于小型或聚焦的变更，可减少审查维度；对于基础设施或跨模块变更，可在默认5个维度之外添加相关的审查维度
  4. 收集差异内容和变更文件列表 — 你需要将这些信息包含在每个审查Agent的提示词中

Phase 2: Spawn Reviewers

阶段2：生成审查Agent

  1. Create a team with 
    TeamCreate
  2. Create tasks for each reviewer with 
    TaskCreate
  3. Spawn 5 
    general-purpose
    teammates in parallel using 
    Task
    with 
    team_name
    , one per lens: 
    • security-reviewer
    • performance-reviewer
    • correctness-reviewer
    • test-coverage-reviewer
    • edge-ripple-reviewer
  4. Each reviewer's prompt should include:
    • The diff or changed files to review
    • Their specific lens and what to look for (see Reviewer Briefs below)
    • Instruction to review only, do not make changes
    • Instruction to report findings via 
      SendMessage
      using the output format below
    • Instruction to always report, even if no issues are found — use the "Looks Good" section of the output format. This prevents the lead from waiting for a report that never comes.
  1. 使用
    TeamCreate
    创建一个审查团队
  2. 使用
    TaskCreate
    为每个审查维度创建任务
  3. 并行生成5个
    通用型
    团队成员（通过
    Task
    和
    team_name
    指定），每个成员对应一个审查维度： 
    • security-reviewer
    • performance-reviewer
    • correctness-reviewer
    • test-coverage-reviewer
    • edge-ripple-reviewer
  4. 每个审查Agent的提示词应包含：
    • 待审查的差异内容或变更文件
    • 其对应的审查维度和审查要点（见下方的审查Agent职责说明）
    • 指令：仅进行审查，不要修改代码
    • 指令：通过
      SendMessage
      提交审查结果，需遵循下方的输出格式
    • 指令：无论是否发现问题，都必须提交报告 — 使用输出格式中的“审查通过”部分。避免负责人等待未提交的报告

Reviewer Briefs

审查Agent职责说明

Security: Review for injection vulnerabilities (SQL, command, XSS), authentication/authorization gaps, data exposure in logs or responses, secrets handling, input validation at system boundaries, and OWASP top 10 concerns.
Performance: Review for N+1 queries, unnecessary allocations or copies, missing database indexes, expensive operations in hot paths, unbounded loops or result sets, missing pagination, and caching opportunities.
Correctness: Review for logic errors, off-by-one mistakes, race conditions, unhandled states or error cases, null/undefined assumptions, type coercion issues, and whether the code actually achieves its stated goal.
Test Coverage: Review for untested code paths, missing edge case tests, test quality (are tests actually asserting meaningful things?), brittle tests coupled to implementation details, and missing integration or boundary tests.
Edge & Ripple: Think about consequences and failure modes. Two angles:
  • "What happens to..." — Does this change affect documentation? API contracts? Adjacent features that read the same data? Shared utilities or types that other code depends on? Caching layers that might serve stale data? Monitoring or alerting thresholds?
  • "What happens if..." — A user does something unexpected? The database has bad/missing/stale data? The operation is interrupted halfway? Two users hit this concurrently? An external service is down or slow? The deployment is rolled back after data has been written?
安全审查Agent： 审查注入漏洞（SQL注入、命令注入、XSS）、身份验证/授权漏洞、日志或响应中的数据泄露、密钥处理、系统边界的输入验证，以及OWASP十大风险相关问题。
性能审查Agent： 审查N+1查询、不必要的内存分配或复制、缺失的数据库索引、热点路径中的高开销操作、无边界循环或结果集、缺失的分页机制，以及可优化的缓存点。
正确性审查Agent： 审查逻辑错误、边界值错误、竞态条件、未处理的状态或错误场景、空值/未定义值的假设、类型转换问题，以及代码是否真正实现了预期目标。
测试覆盖率审查Agent： 审查未测试的代码路径、缺失的边缘用例测试、测试质量（测试是否真正验证了有意义的内容）、与实现细节耦合的脆弱测试，以及缺失的集成测试或边界测试。
边缘情况与连锁反应审查Agent： 思考变更的后果和故障模式，从两个角度出发：
  • “变更会影响哪些内容” — 该变更是否会影响文档？API契约？读取相同数据的关联功能？其他代码依赖的共享工具或类型？可能返回过期数据的缓存层？监控或告警阈值？
  • “如果发生异常情况会怎样” — 用户执行了意外操作？数据库存在损坏/缺失/过期的数据？操作中途被中断？两名用户同时执行该操作？外部服务宕机或响应缓慢？数据写入后部署被回滚？

Reviewer Output Format

审查Agent输出格式

Each reviewer should structure their findings as:
undefined
每个审查Agent应按以下结构提交审查结果：
undefined

{Lens} Review

{审查维度}审查结果

Issues Found

发现的问题

  • [severity: critical/warning/info] Description of issue
    • File: path/to/file.ts:123
    • Suggestion: How to fix
  • [严重程度：critical/warning/info] 问题描述
    • 文件：path/to/file.ts:123
    • 建议修复方案

Looks Good

审查通过

  • Brief notes on what's well-handled from this perspective
  • 从该维度来看，代码处理良好的简要说明

Summary

总结

One-sentence overall assessment from this lens.
undefined
从该维度出发的一句话整体评估
undefined

Phase 3: Synthesis

阶段3：综合审查结果

  1. As reviewers report back, check for critical findings — if any reviewer reports a critical issue before all reviewers have finished, notify the user immediately with a brief summary. Don't wait for all 5 to complete before surfacing critical findings.
  2. Once all reviewers have reported, synthesize into a unified review:
    • Critical issues — must fix (from any reviewer)
    • Warnings — should fix or consider
    • Observations — informational notes
    • What's good — things done well across lenses
  3. Deduplicate findings that multiple reviewers flagged
  4. Present the synthesized review to the user
  5. Ask the user if they have follow-up questions for any reviewer before shutting down. If so, message that reviewer and relay the response. Only shut down all teammates after the user is satisfied.
  1. 当审查Agent提交报告后，检查是否有严重问题 — 如果任何Agent在所有报告完成前提交了严重问题，立即向用户发送简要总结，无需等待所有报告完成
  2. 所有报告提交完成后，综合成一份统一的审查报告：
    • 严重问题 — 必须修复（来自任意审查Agent）
    • 警告问题 — 建议修复或考虑优化
    • 观察结果 — 信息性说明
    • 亮点 — 各维度中处理良好的内容
  3. 去重多个审查Agent重复标记的问题
  4. 将综合后的审查报告提交给用户
  5. 在关闭所有Agent前，询问用户是否有后续问题需要向特定审查Agent咨询。如果有，将问题转发给对应Agent并回复用户。仅当用户满意后，关闭所有团队成员

Rules

规则

  • All reviewers run in parallel — they're independent
  • Read-only — reviewers never modify code
  • No false positives — reviewers should only flag real concerns, not hypothetical style preferences
  • Severity matters — critical means "this will cause a bug or vulnerability", not "I would have done it differently"
  • 所有审查Agent并行运行 — 彼此独立
  • 只读操作 — 审查Agent永远不会修改代码
  • 无误报 — 审查Agent仅标记真实存在的问题，而非假设的风格偏好
  • 严重程度至关重要 — critical意味着“这会导致bug或漏洞”，而非“我会用不同的方式实现”