Code Reviewer Skill

Description: Review completed code against plans, standards, and best practices. Identify issues, validate implementation, provide actionable feedback. Usage: /code-reviewer [files or feature to review]

Trigger this skill when:

• •A major implementation step has been completed
• •User says "review this code", "check my implementation"
• •After code-architect or code-implementation skill completes
• •Before merging or deploying significant changes
• •User wants validation against a plan or spec

Skip for: Explaining code (use tutor), bug fixing (use bug-fix), writing new code (use code-architect)

Phase 1: Context Gathering

Step 1.1: Identify Review Scope

Step 1.2: Understand Intent

• •What was this code supposed to accomplish?
• •What plan or spec was it based on?
• •What are the acceptance criteria?

Phase 2: Review Analysis

2.1: Plan Alignment Check

2.2: Code Quality Assessment

Structure & Organization:

• • Follows project file/folder conventions
• • Appropriate separation of concerns
• • Logical code organization

Naming & Readability:

• • Clear, descriptive names
• • Consistent naming conventions
• • Self-documenting code

Error Handling:

• • Appropriate error handling
• • No silent failures
• • Meaningful error messages

Type Safety:

• • Proper type annotations
• • No any types or suppressions
• • Type guards where needed

Performance:

• • No obvious inefficiencies
• • Appropriate data structures
• • No unnecessary operations

2.3: Architecture & Design

• • Follows SOLID principles
• • Proper abstraction levels
• • Loose coupling between components
• • Integrates well with existing code

2.4: Security Check

• • Input validation present
• • No hardcoded secrets
• • Proper authentication/authorization
• • Safe data handling

2.5: Testing Assessment

• • Tests exist for new code
• • Tests cover happy path
• • Tests cover edge cases
• • Tests are maintainable

Phase 3: Issue Classification

Severity Levels

Issue Template

### [SEVERITY] Issue Title

**Location:** `file:line`

**Problem:** 
[Clear description of what's wrong]

**Impact:**
[Why this matters]

**Recommendation:**
[Specific fix with code example if helpful]

Phase 4: Review Output

Review Report Structure

## Code Review Summary

### Overview
- **Files Reviewed:** [count]
- **Plan Alignment:** [ALIGNED / DEVIATIONS FOUND]
- **Overall Quality:** [GOOD / NEEDS WORK / CRITICAL ISSUES]

### What Was Done Well
- [Positive point 1]
- [Positive point 2]

### Plan Alignment
| Planned | Implemented | Status |
|---------|-------------|--------|
| [Feature 1] | [Description] | [checkmark] / [x] |

### Issues Found

#### Critical (Must Fix)
[List critical issues]

#### High (Should Fix)
[List high issues]

#### Medium (Recommended)
[List medium issues]

#### Low (Suggestions)
[List low issues]

### Recommendations
1. [Actionable recommendation 1]
2. [Actionable recommendation 2]

### Verdict
[ ] APPROVED - Ready to merge
[ ] APPROVED WITH COMMENTS - Minor fixes needed
[ ] CHANGES REQUESTED - Must address issues before merge
[ ] REJECTED - Significant rework needed

Phase 5: Follow-up

If Issues Found:

1. •Communicate findings clearly
2. •Be specific about what needs to change
3. •Provide code examples for fixes when helpful
4. •Offer to re-review after fixes

If Approved:

1. •Confirm code is ready
2. •Note any follow-up tasks for later
3. •Acknowledge good work

Quality Guidelines

ALWAYS:

• •Start with positives before issues
• •Be specific and actionable
• •Provide examples for complex fixes
• •Classify issues by severity
• •Check against the original plan
• •Run lsp_diagnostics on reviewed files

NEVER:

• •Be vague ("this looks wrong")
• •Nitpick style when logic issues exist
• •Approve code with critical issues
• •Skip security considerations
• •Ignore the original plan/spec

Communication Style

• •Constructive: Focus on improvement, not criticism
• •Specific: "Line 42 has X issue" not "there are issues"
• •Actionable: Every issue has a clear fix path
• •Balanced: Acknowledge what's good, not just problems