Code Review Engine

Code Review Engine

Enterprise-grade automated code review. Works on GitHub PRs, local diffs, pasted code, or entire files. No dependencies — pure agent intelligence.

Quick Start

Review a GitHub PR

Review PR #42 in owner/​repo

Review a local diff

Review the staged changes in this repo

Review a file

Review src/​auth/​login.ts for security issues

Review pasted code

Just paste code and say "review this"

---

Review Framework: SPEAR

Every review follows the SPEAR framework — 5 dimensions, each scored 1-10:

🔴 S — Security (Weight: 3x)

🟡 P — Performance (Weight: 2x)

🟠 E — Error Handling (Weight: 2x)

🔵 A — Architecture (Weight: 1.5x)

📊 R — Reliability (Weight: 1.5x)

---

Scoring System

Per-Finding Severity

CRITICAL  → -3 points from dimension score
HIGH      → -2 points
MEDIUM    → -1 point
LOW       → -0.5 points
INFO      → 0 (suggestion only)

Overall SPEAR Score Calculation

Raw Score = (S×3 + P×2 + E×2 + A×1.5 + R×1.5) / 10
Final Score = Raw Score × 10  (scale 0-100)

Verdict Thresholds

---

Review Output Template

Use this structure for every review:

# Code Review: [PR title or file name]

## Summary
[1-2 sentence overview of what this code does and overall quality]

## SPEAR Score: [X]/​100 — [VERDICT]

| Dimension | Score | Key Finding |
|-----------|-------|-------------|
| 🔴 Security | X/​10 | [worst finding or "Clean"] |
| 🟡 Performance | X/​10 | [worst finding or "Clean"] |
| 🟠 Error Handling | X/​10 | [worst finding or "Clean"] |
| 🔵 Architecture | X/​10 | [worst finding or "Clean"] |
| 📊 Reliability | X/​10 | [worst finding or "Clean"] |

## Findings

### [CRITICAL/​HIGH] 🔴 [Title]
**File:** `path/​to/​file.ts:42`
**Category:** Security
**Issue:** [What's wrong]
**Impact:** [What could happen]
**Fix:**
```[lang]
// suggested fix

[MEDIUM] 🟡 [Title]

...

What's Done Well

• [Genuinely good patterns worth calling out]

Recommendations

1. [Prioritized action items]

---

## Language-Specific Patterns

### TypeScript / JavaScript
- `any` type usage → Architecture finding
- `as` type assertions → potential runtime error
- `console.log` in production code → Style
- `==` instead of `===` → Reliability
- Missing `async/​await` error handling
- `useEffect` missing cleanup return
- Index signatures without validation

### Python
- Bare `except:` or `except Exception:` → Error Handling
- `eval()` / `exec()` → Security CRITICAL
- Mutable default arguments → Reliability
- `import *` → Architecture
- Missing `__init__.py` type hints
- f-strings with user input → potential injection

### Go
- `_ :=` discarding errors → Error Handling HIGH
- `panic()` in library code → Reliability HIGH
- Missing `defer` for resource cleanup
- Exported functions without doc comments
- `interface{}` / `any` overuse

### Java
- Catching `Exception` or `Throwable` → Error Handling
- Missing `@Override` annotations
- Mutable static fields → thread safety
- `System.out.println` in production
- Missing null checks (pre-Optional code)

### SQL
- String concatenation in queries → Security CRITICAL
- `SELECT *` → Performance
- Missing WHERE on UPDATE/​DELETE → Security CRITICAL
- No LIMIT on user-facing queries → Performance
- Missing indexes for JOIN columns

---

## Advanced Techniques

### Reviewing for Business Logic
Beyond code quality, check:
- Does the code match the PR description / ticket requirements?
- Are there edge cases the spec didn't mention?
- Could this break existing functionality?
- Is there a simpler way to achieve the same result?

### Reviewing for Operability
- Can this be debugged in production? (logging, error messages)
- Can this be rolled back safely?
- Are feature flags needed?
- What monitoring should accompany this change?

### Reviewing Database Changes
- Is the migration reversible?
- Will it lock tables during migration?
- Are there indexes for new query patterns?
- Is there a data backfill needed?

### Security Review Depth Levels
| Level | When | What |
|-------|------|------|
| Quick | Internal tool, trusted input | OWASP Top 10 patterns only |
| Standard | User-facing feature | + auth, input validation, output encoding |
| Deep | Payment, auth, PII handling | + crypto review, session management, audit logging |
| Threat Model | New service/​API surface | + attack surface mapping, trust boundaries |

---

## Integration Patterns

### GitHub PR Review
```bash
# Get PR diff
gh pr diff 42 --repo owner/​repo

# Get PR details
gh pr view 42 --repo owner/​repo --json title,body,files,commits

# Post review comment
gh pr review 42 --repo owner/​repo --comment --body "review content"

Local Git Review

# Review staged changes
git diff --cached

# Review branch vs main
git diff main..HEAD

# Review last N commits
git log -5 --oneline && git diff HEAD~5..HEAD

Heartbeat / Cron Integration

Check for open PRs in [repo] that I haven't reviewed yet.
For each, run a SPEAR review and post the results as a PR comment.

---

Edge Cases & Gotchas

• Large PRs (>500 lines): Break into logical chunks. Review file-by-file. Flag the PR size itself as a finding (Architecture: "PR too large — consider splitting").
• Generated code: Skip generated files (proto, swagger, migrations from ORMs). Note that you skipped them.
• Dependency updates: Focus on breaking changes in changelogs, not the lockfile diff.
• Merge conflicts markers: Flag immediately as CRITICAL — <<<<<<< in code means broken merge.
• Binary files: Note presence, can't review content.
• Config changes: Extra scrutiny — wrong env var = production outage.
• Refactors: Verify behavior preservation. Check if tests still pass conceptually.

---

Review Checklist (Quick Mode)

For fast reviews when full SPEAR isn't needed:

• No hardcoded secrets or credentials
• No SQL injection / XSS / path traversal
• All errors handled (no empty catch, no discarded errors)
• No N+1 queries or unbounded operations
• Tests exist for new/​changed logic
• No console.log / print / fmt.Print left in
• Functions under 50 lines, files under 300 lines
• Types are specific (no any / interface{})
• PR description matches the actual changes
• No TODOs without linked issues