review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review

审查

Overview

概述

Use this skill to review uncommitted changes in the current git workspace.
Focus on correctness, safety, maintainability, and alignment with project standards.

The review must produce:

A concise summary of what changed
Prioritized findings with severity labels
Actionable fix suggestions
A final verdict (
```
Approve
```
or
```
Request Changes
```
)

使用此技能审查当前Git工作区中的未提交变更。
重点关注正确性、安全性、可维护性以及是否符合项目标准。

审查必须生成以下内容：

变更内容的简洁摘要
带有严重等级标签的优先级审查结果
可执行的修复建议
最终结论（
```
Approve
```
或
```
Request Changes
```
）

Workflow

工作流程

Step 1: Gather Context

步骤1：收集上下文

Inspect current changes:
- ```
git diff
```
- ```
git diff --cached
```
  (if staged changes exist)
Read the full modified files (not only the diff hunks) to understand surrounding logic and architecture.

Check project documentation before judging style/patterns:

```
docs/code-standard.md
```
```
docs/architecture.md
```
```
docs/codebase.md
```
```
docs/project-pdr.md
```

Run relevant quality checks for touched areas (lint/type/tests when practical).

检查当前变更：
- ```
git diff
```
- ```
git diff --cached
```
  （若存在已暂存的变更）
阅读完整的修改文件（不仅是差异片段），以理解周边逻辑和架构。

在判断代码风格/模式前查阅项目文档：

```
docs/code-standard.md
```
```
docs/architecture.md
```
```
docs/codebase.md
```
```
docs/project-pdr.md
```

对涉及的代码区域运行相关质量检查（在可行情况下进行 lint/类型检查/测试）。

Step 2: Analyze Changes

步骤2：分析变更

Evaluate each change across these dimensions:

Correctness - Does behavior match intended requirements?
Safety & Security - Are there vulnerabilities, data leaks, auth gaps, or unsafe assumptions?
Reliability - Are edge cases, null states, retries, and error paths handled?
Style & Consistency - Does code follow project conventions and established patterns?
Performance - Any unnecessary expensive operations or regressions?
Testing - Are critical paths covered with appropriate tests?
Maintainability - Is the code clear, modular, and easy to evolve?

从以下维度评估每一项变更：

正确性 - 行为是否符合预期需求？
安全与保密性 - 是否存在漏洞、数据泄露、认证缺口或不安全的假设？
可靠性 - 是否处理了边缘情况、空值状态、重试机制和错误路径？
风格与一致性 - 代码是否遵循项目约定和既定模式？
性能 - 是否存在不必要的高开销操作或性能退化？
测试 - 关键路径是否有适当的测试覆盖？
可维护性 - 代码是否清晰、模块化且易于演进？

Step 3: Classify Findings by Severity

步骤3：按严重等级分类审查结果

Assign one severity per finding using this rubric:

S0 - Critical
- Production-breaking issue, severe security risk, data corruption/loss, or irreversible side effects
- Must be fixed before merge
S1 - High
- Likely bug, correctness flaw, significant reliability issue, or major missing validation
- Should be fixed before merge
S2 - Medium
- Non-blocking but meaningful issue affecting maintainability, performance, or clarity
- Fix recommended soon
S3 - Low
- Minor improvement, polish, or style-level suggestion
- Optional unless team standards require it

使用以下标准为每个审查结果分配一个严重等级：

S0 - 关键
- 会导致生产环境故障、严重安全风险、数据损坏/丢失或不可逆副作用的问题
- 合并前必须修复
S1 - 高
- 可能存在的bug、正确性缺陷、重大可靠性问题或严重缺失的验证
- 合并前应修复
S2 - 中
- 不阻塞合并但会影响可维护性、性能或清晰度的重要问题
- 建议尽快修复
S3 - 低
- 微小改进、优化或风格层面的建议
- 除非团队标准强制要求，否则为可选修复

Step 4: Produce Structured Review Report

