Code Review and Quality Assessment

The Problem It Solves

Code review often degrades into a shallow pass-fail check: comments lack priority, authors cannot tell which feedback is mandatory, and large changes become hard to evaluate. AI-generated code is especially risky because it can look plausible while hiding edge-case, security, or performance problems. This skill turns review into a concrete quality gate. The goal is not perfect code, but a change that reliably improves overall code health without breaking conventions or introducing hidden debt.

How It Works

The skill evaluates changes across five axes:

• Correctness: whether behavior matches the requirement, and whether edge cases, error paths, race conditions, and state consistency are handled.
• Readability and simplicity: whether naming, control flow, module organization, and abstraction depth are understandable without the author explaining them.
• Architecture: whether module boundaries, dependency direction, duplication, and coupling fit the system design.
• Security: whether input validation, secrets handling, authorization, parameterized queries, output encoding, and untrusted external data are addressed.
• Performance: whether changes introduce N+1 queries, unbounded loops, blocking operations, missing pagination, or large allocations in hot paths.

The workflow starts by understanding intent, then reviews tests before implementation, then walks through the code using the five axes. Feedback is labeled by severity so authors can distinguish required fixes from optional suggestions. For example, Critical: blocks merge, Nit: is optional style feedback, and Optional: or Consider: is a suggestion. The skill also emphasizes small, focused changes, clear change descriptions, dependency discipline, dead-code hygiene, and a final verification checklist covering resolved critical issues, passing tests, successful build, and documented verification.

Boundaries and Caveats

This skill is best used before merging a PR, after implementing a feature, after refactoring, after bug fixes, and when reviewing code produced by another engineer or model. It is a review process and decision framework, not a substitute for project-specific architecture rules, security policies, or benchmark-driven performance requirements. When disagreement occurs, technical facts, style guides, and engineering principles should take precedence over personal preference. If the author has full context and disagrees with a suggestion, the review should focus on the code, not the person.