as-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.
Load project context per the shared Context Loading Protocol before judging style/patterns.
Run relevant quality checks for touched areas (lint/type/tests when practical).

检查当前变更：
- ```
git diff
```
- ```
git diff --cached
```
  （如果存在暂存变更）
读取完整的修改文件（不仅是diff片段），理解周边逻辑和架构设计。
评判代码风格/模式前，按照共享的上下文加载协议加载项目上下文。
针对修改的区域运行相关质量检查（可行时执行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 - 高
- 大概率存在的漏洞、正确性缺陷、显著可靠性问题或缺失重要校验
- 合并前应当修复
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:

正确性 | 安全 | 可靠性 | 风格 | 性能 | 测试 | 可维护性

位置:
```
path/to/file.ext#Lx-Ly
```
（或函数/类名）
问题: 清晰的问题描述
影响说明: 对用户/系统的影响
修复建议: 具体的修复指导
置信度:
```
高 | 中 | 低
```

如果没有问题，明确标注：无待处理问题。

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 - 发现1个或多个阻塞性问题（
```
S0/S1
```
）

可选择性补充：

重审重点: 修复后需要重新检查的具体文件/区域。

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

最终确认前，请检查：

所有修改文件已结合上下文完成评审
每个问题都标注了严重级别、影响和修复建议
阻塞性问题已单独整理到必须修复清单
最终结论与问题严重级别匹配
反馈简洁、准确、可落地