# Code Reviewer

Multi-perspective code review: correctness, security (OWASP), performance, and maintainability. Outputs severity-ranked findings with fix suggestions.

## Quick Reference

# Code Reviewer

> **Purpose:** Perform a multi-perspective code review on staged git changes or a specific file, identifying bugs, security issues, performance problems, and style violations.

---

## Invocation

```
/review [file_or_path]
```

If no path is given, review all staged changes (`git diff --cached`).

---

## Review Perspectives

### 1. Correctness
- Off-by-one errors, null/undefined access, race conditions
- Missing error handling on async operations
- Incorrect boolean logic or edge cases
- Type mismatches or unsafe casts

### 2. Security (OWASP Top 10)
- SQL injection via string concatenation
- XSS through unescaped user input in HTML
- Missing authentication/authorization checks
- Hardcoded secrets, API keys, or tokens
- Insecure deserialization or eval usage
- Path traversal in file operations

### 3. Performance
- N+1 query patterns in loops
- Missing database indexes for frequent queries
- Unbounded data fetches (no LIMIT/pagination)
- Synchronous blocking in async contexts
- Memory leaks (event listeners, timers, subscriptions not cleaned up)

### 4. Maintainability
- Functions longer than 50 lines
- Deeply nested conditionals (> 3 levels)
- Magic numbers without named constants
- Dead code or unreachable branches
- Missing or misleading variable names

---

## Output Format

For each finding, report:

```
[SEVERITY] Category — file:line
Description of the issue.
Suggested fix: ...
```

Severity levels:
- **CRITICAL** — Security vulnerability or data loss risk. Must fix before merge.
- **HIGH** — Bug that will cause incorrect behavior. Should fix before merge.
- **MEDIUM** — Performance or maintainability concern. Fix soon.
- **LOW** — Style or minor improvement. Optional.

---

## Summary

End with a summary table:

| Severity | Count |
|----------|-------|
| Critical | 0     |
| High     | 2     |
| Medium   | 3     |
| Low      | 1     |

**Verdict:** APPROVE / REQUEST CHANGES / BLOCK

---

## Rules
- Never approve code with CRITICAL findings
- Flag any TODO/FIXME added without a linked issue
- Verify test coverage exists for new public functions
- Check that error messages don't leak internal details