review

Original：🇺🇸 English
Translated

Review current uncommitted git changes with full file context and produce a structured report with severity levels, actionable fixes, and an approval verdict.

3installs
Sourcebuiducnhat/agent-skills
Added on

NPX Install

npx skill4agent add buiducnhat/agent-skills review

Tags

Translated version includes tags in frontmatter
git-code-reviewcode-quality-assurancechange-auditreview-workflowseverity-rating

SKILL.md Content

View Translation Comparison →

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)
  2. Read the full modified files (not only the diff hunks) to understand surrounding logic and architecture.
  3. Check project documentation before judging style/patterns: 
    • docs/code-standard.md
    • docs/architecture.md
    • docs/codebase.md
    • docs/project-pdr.md
  4. 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