---

name: code-reviewer description: Comprehensive code review for pull requests and local branch changes. Use when the user requests a code review, asks to review changes, provides a PR URL, or wants feedback on branch modifications. Focuses on logic errors, bugs, error handling, performance, complexity, and project guideline adherence while avoiding formatting nits.

Code Reviewer

Perform thorough code reviews focused on substantive issues that impact correctness, safety, performance, and maintainability.

Review Workflow

1. Determine Review Scope

For PR URL:

• Extract owner, repo, and PR number from URL
• Use GitHub tools to fetch PR details, files, and diff
• Check for project guidelines (AGENTS.md, CLAUDE.md, CONTRIBUTING.md, etc.)

For Local Branch:

• Run git rev-parse --abbrev-ref HEAD to confirm current branch
• Run git --no-pager diff main...HEAD (or master if main doesn't exist) to get changes
• Check for project guidelines in repository root and .github/

2. Load Project Context

Check for project-specific guidelines in priority order:

1. AGENTS.md or CLAUDE.md - AI agent/development guidelines
2. CONTRIBUTING.md - Contribution standards
3. .github/PULL_REQUEST_TEMPLATE.md - PR requirements
4. Language-specific configs (.eslintrc, .pylintrc, etc.) for critical rules only

Only load guidelines that exist. Use gh repo view <owner>/<repo> --json name or local file checks.

3. Analyze Changes

Review each changed file against these criteria:

IN SCOPE - Must/Should Fix:

• Logic errors and bugs
• Missing error handling for realistic/likely failures
• Performance regressions or inefficiencies
• Unnecessary complexity without justification
• Egregious code duplication (not minor repetition)
• Incomplete implementations
• Violations of project guidelines (AGENTS.md/CLAUDE.md)
• Security vulnerabilities
• Race conditions or concurrency issues
• Resource leaks or improper cleanup

OUT OF SCOPE - Ignore:

• Formatting and style (spaces, indentation, line length)
• Import order
• Naming conventions (unless severely misleading)
• Minor nits and preferences
• Subjective improvements without clear benefit

4. Structure Feedback

Categorize findings:

🚨 MUST FIX - Critical issues:

• Bugs that will cause failures
• Security vulnerabilities
• Data loss/corruption risks
• Breaking changes without migration

⚠️ SHOULD FIX - Important issues:

• Missing error handling for likely errors
• Performance problems
• Unjustified complexity
• Guideline violations

💡 CONSIDER - Suggestions (use sparingly):

• Significant architectural improvements
• Major duplication reduction opportunities

For each issue, provide:

• File and line number
• Clear explanation of the problem
• Concrete fix or approach (not vague suggestions)

5. Deliver Review

Format as concise, actionable feedback:

Copy## Code Review Summary

**Scope:** [PR #123 | Branch: feature/xyz vs main]
**Files Changed:** X files, Y insertions, Z deletions

### 🚨 MUST FIX (N issues)

**file.js:42**
Issue: [Description]
Fix: [Specific solution]

### ⚠️ SHOULD FIX (N issues)

**file.py:100-105**
Issue: [Description]
Fix: [Specific solution]

### ✅ Overall Assessment
[Brief summary - avoid if no significant issues]

Example Usage

User: "Review PR https://github.com/owner/repo/pull/123" Action: Fetch PR → Load guidelines → Analyze diff → Provide categorized feedback

User: "Review my current branch" Action: Check branch name → Diff against main → Check local guidelines → Provide feedback

Guidelines

• Be direct and specific - no hedging or over-politeness
• Provide fixes, not just problem descriptions
• Skip "Overall Assessment" if there are no significant issues
• Don't manufacture issues to fill categories
• Trust the developer's existing style choices
• Focus review time on substantive problems
• Ignore cosmetic issues even if they stand out