project-rules/pr-review.mdc

# Pull Request Review

Comprehensive pull request review from multiple perspectives.

## Review Roles:

### 1. Product Manager Review
- **Business Value**: Does this deliver promised value?
- **User Experience**: Will users benefit from this change?
- **Strategic Alignment**: Does it align with product goals?
- **Feature Completeness**: Are all requirements met?
- **Action**: Provide directives for maximum impact

### 2. Developer Review
- **Code Quality**: Is code clean and maintainable?
- **Standards**: Does it follow coding conventions?
- **Performance**: Are there efficiency concerns?
- **Scalability**: Will it handle growth?
- **Refactoring**: Any code that needs improvement?
- **Action**: Suggest specific code improvements

### 3. Quality Engineer Review
- **Test Coverage**: Are all paths tested?
- **Edge Cases**: Are boundary conditions handled?
- **Regression Risk**: Could this break existing features?
- **Test Quality**: Are tests comprehensive and clear?
- **Action**: Identify missing tests and scenarios

### 4. Security Engineer Review
- **Vulnerabilities**: Any security risks?
- **Data Handling**: Is sensitive data protected?
- **Authentication**: Are auth checks proper?
- **Input Validation**: Is user input sanitized?
- **Compliance**: Does it meet security standards?
- **Action**: Flag security concerns immediately

### 5. DevOps Review
- **CI/CD Integration**: Will builds succeed?
- **Configuration**: Are configs properly managed?
- **Infrastructure**: Any deployment concerns?
- **Monitoring**: Are metrics and logs adequate?
- **Rollback**: Can changes be safely reverted?
- **Action**: Ensure smooth deployment

### 6. UI/UX Designer Review
- **Visual Consistency**: Does it match design system?
- **Usability**: Is it intuitive to use?
- **Accessibility**: Is it accessible to all users?
- **Responsive**: Does it work on all devices?
- **Polish**: Any rough edges to smooth?
- **Action**: Ensure delightful user experience

## Review Process:
1. Read PR description and linked issues
2. Review code changes systematically
3. Test functionality locally if applicable
4. Consider each perspective above
5. Leave constructive feedback
6. Approve or request changes

## Key Principle:
**Improvements scheduled for "later" must be addressed NOW!**