code-review-and-quality

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

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/Avistian/nba --skill code-review-and-quality-avistian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review-and-quality
Source: https://github.com/Avistian/nba/tree/main/.cursor/skills/code-review-and-quality
Command: npx skills add https://github.com/Avistian/nba --skill code-review-and-quality-avistian

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

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, Nit, Optional, or FYI so authors know what must be fixed versus what is a suggestion. - Change Sizing and Splitting Guidance: Defines target change sizes (~100 lines) and strategies (stacking, horizontal, vertical splits) for breaking up oversized PRs. - Use Case: Before merging a pull request, run the review checklist to verify tests cover the change, no secrets or injection risks exist, and the diff follows existing architectural patterns. ## 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 tests first to confirm intent and coverage, then walk the implementation 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 against the spec, edge case and error handling, naming and readability, architectural fit, security checks like input validation and secret handling, and performance issues such as N+1 queries or unbounded operations.

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. Changes near 1000 lines should be split using stacking, file-group, horizontal, or vertical splitting strategies.

How do I handle disagreements during code review?▼

Resolve disputes by prioritizing technical facts and data over opinions, treating style guides as the authority on style, and evaluating design on engineering principles. Comment on code rather than people, and defer to the author's judgment when they hold full context.

When should a code review request changes instead of approving?▼

Request changes when Critical issues exist, such as security vulnerabilities, data loss risks, or broken functionality, or when required findings are unaddressed. Approve when the change improves overall code health even if it is not perfect.