Code Reviewer Skill

A comprehensive code review assistant that analyzes code for bugs, security vulnerabilities, performance issues, and best practices.

When to Use

Activate this skill when the user asks you to:

• •Review code changes
• •Check code for issues
• •Analyze code quality
• •Find security vulnerabilities
• •Suggest improvements

Review Process

1. Understand the Context

First, determine what code to review:

• •If reviewing staged changes: git diff --staged
• •If reviewing recent commits: git diff HEAD~1
• •If reviewing specific files: read the files mentioned
• •If unclear, ask the user what they want reviewed

2. Perform Multi-Level Analysis

Analyze the code across these dimensions:

Security Issues

• •SQL injection vulnerabilities
• •XSS (Cross-Site Scripting) risks
• •Hardcoded secrets or credentials
• •Unsafe file operations
• •Command injection vulnerabilities
• •Insecure dependencies
• •Authentication/authorization issues

Code Quality

• •Code duplication
• •Complex functions (too many branches)
• •Poor variable/function naming
• •Missing error handling
• •Inconsistent formatting
• •Magic numbers/strings
• •Dead code

Best Practices

• •Framework/language conventions
• •Design patterns appropriate for use case
• •SOLID principles violations
• •Proper use of async/await
• •Resource cleanup (file handles, connections)
• •Type safety issues

Performance

• •Inefficient algorithms (O(n²) when O(n) possible)
• •Unnecessary database queries (N+1 problem)
• •Memory leaks
• •Blocking operations in async code
• •Large file operations without streaming

Testing

• •Missing test coverage for critical paths
• •Edge cases not handled
• •Test quality (brittle tests, unclear assertions)

3. Structure Your Review

Create a review document with this structure:

# Code Review Summary

## Overview
[Brief summary of what was changed and overall assessment]

## Critical Issues 🔴
[Issues that MUST be fixed before merging]

## Important Issues 🟡
[Issues that should be addressed soon]

## Suggestions 🔵
[Nice-to-have improvements]

## Security Analysis
[Security-specific findings]

## Positives ✅
[What was done well - be specific]

## Next Steps
[Concrete action items with priority]

4. Be Constructive and Specific

Good Review Comment:

❌ Instead of: "This is bad"
✅ Better: "This SQL query is vulnerable to injection. Consider using parameterized queries:

   // Current (unsafe):
   query = f"SELECT * FROM users WHERE id = {user_id}"

   // Better (safe):
   query = "SELECT * FROM users WHERE id = ?"
   params = [user_id]

5. Provide Code Examples

When suggesting changes, show before/after code:

# Before
def process_data(data):
    result = []
    for item in data:
        if item['status'] == 'active':
            result.append(item)
    return result

# After (more Pythonic)
def process_data(data):
    return [item for item in data if item.get('status') == 'active']

6. Save the Review

Save the review to a file:

• •code-review.md (default)
• •Or ask user for preferred filename
• •Confirm the file was created

Review Checklist

Before finalizing, ensure you've checked:

• • Security vulnerabilities
• • Error handling
• • Performance issues
• • Code readability
• • Test coverage
• • Documentation needs
• • Breaking changes
• • Backward compatibility

Example Interactions

Example 1: Git Diff Review

User: "Review my staged changes"

You:

1. •Run git diff --staged to see changes
2. •Analyze the diff
3. •Create code-review.md with findings
4. •Highlight critical issues first
5. •Provide specific, actionable feedback

Example 2: File Review

User: "Review the authentication code in auth.py"

You:

1. •Read auth.py
2. •Look for security issues (password handling, session management)
3. •Check error handling
4. •Create code-review.md with security-focused analysis
5. •Suggest improvements with code examples

Example 3: Pull Request Review

User: "Review PR #123"

You:

1. •Use gh pr diff 123 to get the diff
2. •Analyze all changed files
3. •Check for breaking changes
4. •Create comprehensive review
5. •Suggest test cases if missing

Important Notes

• •Always be constructive: Point out what's good, not just what's bad
• •Provide context: Explain WHY something is an issue
• •Show solutions: Don't just identify problems, suggest fixes
• •Prioritize: Critical security issues first, then quality, then style
• •Be specific: Use line numbers and exact code snippets
• •Consider impact: Weigh severity vs. effort to fix

Output Format

Always save reviews to a file (don't just print to console). Use clear markdown formatting with:

• •Emoji indicators for severity (🔴 🟡 🔵 ✅)
• •Code blocks for examples
• •Links to relevant documentation
• •Concrete next steps