code-review-and-quality

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

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

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 with severity-labeled feedback so every change is evaluated before it reaches 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: Provides thresholds (~100/~300/~1000 lines) and splitting strategies (stack, by file group, horizontal, vertical) for oversized changes. - Use Case: Before merging a pull request that adds a new API endpoint, run the review checklist to verify tests cover edge cases, inputs are validated, no N+1 queries exist, and the change description stands alone in version control history. ## Quick Start Review the current uncommitted changes 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?

Follow the five-step process: understand the change context, review the tests first, walk through the implementation across the five axes, categorize findings with severity labels, and verify the author's testing story. Approve only when the change improves overall code health.

What should a code review checklist include?

A thorough checklist covers correctness (edge cases, error paths, test coverage), readability (naming, simplicity), architecture (patterns, coupling), security (input validation, secrets, injection), and performance (N+1 queries, pagination, unbounded operations).

How large should a pull request be for effective review?

Around 100 lines changed is ideal and reviewable in one sitting. Up to 300 lines is acceptable 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 label code review comments by severity?

Use no prefix for required changes, Critical for merge-blocking issues like security vulnerabilities, Nit for minor optional style points, Optional or Consider for suggestions, and FYI for informational context requiring no action.

When should a code review request changes instead of approving?

Request changes when Critical or Important issues exist, such as security vulnerabilities, missing error handling, or broken functionality. Approve when the change improves overall code health even if imperfect, and never accept deferred cleanup promises.