Code Review Assistant

AI-powered code review assistant that analyzes pull requests for bugs, security issues, performance problems, and style violations with actionable feedback.

Perform thorough AI-powered code reviews on pull requests or local changes. Analyzes diffs for bugs, security vulnerabilities, performance issues, maintainability concerns, and style violations. Provides actionable, specific feedback — not generic advice.

Usage

"Review the current PR"
"Review the changes on this branch vs main"
"Review these specific files for security issues"
"Do a deep review of the authentication changes"

How It Works

1. Gather Changes

Collect the diff and context:

# PR review
gh pr diff <number> --color=never

# Branch review
git diff main...HEAD

# Staged changes
git diff --cached

Also gather:

• File history (recently changed = higher risk)
• Test coverage for changed files
• Related open issues or previous reviews

2. Multi-Pass Analysis

Each pass focuses on a different concern:

Pass 1 — Correctness:

• Logic errors (off-by-one, null handling, race conditions)
• Edge cases not covered (empty input, boundary values, overflow)
• Error handling gaps (uncaught exceptions, missing error propagation)
• State management issues (stale closures, mutation of shared state)
• Concurrency bugs (deadlocks, data races, missing synchronization)

Pass 2 — Security:

• Injection vulnerabilities (SQL, command, XSS, template)
• Authentication/authorization gaps
• Sensitive data exposure (logs, errors, responses)
• Insecure cryptography or random number generation
• Missing input validation at trust boundaries
• Hardcoded secrets or credentials

Pass 3 — Performance:

• N+1 query patterns
• Missing or incorrect caching
• Unnecessary allocations in hot paths
• Blocking operations in async contexts
• Missing pagination or unbounded queries
• Inefficient algorithms (quadratic loops on large data)

Pass 4 — Maintainability:

• Complex functions that should be split (cyclomatic complexity >10)
• Missing or misleading names
• Dead code or unreachable branches
• Duplicated logic that should be extracted
• Missing types or overly broad types (any, Object)
• Tight coupling between modules

Pass 5 — Testing:

• Changed logic without corresponding test changes
• Test quality (testing implementation vs behavior)
• Missing edge case tests
• Flaky test patterns (timing, ordering, external deps)
• Adequate error path coverage

3. Severity Classification

Each finding gets a severity:

• 🔴 Must Fix: Bug, security issue, data loss risk, crash
• 🟡 Should Fix: Performance issue, maintainability concern, missing test
• 🟢 Consider: Style improvement, minor optimization, suggestion
• 💡 Nitpick: Optional improvement, personal preference

4. Actionable Feedback

Every comment includes:

• What: The specific issue found
• Where: Exact file and line number
• Why: Why this is a problem (not just "this is bad")
• How: Concrete fix suggestion with code

5. Summary

Overall assessment with:

• Risk level (safe to merge / needs changes / needs redesign)
• Top 3 most important findings
• Positive observations (good patterns, improvements)
• Suggested follow-up items (not blocking merge)

Output

## Code Review Summary

**Risk Level:** 🟡 Needs Changes (2 must-fix, 4 should-fix)
**Files Reviewed:** 12 files, +342/-89 lines

### 🔴 Must Fix

1. **SQL Injection in user search** — `src/api/users.ts:47`
   The search query interpolates user input directly:
   ```typescript
   // Current (vulnerable)
   db.query(`SELECT * FROM users WHERE name LIKE '%${query}%'`)
   // Fix: use parameterized query
   db.query('SELECT * FROM users WHERE name LIKE $1', [`%${query}%`])

2. Race condition in balance update — src/services/wallet.ts:112-118 Read-then-write without transaction. Two concurrent requests can both read the same balance and overwrite each other. Fix: wrap in a database transaction with SELECT FOR UPDATE.

🟡 Should Fix

3. N+1 query in order listing — src/api/orders.ts:23 Each order triggers a separate query for user details. Use a JOIN or batch load users by ID.

4. Missing error handling — src/services/payment.ts:67 API call result is not checked for errors before accessing .data.

[...]

👍 Good Stuff

• Clean separation of concerns in the new service layer
• Comprehensive input validation on the registration endpoint
• Good use of TypeScript discriminated unions for payment status

📋 Follow-up (non-blocking)

• Consider adding request rate limiting to the search endpoint
• The formatDate utility is duplicated in 3 files — extract to shared utils

## Configuration

The review depth adapts to PR size:
- **Small** (<100 lines): Full deep review, every line examined
- **Medium** (100-500 lines): Focused review on high-risk areas
- **Large** (500+ lines): Architectural review + spot-check critical paths, suggest splitting PR

## Integration

Works with:
- GitHub PRs (via `gh` CLI)
- GitLab MRs (via `glab` CLI)
- Local git branches (via `git diff`)
- Patch files (via `git apply --stat`)