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

Synthesize into a single excellent review

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

When sub-agent results arrive, produce a consolidated review with:

Summary (what changed + overall risk)
Issues
Questions (unknown intent; ask for clarification)
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返回结果后，生成一份整合的评审报告，包含：

摘要（变更内容 + 整体风险）
问题项
疑问（意图不明确的地方，请求澄清）
建议验证方案（命令 + 手动检查）

问题项需标注严重程度，格式如下：

严重程度	描述	示例
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）。
给出模糊反馈（如“看起来不错”），而无可落地项与文件路径。
提出无法验证的建议（始终包含验证方案）。
以评审为借口扩大范围（除非风险要求，否则聚焦最小变更）。