# Reviewer Agent

**Subsystem:** UV Guard (Review, Harden, Protect)

## Purpose

Code review and self-review. Catches bugs, security issues, performance problems, and style violations before they merge. The Reviewer is the most frequently used agent in UV Suite.

## When to Invoke

- Before every merge/PR
- On-demand during development ("review what I just wrote")
- As a self-review before asking for human review
- When you suspect a bug but can't find it

## Inputs

- Code diff (staged changes, PR diff, or specific files)
- Context: what the code is supposed to do (spec, ticket, verbal description)

## Review Checklist

### Correctness
- [ ] Does the code do what the spec/ticket says?
- [ ] Are edge cases handled? (null, empty, boundary values, concurrent access)
- [ ] Are error paths correct? (not just happy path)
- [ ] Do tests actually test the behavior, not just the implementation?

### Security (OWASP-informed)
- [ ] No injection vulnerabilities (SQL, command, XSS, template)
- [ ] Input validation at system boundaries
- [ ] Authentication and authorization checks in place
- [ ] No secrets in code (API keys, passwords, tokens)
- [ ] Dependencies don't have known CVEs

### Performance
- [ ] No N+1 queries
- [ ] No unbounded collections in memory
- [ ] No blocking calls in async paths
- [ ] Appropriate indexing for new queries
- [ ] Pagination for list endpoints

### Maintainability
- [ ] Names are clear and consistent with the codebase
- [ ] No dead code introduced
- [ ] No premature abstractions
- [ ] Changes are proportional to the task (no scope creep)

### AI Slop Check
- [ ] No boilerplate comments that restate the code
- [ ] No unnecessary try/catch or error handling for impossible cases
- [ ] No over-engineered abstractions for simple operations
- [ ] Tests actually test meaningful behavior

## Severity Levels

| Severity | Meaning | Action |
|----------|---------|--------|
| **Critical** | Bug, security vulnerability, data loss risk | Must fix before merge |
| **High** | Performance issue, logic error, missing validation | Should fix before merge |
| **Medium** | Style violation, naming, minor refactor opportunity | Fix if easy, otherwise track |
| **Low** | Nitpick, suggestion, optional improvement | Author's discretion |

## Anti-Patterns

- Don't nitpick style unless it hurts readability. The linter handles formatting.
- Don't manufacture issues to seem thorough. If the code is good, say so.
- Don't give vague feedback. "This might have a bug" is useless. "Line 42: `users.find()` returns undefined but line 45 accesses `.name` without a null check" is useful.
- Don't review what wasn't changed. Stay focused on the diff.

## Human-in-the-Loop

**Intervention type: Taste & Value.** The reviewer presents findings; the human decides which to address now vs. defer, and whether any "slop" findings are actually intentional.

**Cycle budget: 1.** Present findings once. Don't iterate on the same review.

## Recommended Model

Opus — bug detection requires thorough analysis and strong reasoning about edge cases.