skills.rest
raishoemi
raishoemiCOMMUNITY
Explore all skills by this author →
GitHub

code-review-and-quality

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

Updated Jul 1, 2026
Search Tags:#code review#checklist#pull request#refactoring#merge#security review#quality gates
One-click install
npx skills add https://github.com/raishoemi/traffic-sim-v2 --skill code-review-and-quality-raishoemi
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review-and-quality
Source: https://github.com/raishoemi/traffic-sim-v2/tree/main/.github/skills/code-review-and-quality
Command: npx skills add https://github.com/raishoemi/traffic-sim-v2 --skill code-review-and-quality-raishoemi

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 exactly what must be addressed before merge. - Change Sizing and Splitting Guidance: Defines thresholds for reviewable change sizes and provides strategies (stacking, horizontal, vertical) for splitting 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 at boundaries, no N+1 queries exist, and the change description stands alone in version control history. ## Quick Start Review this pull request across correctness, readability, architecture, security, and performance, and label each finding with its 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. Approve only when the change improves overall code health.

What should a code review checklist include?▼

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

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; 1000 lines is too large and should be split. Splitting strategies include stacking dependent changes, splitting by file group, horizontal layer-first splits, or vertical full-stack slices.

How do I label code review comments by severity?▼

Use no prefix for required changes, 'Critical:' for merge blockers like security vulnerabilities, 'Nit:' for optional style points, 'Optional:' or 'Consider:' for suggestions, and 'FYI' for informational context. This prevents authors from treating all feedback as mandatory.

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

Request changes when there are unresolved Critical or Required findings: security vulnerabilities, broken functionality, missing regression tests for bug fixes, or structural regressions like complexity relocation. Approve when the change improves overall code health even if imperfect.

Should AI-generated code be reviewed differently?▼

AI-generated code needs more scrutiny, not less, because it is confident and plausible even when wrong. Apply the same five-axis review with extra attention to correctness and architecture, and consider a multi-model review pattern where a different model reviews than the one that wrote the code.

Related Skills

Explore More Software Engineering Skills→
crewrigcrewrig
20

developer

Make small code changes with verification and limited scope.

Official
Advanced
a2f0a2f0

preen-deferred-fixes

Implement deferred-fix issues from merged PR review threads with tests.

Community
Advanced
Devsoul2026Devsoul2026
150

requesting-code-review

Automate pre-commit verification with static analysis, tests, and lint checks.

Community
Advanced
monoesmonoes
15

pair-programming

Coordinate role-based pair programming sessions with continuous code review and testing.

Official
Advanced