code-review-excellence

Guides structured pull request reviews with severity-labeled feedback and multi-pass inspection.

Updated May 22, 2026
One-click install
npx skills add https://github.com/viniciuscs84/sdd-toolkit --skill code-review-excellence-viniciuscs84
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review-excellence
Source: https://github.com/viniciuscs84/sdd-toolkit/tree/main/skills/code-review-excellence
Command: npx skills add https://github.com/viniciuscs84/sdd-toolkit --skill code-review-excellence-viniciuscs84

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often suffer from vague feedback, inconsistent standards, rubber-stamping, and delayed turnaround. This Skill provides a disciplined review workflow so reviewers deliver actionable, severity-labeled feedback on pull requests without missing critical issues. ## Core Features & Use Cases - Four-Pass Review Workflow: Systematically inspect architecture, tests, logic/correctness, and reach a clear approve/comment/request-changes decision. - Severity-Labeled Feedback: Tag every comment as [blocking], [important], [nit], [question], or [praise] so authors can triage effectively. - Pre-Review Gatekeeping: Check PR size, CI status, and scope before investing review time. - Use Case: A senior engineer reviewing a 300-line PR touching the auth layer uses the checklist to catch an unparameterized SQL query, labels it [blocking] with a concrete fix, and posts a summary of required changes. ## Quick Start Review the current pull request using the code review excellence workflow and provide severity-labeled feedback.

Frequently Asked Questions about code-review-excellence

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

FAQPage Schema
How do I conduct an effective code review on a pull request?

Follow a four-pass workflow: check architecture fit, verify test coverage of behavior and edge cases, inspect logic line-by-line for correctness and security issues, then state a clear approve, comment, or request-changes decision.

How should I label code review comments by severity?

Use five labels: [blocking] for must-fix issues, [important] for strong recommendations, [nit] for style notes, [question] for clarification, and [praise] for good work. This lets authors triage feedback quickly.

When should I request changes instead of approving a PR?

Request changes only for actual blockers such as security vulnerabilities, correctness bugs, or missing error handling. Do not block on [nit]-level style issues; those should be automated with linters or left as non-blocking comments.

What should I check before starting a code review?

Read the PR description and linked issue, verify the PR is under 400 lines of non-generated code, confirm CI is green, and identify affected subsystems. Pull the branch locally for changes touching security, concurrency, or migrations.

What are common code review mistakes to avoid?

Avoid rubber-stamping without reading, bike-shedding on naming, scope creep requests, delayed reviews beyond one business day, ghosting after requesting changes, and applying inconsistent standards across seniority levels.