code-review-and-quality

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

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/MSC72m/DevForge --skill code-review-and-quality-msc72m
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review-and-quality
Source: https://github.com/MSC72m/DevForge/tree/main/skills/code-review-and-quality
Command: npx skills add https://github.com/MSC72m/DevForge --skill code-review-and-quality-msc72m

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 what blocks merge versus what is a suggestion. - Change Sizing and Splitting: Provides diff-size thresholds and splitting strategies (stack, by file group, horizontal, vertical) to keep changes reviewable. - Use Case: Before merging a pull request, run the review checklist to verify tests cover the change, no secrets or injection risks exist, the diff stays under ~300 lines, and dependency upgrades were reviewed against their changelogs. ## 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 a pull request by first understanding its intent, then checking tests, then walking the implementation across five axes: correctness, readability, architecture, security, and performance. Label every finding by severity and finish with an approve or request-changes verdict.

What should a code review checklist include?▼

A code review checklist should cover context understanding, correctness against the spec, edge case and error handling, naming and simplicity, architectural fit, secrets and injection risks, performance patterns like N+1 queries, and verification that tests and builds pass.

How large should a pull request be for review?▼

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

How do I review dependency upgrades safely?▼

Review dependency upgrades by reading the changelog rather than trusting semver, upgrading one dependency per change, verifying a green test suite before and after, and reviewing the lockfile diff for transitive changes. Never hand-edit the lockfile.

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 imperfect, and treat nits as optional.