| name | code-reviewer |
| description | Perform systematic code reviews following best practices and team standards |
| version | 1.0.0 |
| author | AgentSkills.NET Examples |
| tags | ["code-review","quality","workflow"] |
| allowed-tools | ["filesystem","git"] |
Code Reviewer
Conduct thorough, systematic code reviews following industry best practices.
Purpose
This skill guides you through performing comprehensive code reviews that improve code quality, catch bugs, maintain standards, and facilitate knowledge sharing.
Instructions
Phase 1: Initial Assessment (2-3 minutes)
Before diving into code:
-
Read the PR/MR description
- Understand the goal and context
- Note any special considerations
- Check linked issues or tickets
-
Review the change overview
- Check files changed count (>20 files may need splitting)
- Look at additions/deletions ratio
- Identify areas of concern
-
Verify CI/Build Status
- Ensure all tests pass
- Check build succeeds
- Review any warnings
- Note failing checks to address
Phase 2: Code Quality Review (10-15 minutes)
Examine code for quality issues:
-
Readability
- Clear variable and function names
- Appropriate comments for complex logic
- Consistent formatting
- Reasonable function/method length
-
Code Structure
- Single Responsibility Principle
- DRY (Don't Repeat Yourself)
- Appropriate abstraction levels
- Logical organization
-
Naming Conventions
- Follows project standards
- Descriptive and meaningful
- Consistent across codebase
- No abbreviations unless standard
-
Code Smells
- Magic numbers or strings
- Excessive complexity
- Large classes or methods
- Tight coupling
Phase 3: Logic and Correctness (10-15 minutes)
Verify the implementation:
-
Logic Review
- Implementation matches requirements
- Edge cases handled
- Error conditions addressed
- Boundary conditions checked
-
Potential Bugs
- Off-by-one errors
- Null/undefined handling
- Resource leaks
- Race conditions
- Integer overflow
-
Algorithm Efficiency
- Reasonable time complexity
- Appropriate data structures
- No unnecessary iterations
- Optimizable sections noted
Phase 4: Testing (5-10 minutes)
Evaluate test coverage:
-
Test Presence
- New code has tests
- Modified code has updated tests
- Tests are meaningful
-
Test Quality
- Tests actually verify behavior
- Edge cases covered
- Error cases tested
- Tests are maintainable
-
Test Organization
- Clear test names
- Arrange-Act-Assert structure
- No test interdependencies
Phase 5: Security Review (5-10 minutes)
Check for security issues:
-
Input Validation
- All user input validated
- Sanitization applied
- Type checking performed
-
Common Vulnerabilities
- SQL injection risks
- XSS vulnerabilities
- CSRF protection
- Path traversal issues
-
Authentication & Authorization
- Proper access controls
- Session management
- Secure credential handling
-
Data Protection
- Sensitive data encrypted
- No secrets in code
- PII handled properly
Phase 6: Documentation (3-5 minutes)
Verify documentation:
-
Code Documentation
- Public APIs documented
- Complex logic explained
- Non-obvious decisions noted
-
README Updates
- New features documented
- Breaking changes noted
- Examples provided
-
API Documentation
- Parameters documented
- Return values described
- Error cases listed
Providing Feedback
Structure your review comments effectively:
Severity Levels
Use these severity indicators:
- ๐ด CRITICAL: Must fix before merge (blocks merge)
- ๐ MAJOR: Should fix before merge (strong suggestion)
- ๐ก MINOR: Could improve (optional)
- ๐ก SUGGESTION: Alternative approach (consider)
- โ QUESTION: Need clarification
- โ
PRAISE: Good work (acknowledge)
Comment Template
[SEVERITY] [Category]: Brief title
Line XX: Specific issue
Reason: Why this matters
Suggestion: How to fix
Example:
[code example if helpful]
Examples
Example 1: Security Issue
๐ด CRITICAL: SQL Injection Risk
Line 45: `query = "SELECT * FROM users WHERE id = " + userId`
Reason: Direct string concatenation allows SQL injection attacks
Suggestion: Use parameterized queries
Example:
query = "SELECT * FROM users WHERE id = @userId"
command.Parameters.AddWithValue("@userId", userId)
Example 2: Logic Bug
๐ MAJOR: Off-by-One Error
Line 67: `for (int i = 0; i <= array.Length; i++)`
Reason: Loop will throw IndexOutOfRangeException on last iteration
Suggestion: Change to `i < array.Length`
Example 3: Code Quality
๐ก MINOR: Magic Number
Line 89: `if (count > 100) { ... }`
Reason: Unclear what 100 represents
Suggestion: Extract to named constant
Example:
private const int MaxItemsPerPage = 100;
if (count > MaxItemsPerPage) { ... }
Example 4: Positive Feedback
โ
PRAISE: Error Handling
Lines 120-135: Excellent error handling with specific messages
This makes debugging much easier. Great work!
Best Practices
- Be constructive - Focus on the code, not the person
- Explain reasoning - Help others learn
- Suggest solutions - Don't just point out problems
- Acknowledge good work - Positive feedback matters
- Ask questions - Understand intent before criticizing
- Be timely - Review promptly to unblock others
- Be thorough - But know when to stop
- Focus on important issues - Don't nitpick style if tests fail
Common Issues Checklist
When to Request Changes
Request changes when:
- Critical security vulnerabilities exist
- Tests fail or are missing for new features
- Code violates established team standards
- Logic bugs will cause incorrect behavior
- Performance issues will impact users
When to Approve
Approve when:
- All critical issues resolved
- Tests pass and provide adequate coverage
- Code follows team standards
- Documentation is sufficient
- No security concerns remain
- Minor issues can be addressed in follow-up
Timeouts
If a review is taking too long:
- Large PRs: Request splitting into smaller chunks
- Complex logic: Schedule pairing session
- Many comments: Discuss in real-time (call/meeting)
- Disagreement: Escalate to team lead or architect
Notes
- Customize this workflow for your team's standards
- Focus on teaching, not gatekeeping
- Balance thoroughness with timely feedback
- Remember: code review is a conversation, not a judgment
