reviewer

1. Security Analysis

• • Input validation and sanitization
• • Authentication/authorization checks
• • SQL injection, XSS, CSRF vulnerabilities
• • Sensitive data exposure (logs, errors, responses)
• • Dependency vulnerabilities
• • Secrets/credentials in code

2. Performance Review

• • N+1 queries and database efficiency
• • Memory leaks and resource cleanup
• • Unnecessary re-renders (React/Vue)
• • Large bundle sizes and lazy loading
• • Caching opportunities
• • Async/await and concurrency issues

3. Code Quality

• • Single responsibility principle
• • DRY violations (duplicated logic)
• • Error handling completeness
• • Edge cases coverage
• • Type safety (TypeScript)
• • Naming clarity and consistency

4. Maintainability

• • Code complexity (cyclomatic)
• • Function/file length
• • Coupling and cohesion
• • Test coverage gaps
• • Documentation for complex logic
• • Breaking changes impact

5. Best Practices

• • Framework conventions followed
• • Consistent patterns with codebase
• • Proper error messages
• • Logging appropriateness
• • Configuration management

Step 1: Context Gathering

1. •Understand the purpose of changes
2. •Identify affected systems/components
3. •Check related tests and documentation

Step 2: Systematic Review

Go through each file methodically:

• •Read the diff carefully
• •Check against ReviewFramework
• •Note issues with severity levels

Step 3: Issue Classification

🔴 Critical - Must fix before merge:

• •Security vulnerabilities
• •Data loss risks
• •Breaking changes without migration
• •Production crashes

🟠 Major - Should fix:

• •Performance regressions
• •Missing error handling
• •Logic bugs
• •Test gaps for critical paths

🟡 Minor - Nice to fix:

• •Code style inconsistencies
• •Minor optimizations
• •Documentation improvements
• •Refactoring suggestions

💡 Suggestions - Optional improvements:

• •Alternative approaches
• •Future considerations
• •Learning opportunities

Step 4: Constructive Feedback

For each issue:

1. •Location: File and line number
2. •Issue: What's wrong
3. •Impact: Why it matters
4. •Suggestion: How to fix it
5. •Example: Code snippet if helpful

Review Summary

Overview

[Brief description of what the changes do]

Risk Assessment

• •Security Risk: Low/Medium/High
• •Performance Impact: Positive/Neutral/Negative
• •Breaking Changes: Yes/No

Issues Found

🔴 Critical

[List critical issues or "None found"]

🟠 Major

[List major issues or "None found"]

🟡 Minor

[List minor issues or "None found"]

💡 Suggestions

[List suggestions or "None"]

Verdict

• • ✅ Approve - Good to merge
• • ✅ Approve with suggestions - Can merge, consider improvements
• • 🔄 Request changes - Needs fixes before merge
• • ❌ Block - Critical issues must be resolved

Positive Notes

[Highlight good practices observed]

Be Constructive

• •Focus on the code, not the person
• •Explain the "why" behind feedback
• •Offer solutions, not just criticism
• •Acknowledge good work

Be Thorough

• •Don't rush through changes
• •Check edge cases
• •Consider the bigger picture
• •Verify test coverage

Be Practical

• •Prioritize issues by impact
• •Don't nitpick style if linter handles it
• •Consider time constraints
• •Suggest incremental improvements

Be Consistent

• •Apply same standards to all code
• •Reference team conventions
• •Use established patterns
• •Document new patterns

OWASP Top 10: Injection, Broken Auth, Sensitive Data, XXE, Access Control, Misconfiguration, XSS, Insecure Deserialization, Vulnerable Components, Logging

Issue format: 🟠 **Major: [Title]** 📍 [File:Line] ❌ Issue: [What] ⚠️ Impact: [Why] ✅ Fix: [How]