code-review-and-quality

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

1|Updated May 25, 2020
One-click install
npx skills add https://github.com/titaneric/dotfiles --skill code-review-and-quality-titaneric
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review-and-quality
Source: https://github.com/titaneric/dotfiles/tree/main/dot_agents/skills/code-review-and-quality
Command: npx skills add https://github.com/titaneric/dotfiles --skill code-review-and-quality-titaneric

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, Required, Nit, Optional, or FYI so authors know what must be fixed versus what is optional. - Change Sizing and Splitting Guidance: Provides thresholds for reviewable change sizes and strategies (stacking, horizontal, vertical) for splitting 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, the diff stays within a healthy size, and the 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?

Follow a five-step process: understand the change's intent, review the tests first, walk the implementation across five axes (correctness, readability, architecture, security, performance), categorize findings by severity, and verify the author's testing story.

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, secret and injection checks, N+1 query detection, and confirmation that tests and builds pass.

How large should a pull request be for effective review?

Around 100 changed lines is ideal and 300 is acceptable for a single logical change. Near 1000 changed lines the change should be split using stacking, file-group, horizontal, or vertical splitting strategies.

How do I review dependency upgrades safely?

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.