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
```
)

Workflow

Step 1: Gather Context

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).

Step 2: Analyze Changes

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

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

review

NPX Install

Tags

SKILL.md Content