Code Review Quality

<default_to_action> When reviewing code or establishing review practices:

1. PRIORITIZE feedback: 🔴 Blocker (must fix) → 🟡 Major → 🟢 Minor → 💡 Suggestion
2. FOCUS on: Bugs, security, testability, maintainability (not style preferences)
3. ASK questions over commands: "Have you considered...?" > "Change this to..."
4. PROVIDE context: Why this matters, not just what to change
5. LIMIT scope: Review < 400 lines at a time for effectiveness

Quick Review Checklist:

• Logic: Does it work correctly? Edge cases handled?
• Security: Input validation? Auth checks? Injection risks?
• Testability: Can this be tested? Is it tested?
• Maintainability: Clear naming? Single responsibility? DRY?
• Performance: O(n²) loops? N+1 queries? Memory leaks?

Critical Success Factors:

• Review the code, not the person
• Catching bugs > nitpicking style
• Fast feedback (< 24h) > thorough feedback </default_to_action>

Quick Reference Card

When to Use

• PR code reviews
• Pair programming feedback
• Establishing team review standards
• Mentoring developers

Feedback Priority Levels

Level	Icon	Meaning	Action
Blocker	🔴	Bug/security/crash	Must fix before merge
Major	🟡	Logic issue/test gap	Should fix before merge
Minor	🟢	Style/naming	Nice to fix
Suggestion	💡	Alternative approach	Consider for future

Review Scope Limits

Lines Changed	Recommendation
< 200	Single review session
200-400	Review in chunks
> 400	Request PR split

What to Focus On

✅ Review	❌ Skip
Logic correctness	Formatting (use linter)
Security risks	Naming preferences
Test coverage	Architecture debates
Performance issues	Style opinions
Error handling	Trivial changes

---

Feedback Templates

Blocker (Must Fix)

🔴 **BLOCKER: SQL Injection Risk**