code-review-excellence

Review pull requests with structured checklists, severity labels, and constructive feedback techniques.

1|Updated Mar 5, 2026

Search Tags:#code review #feedback #pull request #software quality #mentoring #security checklist

Ready to run

npx skills add https://github.com/Clay-HHK/claude-skills --skill code-review-excellence-clay-hhk

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: code-review-excellence
Source: https://github.com/Clay-HHK/claude-skills/tree/main/code-review-excellence
Command: npx skills add https://github.com/Clay-HHK/claude-skills --skill code-review-excellence-clay-hhk

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often become bottlenecks, sources of team friction, or rubber-stamp approvals that miss critical bugs. This Skill provides a systematic review process that catches real issues while keeping feedback constructive and reviews fast. ## Core Features & Use Cases - Four-Phase Review Process: Structured workflow from context gathering through high-level design review, line-by-line analysis, and final decision. - Severity-Labeled Feedback: Tag comments as blocking, important, nit, suggestion, or praise so authors know exactly what must change before merge. - Language-Specific Checklists: Catch common Python and TypeScript/JavaScript bugs like mutable default arguments, unhandled async errors, and prop mutation. - Use Case: When reviewing a teammate's 300-line pull request, follow the phased process to check security, performance, and test coverage, then deliver a summary with clear approve/request-changes verdict. ## Quick Start Review this pull request and provide structured feedback with severity labels and a clear approval decision.

Frequently Asked Questions about code-review-excellence

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How large should a pull request be for effective review?▼

Keep pull requests between 200 and 400 lines for effective review. Larger PRs should be split into stages, such as separate PRs for interfaces, implementation, and tests, so reviewers can give meaningful feedback.