code-review

[CATEGORY] **Title** (SEVERITY)
📍 Location: `file:line`
🔍 Confidence: HIGH/MEDIUM/LOW
❌ Issue: [What's wrong]
✅ Fix: [How to fix it]

```diff (if applicable)
- [Old code]
+ [New code]

undefined

[🔐 Security] **SQL Injection Vulnerability** (CRITICAL)
📍 Location: `src/api/users.ts:45`
🔍 Confidence: HIGH
❌ Issue: User input directly interpolated into SQL query
✅ Fix: Use parameterized queries

```diff
- const result = db.query(`SELECT * FROM users WHERE id = ${req.params.id}`)
+ const result = db.query('SELECT * FROM users WHERE id = $1', [req.params.id])

**High Performance Finding:**

- const orders = await Order.findAll()
- for (const order of orders) {
-   order.items = await OrderItem.findByOrderId(order.id)
- }
+ const orders = await Order.findAll({ include: [OrderItem] })

**Medium Quality Finding:**

**Low Suggestion:**

it('should handle invalid date input', () => {
  expect(formatDate(null)).toBe('')
  expect(formatDate('invalid')).toBe('')
})

---

[🔐+⚡ Security/Performance] **Unvalidated User Input** (CRITICAL)
📍 Location: `src/api/search.ts:34`
🔍 Flagged by: Security Reviewer, Performance Reviewer
❌ Issue:
  - Security: Potential injection vulnerability
  - Performance: Unvalidated input could cause DoS
✅ Fix: Add input validation and length limits

| Category      | Critical | High | Medium | Low | Total |
|---------------|----------|------|--------|-----|-------|
| 🔐 Security   | [N]      | [N]  | [N]    | [N] | [N]   |
| ⚡ Performance | [N]      | [N]  | [N]    | [N] | [N]   |
| 📝 Quality    | [N]      | [N]  | [N]    | [N] | [N]   |
| 🧪 Testing    | [N]      | [N]  | [N]    | [N] | [N]   |
| **Total**     | [N]      | [N]  | [N]    | [N] | [N]   |

Overall Assessment: [EMOJI] [DECISION]
Reasoning: [Why this decision was made]

Blocking Issues: [N] (must fix before merge)
Non-blocking Issues: [N] (should consider)
Suggestions: [N] (nice to have)

✅ Positive Observations

- Well-structured error handling in `src/services/auth.ts`
- Comprehensive test coverage for edge cases
- Good use of TypeScript types for API responses
- Efficient caching strategy for frequent queries

FOCUS: Security review of the provided code changes
    - Identify authentication/authorization issues
    - Check for injection vulnerabilities (SQL, XSS, command, LDAP)
    - Look for hardcoded secrets or credentials
    - Verify input validation and sanitization
    - Check for insecure data handling (encryption, PII)
    - Review session management
    - Check for CSRF vulnerabilities in forms

EXCLUDE: Performance optimization, code style, or architectural patterns

CONTEXT: [Include the diff and full file context]

OUTPUT: Security findings in this format:
    [🔐 Security] **[Title]** (SEVERITY)
    📍 Location: `file:line`
    🔍 Confidence: HIGH/MEDIUM/LOW
    ❌ Issue: [Description]
    ✅ Fix: [Recommendation with code example if applicable]

SUCCESS: All security concerns identified with remediation steps
TERMINATION: Analysis complete OR code context insufficient

FOCUS: Performance review of the provided code changes
    - Identify N+1 query patterns
    - Check for unnecessary re-renders or recomputations
    - Look for blocking operations in async code
    - Identify memory leaks or resource cleanup issues
    - Check algorithm complexity (avoid O(n²) when O(n) possible)
    - Review caching opportunities
    - Check for proper pagination

EXCLUDE: Security vulnerabilities, code style, or naming conventions

CONTEXT: [Include the diff and full file context]

OUTPUT: Performance findings in this format:
    [⚡ Performance] **[Title]** (SEVERITY)
    📍 Location: `file:line`
    🔍 Confidence: HIGH/MEDIUM/LOW
    ❌ Issue: [Description]
    ✅ Fix: [Optimization strategy with code example if applicable]

SUCCESS: All performance concerns identified with optimization strategies
TERMINATION: Analysis complete OR code context insufficient

FOCUS: Code quality review of the provided code changes
    - Check adherence to project coding standards
    - Identify code smells (long methods, duplication, complexity)
    - Verify proper error handling
    - Check naming conventions and code clarity
    - Identify missing or inadequate documentation
    - Verify consistent patterns with existing codebase
    - Check for proper abstractions

EXCLUDE: Security vulnerabilities or performance optimization

CONTEXT: [Include the diff and full file context]
    [Include CLAUDE.md or .editorconfig if available]

OUTPUT: Quality findings in this format:
    [📝 Quality] **[Title]** (SEVERITY)
    📍 Location: `file:line`
    🔍 Confidence: HIGH/MEDIUM/LOW
    ❌ Issue: [Description]
    ✅ Fix: [Improvement suggestion with code example if applicable]

SUCCESS: All quality concerns identified with clear improvements
TERMINATION: Analysis complete OR code context insufficient

FOCUS: Test coverage review of the provided code changes
    - Identify new code paths that need tests
    - Check if existing tests cover the changes
    - Look for test quality issues (flaky, incomplete assertions)
    - Verify edge cases are covered
    - Check for proper mocking at boundaries
    - Identify integration test needs
    - Verify test naming and organization

EXCLUDE: Implementation details not related to testing

CONTEXT: [Include the diff and full file context]
    [Include related test files if they exist]

OUTPUT: Test coverage findings in this format:
    [🧪 Testing] **[Title]** (SEVERITY)
    📍 Location: `file:line`
    🔍 Confidence: HIGH/MEDIUM/LOW
    ❌ Issue: [Description]
    ✅ Fix: [Suggested test case with code example]

SUCCESS: All testing gaps identified with specific test recommendations
TERMINATION: Analysis complete OR code context insufficient

🔍 Code Review Synthesis Complete

Review Target: [What was reviewed]
Reviewers: 4 (Security, Performance, Quality, Testing)

Findings Summary:
- Critical: [N] 🔴
- High: [N] 🟠
- Medium: [N] 🟡
- Low: [N] ⚪

Duplicates Merged: [N]
Positive Observations: [N]

Decision: [APPROVE / APPROVE WITH COMMENTS / REQUEST CHANGES]
Reasoning: [Brief explanation]

Ready for final report generation.