code-review-and-quality

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

Updated Aug 15, 2026
One-click install
npx skills add https://github.com/jacksonlee-tw/mystock-vue --skill code-review-and-quality-jacksonlee-tw
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review-and-quality
Source: https://github.com/jacksonlee-tw/mystock-vue/tree/main/mystock-vue/.agents/skills/code-review-and-quality
Command: npx skills add https://github.com/jacksonlee-tw/mystock-vue --skill code-review-and-quality-jacksonlee-tw

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code merged without structured review accumulates correctness bugs, security vulnerabilities, architectural drift, and unreadable logic. This Skill enforces a consistent multi-axis review gate so every change is evaluated against the same quality standard 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 blocks merge. - Change Sizing and Splitting: Provides thresholds (~100/~300/~1000 lines) and splitting strategies (stack, by file group, horizontal, vertical) for oversized changes. - Dependency Discipline: Covers changelog review, one-package-per-change upgrades, lockfile diff review, and audit triage for dependency updates. - Use Case: Before merging a pull request, run the review checklist to verify tests, flag an N+1 query as Required, propose a structural remedy for a misplaced conditional, and approve only when the change improves overall code health. ## 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 each changed file across five axes: correctness, readability, architecture, security, and performance. Label every finding by severity and approve only when the change improves overall code health.

What should a code review checklist include?▼

A code review checklist should cover correctness (edge cases, error paths, test coverage), readability (naming, simplicity), architecture (patterns, coupling), security (input validation, secrets, injection), and performance (N+1 queries, pagination), plus verification that tests and builds pass.

How large should a pull request be for review?▼

A pull request should be around 100 changed lines for easy review, up to 300 for a single logical change. Around 1000 lines is too large and should be split using stacking, file-group, horizontal, or vertical splitting strategies.

How do I review dependency upgrades safely?▼

Review dependency upgrades by reading the changelog rather than trusting semver, upgrading one package per change, verifying a green test suite before and after, and reviewing the lockfile diff for unexpected transitive changes. 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, and treat nits and optional suggestions as non-blocking.