as-review（作为评论）

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:

1. A concise summary of what changed
2. Prioritized findings with severity labels
3. Actionable fix suggestions
4. A final verdict (Approve or Request Changes)

Workflow

Step 1: Gather Context

1. Inspect current changes:

- git diff - git diff --cached (if staged changes exist)

1. Read the full modified files (not only the diff hunks) to understand surrounding logic and architecture.
2. Load project context per the shared Context Loading Protocol before judging style/patterns.
3. Run relevant quality checks for touched areas (lint/type/tests when practical).

Step 2: Analyze Changes

Evaluate each change across these dimensions:

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

Step 3: Classify Findings by Severity

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

Step 4: Produce Structured Review Report

Use the report format below in this exact section order.

Output Format

1) Summary

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

2) Findings

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.

3) Positive Notes

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

Include only S0 and S1 findings:

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

If none, state: No must-fix items.

5) Verdict

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.

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