步骤4：生成结构化审查报告

Use the report format below in this exact section order.

使用以下报告格式，严格按照此章节顺序呈现。

Output Format

输出格式

1) Summary

1) 摘要

What changed (2-6 bullets)
Risk profile (low/medium/high)
Areas reviewed (files/modules)

变更内容（2-6个要点）
风险等级（低/中/高）
审查范围（文件/模块）

2) Findings

2) 审查结果

For each finding, use this template:

ID:
```
R-001
```
(incrementing)
Severity:
```
S0 | S1 | S2 | S3
```

Category:

Correctness | Security | Reliability | Style | Performance | Testing | Maintainability

Location:
```
path/to/file.ext#Lx-Ly
```
(or function/class name)
Issue: Clear statement of the problem
Why it matters: User/system impact
Suggestion: Concrete fix guidance
Confidence:
```
High | Medium | Low
```

If no findings exist, explicitly write: No actionable findings.

每个审查结果使用以下模板：

ID:
```
R-001
```
（递增编号）
Severity:
```
S0 | S1 | S2 | S3
```

Category:

Correctness | Security | Reliability | Style | Performance | Testing | Maintainability

Location:
```
path/to/file.ext#Lx-Ly
```
（或函数/类名）
Issue: 问题的清晰描述
Why it matters: 对用户/系统的影响
Suggestion: 具体的修复指导
Confidence:
```
High | Medium | Low
```

若没有审查结果，请明确写出：无可行动的审查结果。

3) Positive Notes

3) 正面评价

List good practices observed, such as:

Strong test coverage additions
Clean separation of concerns
Thoughtful error handling
Consistent style and naming

列出观察到的良好实践，例如：

新增了完善的测试覆盖
关注点分离清晰
错误处理考虑周全
风格和命名保持一致

4) Must-Fix Checklist

4) 必须修复的检查清单

Include only

S0

and

S1

findings:

```
R-00X
```
short fix description
```
R-00Y
```
short fix description

If none, state: No must-fix items.

仅包含

S0

和

S1

级别的审查结果：

```
R-00X
```
简短的修复描述
```
R-00Y
```
简短的修复描述

若无此类问题，请说明：无必须修复的项。

5) Verdict

5) 结论

Use one of:

Approve - No blocking issues (
```
S0/S1
```
) remain.
Request Changes - One or more blocking issues (
```
S0/S1
```
) found.

Optionally include:

Re-review focus: exact files/areas to re-check after fixes.

使用以下其中一种：

Approve - 不存在阻塞性问题（
```
S0/S1
```
）。
Request Changes - 发现一个或多个阻塞性问题（
```
S0/S1
```
）。

可选补充：

Re-review focus: 修复后需重新检查的具体文件/区域。

Rules

规则

Be specific and cite exact locations whenever possible.
Do not judge code in isolation; always consider surrounding context.
Prefer actionable suggestions over vague criticism.
Distinguish clearly between blocking and non-blocking feedback.
Avoid speculative claims; if uncertain, lower confidence and explain why.
Align feedback with project documentation and coding standards.

尽可能具体并引用确切位置。
不要孤立地评判代码；始终考虑周边上下文。
优先提供可执行的建议，而非模糊的批评。
明确区分阻塞性和非阻塞性反馈。
避免推测性声明；若不确定，降低置信度并说明原因。
反馈需与项目文档和编码标准保持一致。

Review Quality Checklist

审查质量检查清单

Before finalizing, confirm:

All modified files were reviewed with context
Each finding has severity, impact, and fix suggestion
Blocking issues are separated into a must-fix checklist
Final verdict matches the finding severities
Feedback is concise, precise, and implementable

最终确定前，请确认：

所有修改文件均结合上下文进行了审查
每个审查结果都包含严重等级、影响和修复建议
阻塞性问题已分离到必须修复的检查清单中
最终结论与审查结果的严重等级匹配
反馈简洁、准确且可落地