code-review-and-quality

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

2|Updated Jul 1, 2026
One-click install
npx skills add https://github.com/Lazare-Panam/mars-api --skill code-review-and-quality-lazare-panam
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review-and-quality
Source: https://github.com/Lazare-Panam/mars-api/tree/main/Mars.API/.claude/skills/code-review-and-quality
Command: npx skills add https://github.com/Lazare-Panam/mars-api --skill code-review-and-quality-lazare-panam

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 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 across correctness, readability, architecture, security, and performance with concrete checklists for each dimension. - 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: Provides thresholds for reviewable change sizes and strategies (stacking, horizontal, vertical) for splitting oversized changes. - Use Case: Before merging a pull request that adds a new API endpoint, run this review 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 the current uncommitted changes across all five quality axes 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?

Review a pull request by first understanding its intent, then checking tests, then walking the implementation across five axes: correctness, readability, architecture, security, and performance. Label every finding with a severity prefix so the author knows what is required versus optional.

What should a code review checklist include?

A code review checklist should cover correctness against the spec, edge case and error path handling, test adequacy, naming and readability, architectural fit, input validation and secret handling, and performance issues like N+1 queries. It ends with a verdict: approve or request changes.

How large should a pull request be for effective review?

A pull request should be around 100 changed lines for easy review, up to 300 for a single logical change. Changes near 1000 lines 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 dependency per change, verifying with a green test suite before and after, and reviewing the lockfile diff for 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 required fixes the author must address. Approve when the change improves overall code health even if imperfect, since the standard is continuous improvement rather than perfection.