code-review-and-quality

Reviews code changes across correctness, readability, architecture, security, and performance before merge.

1|Updated Sep 4, 2026
One-click install
npx skills add https://github.com/SanHsien/agent-skills --skill code-review-and-quality-sanhsien
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review-and-quality
Source: https://github.com/SanHsien/agent-skills/tree/main/skills/code-review-and-quality
Command: npx skills add https://github.com/SanHsien/agent-skills --skill code-review-and-quality-sanhsien

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code merged without structured review accumulates defects, security vulnerabilities, and architectural debt. This Skill enforces a consistent multi-axis review process so every change is evaluated against the same quality gates before entering the main branch. ## Core Features & Use Cases - Five-Axis Review: Evaluates every change for correctness, readability, architecture, security, and performance with concrete checklists per axis. - Severity-Labeled Feedback: Categorizes findings as Critical, Required, Nit, Optional, or FYI so authors know exactly what must be addressed before merge. - Change Sizing and Dependency Discipline: Enforces small reviewable changes, separates refactoring from feature work, and requires changelog review with one-dependency-per-change upgrades. - Use Case: Before merging a pull request that adds a new API endpoint, run this review to verify tests cover edge cases, inputs are validated at boundaries, no N+1 queries exist, and the change description stands alone in version control history. ## Quick Start Review the current uncommitted changes or the specified pull request using the five-axis code review checklist and report findings with severity labels.

Frequently Asked Questions about code-review-and-quality

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a pull request before merging?

Review the tests first to understand intent, then walk each changed file across five axes: correctness, readability, architecture, security, and performance. Label every finding with a severity prefix like Critical, Nit, or Optional so the author knows what must be addressed before merge.

What should a code review checklist include?

A code review checklist should cover correctness against the spec, edge case and error path handling, clear naming, architectural fit, input validation and secret hygiene, and performance issues like N+1 queries. It should end with verification that tests pass and the build succeeds.

How large should a pull request be for effective review?

Around 100 changed lines is ideal and reviewable in one sitting; 300 lines is acceptable for a single logical change. Around 1000 changed lines is too large and should be split by stacking, file groups, or horizontal and vertical slicing.

How do I review dependency upgrades safely?

Read the changelog rather than trusting semver, upgrade one dependency per change so failures are attributable, and verify with a green test suite before and after. Review the lockfile diff for transitive changes and never hand-edit the lockfile.

When should a code review request changes instead of approving?

Request changes when there are Critical issues like security vulnerabilities or broken functionality, or unresolved Required findings. Approve when the change improves overall code health even if imperfect, since the standard is continuous improvement rather than perfection.