tomevault-io 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?"
Converted and distributed by TomeVault — claim your Tome and manage your conversions.