Provides comprehensive code review guidance for React 19, Vue 3, Rust, TypeScript, Java, Python, and C/C++.
Helps catch bugs, improve code quality, and give constructive feedback.
Use when: reviewing pull requests, conducting PR reviews, code review, reviewing code changes,
establishing review standards, mentoring developers, architecture reviews, security audits,
checking code quality, finding bugs, giving feedback on code.
Code Review Excellence
Transform code reviews from gatekeeping to knowledge sharing through constructive feedback, systematic analysis, and collaborative improvement.
When to Use This Skill
Reviewing pull requests and code changes
Establishing code review standards for teams
Mentoring junior developers through reviews
Conducting architecture reviews
Creating review checklists and guidelines
Improving team collaboration
Reducing code review cycle time
Maintaining code quality standards
Core Principles
1. The Review Mindset
Goals of Code Review:
Catch bugs and edge cases
Ensure code maintainability
Share knowledge across team
Enforce coding standards
Improve design and architecture
Build team culture
Not the Goals:
Show off knowledge
Nitpick formatting (use linters)
Block progress unnecessarily
Rewrite to your preference
2. Effective Feedback
Good Feedback is:
Specific and actionable
Educational, not judgmental
Focused on the code, not the person
Balanced (praise good work too)
Prioritized (critical vs nice-to-have)
[BAD] "This is wrong."
[GOOD] "This could cause a race condition when multiple users
access simultaneously. Consider using a mutex here."
[BAD] "Why didn't you use X pattern?"
[GOOD] "Have you considered the Repository pattern? It would
make this easier to test. Here's an example: [link]"
[BAD] "Rename this variable."
[GOOD] "[nit] Consider `userCount` instead of `uc` for
clarity. Not blocking if you prefer to keep it."
3. Review Scope
What to Review:
Logic correctness and edge cases
Security vulnerabilities
Performance implications
Test coverage and quality
Error handling
Documentation and comments
API design and naming
Architectural fit
What Not to Review Manually:
Code formatting (use Prettier, Black, etc.)
Import organization
Linting violations
Simple typos
Review Process
Phase 1: Context Gathering (2-3 minutes)
Before diving into code, understand:
Read PR description and linked issue
Check PR size (>400 lines? Ask to split)
Review CI/CD status (tests passing?)
Understand the business requirement
Note any relevant architectural decisions
Phase 2: High-Level Review (5-10 minutes)
Architecture & Design - Does the solution fit the problem?
Maintainability - Clear names, single responsibility, comments
Phase 4: Summary & Decision (2-3 minutes)
Summarize key concerns
Highlight what you liked
Make clear decision:
[approve] Approve
[comment] Comment (minor suggestions)
[changes] Request Changes (must address)
Offer to pair if complex
Review Techniques
Technique 1: The Checklist Method
Use checklists for consistent reviews. See Security Review Guide for comprehensive security checklist.
Technique 2: The Question Approach
Instead of stating problems, ask questions:
[BAD] "This will fail if the list is empty."
[GOOD] "What happens if `items` is an empty array?"
[BAD] "You need error handling here."
[GOOD] "How should this behave if the API call fails?"
Technique 3: Suggest, Don't Command
Use collaborative language:
[BAD] "You must change this to use async/await"
[GOOD] "Suggestion: async/await might make this more readable. What do you think?"
[BAD] "Extract this into a function"
[GOOD] "This logic appears in 3 places. Would it make sense to extract it?"
Technique 4: Differentiate Severity
Use labels to indicate priority:
[blocking] - Must fix before merge
[important] - Should fix, discuss if disagree
[nit] - Nice to have, not blocking
[suggestion] - Alternative approach to consider
[learning] - Educational comment, no action needed
[praise] - Good work, keep it up!
Language-Specific Guides
Consult the corresponding detailed guide based on the language being reviewed:
