code-review-and-quality

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

2|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/MoofonLi/dev-ready --skill code-review-and-quality-moofonli
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review-and-quality
Source: https://github.com/MoofonLi/dev-ready/tree/main/src/dev_ready/templates/claude/skills/code-review-and-quality
Command: npx skills add https://github.com/MoofonLi/dev-ready --skill code-review-and-quality-moofonli

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 across 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 reviewable change sizes, splitting strategies for large PRs, and per-package dependency upgrade review with changelog and lockfile inspection. - 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 this pull request across correctness, readability, architecture, security, and performance, and label each finding by severity.

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 change across five axes: correctness, readability, architecture, security, and performance. Start by understanding the intent, review tests first, then walk the implementation, and label every finding with a severity such as Critical, Required, Nit, or Optional.

What should a code review checklist include?

A review checklist should cover correctness against the spec, edge case and error handling, clear naming, architectural fit, input validation and secret hygiene, N+1 query detection, and verification that tests and builds pass before approval.

How large should a pull request be for effective review?

Around 100 changed lines is ideal, 300 is acceptable for a single logical change, and 1000 lines should be split. Large changes can be split by stacking, file groups, horizontal layers, or vertical feature slices.

How should I review dependency upgrades in a pull request?

Read the changelog rather than trusting semver, upgrade one dependency per change, verify with a green test suite before and after, and review the lockfile diff since a single bump can pull in many transitive changes.

When should a code review request changes instead of approving?

Request changes when Critical or Required findings exist, such as security vulnerabilities, broken functionality, or missing regression tests. Approve when the change improves overall code health even if it is not perfect.