code-review-and-quality

Code Review and Quality — Multidimensional Code Quality Assessment Skill

Skill Overview

The Code Review and Quality skill provides a systematic five-axis code review framework to help developers comprehensively assess correctness, readability, architecture, security, and performance before merging, thereby establishing effective code quality gates.

Applicable Scenarios

1. Pre-Merge Code Review

Conduct a systematic review before submitting a Pull Request or merging code to ensure that all changes undergo quality checks. This skill provides a clear review process and evaluation criteria to help teams establish consistent code review standards.

2. Review of AI-Generated Code

When using AI tools such as Claude or GPT to generate code, more rigorous review is required. AI-generated code may appear correct while containing hidden risks. This skill provides targeted review points and a multi-model collaborative review approach.

3. Review of Refactoring and Bug Fixes

Refactoring and bug fixes often introduce new problems. This skill reviews not only the fix itself, but also checks for architectural issues, performance bottlenecks, and security vulnerabilities, while identifying dead code that can be removed.

Core Features

Five-Axis Code Review Framework

Comprehensively evaluate code quality across five dimensions:

Correctness: Check whether the code meets requirements and handles edge cases and error paths.

Readability: Assess whether the code is easy to understand, whether naming is clear, and whether the logic is concise.

Architecture: Review whether the code is properly decomposed, whether it is overengineered, and whether it reduces rather than shifts complexity.

Security: Check key security concerns such as input validation, access control, and dependency management.

Performance: Identify performance issues such as N+1 queries, unbounded loops, and unnecessary synchronous operations.

Structured Recommendations and Fixes

When code issues are found, provide not only the location of the problem but also specific refactoring recommendations:

Replace conditional chains with type models.

Collapse duplicate branches into a single flow.

Separate orchestration from business logic.

Reuse existing convention helpers instead of creating duplicate custom solutions.

Clarify type boundaries to simplify downstream control flow.

Change Size and Dependency Management

Provide best-practice guidance for PR size and dependency review processes:

Recommend approximately 100 lines of code per change; changes exceeding 1,000 lines should be split.

Check total file size, not just the number of changed lines.

Review dependency upgrades individually and read changelogs rather than looking only at version numbers.

Review lockfile differences and pay attention to transitive dependency changes.

Prevent bulk dependency upgrades from obscuring the root cause of problems.

Frequently Asked Questions

What should be checked during a code review?

A code review should cover five dimensions: correctness (whether the code implements the requirements and handles edge cases), readability (whether naming is clear and the logic is simple), architecture (whether the code is properly decomposed without overengineering), security (input validation, access control, and the absence of injection vulnerabilities), and performance (no N+1 queries or unbounded loops). Do not check only whether the tests pass; tests are necessary but not sufficient.

How should disagreements in code reviews be handled?

When resolving disagreements in code reviews, follow a hierarchy: technical facts and data take precedence over opinions and preferences; style guides are the ultimate authority on style issues; software design must be based on engineering principles rather than personal preferences; if a change does not reduce overall code health, maintaining consistency across the codebase is acceptable. Do not accept “we’ll clean it up later”—experience shows that deferred cleanup rarely happens.

How should code review severity be labeled?

Use clear labels to distinguish issue priority:

No prefix indicates a Required issue that must be fixed.

Critical indicates a severe issue that blocks merging, such as a security vulnerability, data loss, or broken functionality.

Nit indicates an optional style issue.

Optional/Consider indicates a suggestion worth considering.

FYI indicates information provided solely for future reference.

This allows authors to distinguish mandatory fixes from optional suggestions and improves review efficiency.