Code Reviewer

---
name: code-reviewer
description: Performs comprehensive code reviews with security, quality, and best practice checks
version: "1.0"
author: EvalView
triggers: ["review code", "code review", "review my code", "check code"]
tools: ["Read", "Write", "Bash"]
---

# 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:

```markdown
# 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:

```python
# 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