Code Review Assistant

Systematic approach to reviewing code changes for quality and correctness.

When to Use

• User asks for a code review or PR review
• Reviewing changes before merging
• User asks "is this code okay?" or "any issues with this?"
• Before deploying to production

Review Process

1. Understand Context

Before reviewing code:

• What is the purpose of this change?
• What problem does it solve?
• Are there related issues or documentation?

2. Review in Layers

Review code systematically in this order:

Layer 1: Correctness     - Does it work as intended?
Layer 2: Security        - Are there vulnerabilities?
Layer 3: Performance     - Are there bottlenecks?
Layer 4: Maintainability - Is it readable and extensible?
Layer 5: Style           - Does it follow conventions?

Review Checklist

Correctness

• Logic handles all expected cases
• Edge cases considered (empty, null, boundaries)
• Error handling is appropriate
• No obvious bugs or typos
• Tests cover the changes

Security

• No hardcoded secrets or credentials
• User input is validated and sanitized
• SQL queries use parameterized statements
• No XSS vulnerabilities (user data escaped)
• Authentication/authorization checked
• Sensitive data not logged

Performance

• No N+1 query problems
• Large datasets paginated
• Expensive operations cached if appropriate
• No unnecessary re-renders (React)
• Async operations where beneficial

Maintainability

• Code is readable without extensive comments
• Functions are focused and reasonably sized
• No code duplication (DRY)
• Clear naming for variables and functions
• Appropriate abstraction level

Style

• Follows project conventions
• Consistent formatting
• No commented-out code
• Imports organized

Feedback Format

Structure feedback as:

## Summary

Brief overview of the change and overall assessment.

## Must Fix (Blocking)

Issues that must be addressed before merge.

### Issue 1: [Title]
**Location**: `file.ts:42`
**Problem**: Description of the issue
**Suggestion**: How to fix it

## Should Fix (Non-blocking)

Improvements that should be made but don't block merge.

## Consider (Optional)

Suggestions for future improvement.

## Positive Feedback

What was done well.

Examples

Security Issue

### Issue: SQL Injection Vulnerability
**Location**: `users.ts:28`
**Problem**: User input directly concatenated into SQL query
**Suggestion**: Use parameterized query:
\`\`\`typescript
// Before
const query = `SELECT * FROM users WHERE id = ${userId}`;

// After
const query = 'SELECT * FROM users WHERE id = $1';
const result = await db.query(query, [userId]);
\`\`\`

Performance Issue

### Issue: N+1 Query in Loop
**Location**: `orders.ts:15-20`
**Problem**: Database query inside loop causes N+1 queries
**Suggestion**: Fetch all related data in single query:
\`\`\`typescript
// Before: N+1 queries
for (const order of orders) {
  order.items = await db.getItems(order.id);
}

// After: 2 queries
const orderIds = orders.map(o => o.id);
const allItems = await db.getItemsByOrderIds(orderIds);
\`\`\`

Positive Feedback

## Positive Feedback

- Good separation of concerns between service and repository layers
- Comprehensive error handling with specific error types
- Well-structured tests covering edge cases

Review Tone

• Be constructive, not critical
• Explain the "why" behind suggestions
• Acknowledge good work
• Use "we" and "let's" not "you should"
• Ask questions when intent is unclear
• Distinguish between must-fix and nice-to-have

Questions to Ask

If something is unclear:

• "What's the expected behavior when X happens?"
• "Is there a reason this approach was chosen over Y?"
• "Could you help me understand this section?"