Back to Details

deep-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deep Review Mode

深度评审模式

Provide an excellent code review by defaulting to parallelism.
You should use sub-agents to review the change from multiple angles (correctness, tests, consistency, UX, performance, safety). Each sub-agent should have a focused mandate and return actionable findings with file paths.
默认采用并行机制提供优质的代码评审。
你应当使用sub-agents从多个维度（正确性、测试、一致性、UX、性能、安全性）评审代码变更。每个sub-agent应专注于特定任务，并返回包含文件路径的可落地评审结果。

Step 0: Establish the review surface

步骤0：确定评审范围

Before reviewing, gather context:
  • Identify the change scope: 
    git diff --name-only
    (or the file list the user provides).
  • Skim the diff for intent and risk: 
    git diff
    .
  • Note which layers are touched:
    • UI (React/components/styles)
    • Main process / backend services
    • IPC boundary / shared types
    • Tooling/scripts
    • Docs
    • Tests
If the change is large, split review by module and prioritize high-risk paths.
评审前，先收集上下文信息：
  • 明确变更范围：
    git diff --name-only
    （或用户提供的文件列表）。
  • 快速浏览diff了解变更意图与风险：
    git diff
    。
  • 标记涉及的层级：
    • UI（React/组件/样式）
    • 主进程/后端服务
    • IPC边界/共享类型
    • 工具/脚本
    • 文档
    • 测试
如果变更范围较大，按模块拆分评审，并优先处理高风险路径。

Spawn the right sub-agents (change-type aware)

生成适配变更类型的子Agent

Spawn 2–5 sub-agents depending on scope. Tailor them to the change.
根据变更范围生成2-5个sub-agents，使其适配当前变更。

Suggested sub-agent set

推荐的sub-agent组合

  • Correctness & edge cases (always)
    • Goal: find logic bugs, missing error handling, race conditions, broken invariants.
  • Tests & verification (always)
    • Goal: evaluate test coverage, propose missing tests, suggest commands to validate.
  • Consistency & architecture (usually)
    • Goal: ensure changes match existing patterns, abstractions, and boundaries.
  • UX & accessibility (when UI changed)
    • Goal: keyboard flows, a11y, visual consistency, empty/loading/error states.
  • Performance & reliability (when hot paths / streaming / IO changed)
    • Goal: latency, unnecessary work, blocking calls, memory growth, resilience.
  • Docs & developer experience (when docs/scripts/public API changed)
    • Goal: clarity, correctness, navigation updates, link integrity.
  • 正确性与边界情况（必选）
    • 目标：发现逻辑漏洞、缺失的错误处理、竞态条件、破坏的不变量。
  • 测试与验证（必选）
    • 目标：评估测试覆盖率、提议缺失的测试、建议用于验证的命令。
  • 一致性与架构（通常需要）
    • 目标：确保变更符合现有模式、抽象与边界。
  • UX与可访问性（当UI变更时）
    • 目标：键盘导航流程、a11y、视觉一致性、空状态/加载状态/错误状态。
  • 性能与可靠性（当涉及热路径/流处理/IO操作变更时）
    • 目标：延迟、不必要的操作、阻塞调用、内存增长、弹性。
  • 文档与开发者体验（当文档/脚本/公共API变更时）
    • 目标：清晰度、正确性、导航更新、链接完整性。

Synthesize into a single excellent review

整合为一份优质的评审报告

When sub-agent results arrive, produce a consolidated review with:
  1. Summary (what changed + overall risk)
  2. Issues
  3. Questions (unknown intent; ask for clarification)
  4. Suggested validation plan (commands + manual checks)
Issues should have a severity in form of:
| Severity | Description | Example | |----------|-------------| | P0 | Change must not be merged until resolved | Change would permanently break core workflows if merged. | | P1 | Change should not be merged| New code will not work as expected due to severe bugs| | P2 | Consideration required before merging | The change creates inconsistency / fragility | | P3 | Minor issue | The change introduces a minor issue that may be addressed later | | P4 | Long-term issue | The change raises concerns about long-term maintainability or may break under rare conditions |
当sub-agents返回结果后，生成一份整合的评审报告，包含：
  1. 摘要（变更内容 + 整体风险）
  2. 问题项
  3. 疑问（意图不明确的地方，请求澄清）
  4. 建议验证方案（命令 + 手动检查）
问题项需标注严重程度，格式如下：
严重程度描述示例
P0解决前禁止合并变更若合并会永久破坏核心工作流。
P1解决前不应合并新代码因严重bug无法正常工作
P2合并前需考量变更导致不一致性/脆弱性
P3次要问题变更引入可后续修复的小问题
P4长期问题变更引发对长期可维护性的担忧，或在罕见条件下可能失效

Review rubric

评审准则

Use this rubric to avoid blind spots:
  • Correctness: invariants, edge cases, error handling, races
  • Fitness: does it meet the user goal, and does it match product constraints?
  • Tests: coverage of new logic, regression tests, deterministic behavior
  • Consistency: patterns, naming, types, boundaries, IPC typing
  • Maintainability: complexity, duplication, readability
  • Performance: hot paths, streaming, excessive re-renders/IO
  • Safety: secrets, path traversal, injection risks, filesystem safety
  • DX: logs, error messages, debuggability
使用以下准则避免遗漏：
  • 正确性：不变量、边界情况、错误处理、竞态条件
  • 适配性：是否满足用户目标，是否符合产品约束？
  • 测试：新逻辑的覆盖率、回归测试、确定性行为
  • 一致性：模式、命名、类型、边界、IPC类型定义
  • 可维护性：复杂度、重复代码、可读性
  • 性能：热路径、流处理、过度重渲染/IO操作
  • 安全性：密钥、路径遍历、注入风险、文件系统安全
  • DX：日志、错误信息、可调试性

Anti-patterns

反模式

  • Single-threaded review of a large change (spawn sub-agents).
  • Vague feedback (“looks good”) without actionable items and file paths.
  • Non-verifiable suggestions (always include a validation plan).
  • Scope creep disguised as review (focus on minimal changes unless risk demands more).
  • 对大型变更进行单线程评审（应生成sub-agents）。
  • 给出模糊反馈（如“看起来不错”），而无可落地项与文件路径。
  • 提出无法验证的建议（始终包含验证方案）。
  • 以评审为借口扩大范围（除非风险要求，否则聚焦最小变更）。