This is a strict guideline. Follow these rules exactly.
Multi-perspective code analysis strategy for comprehensive reviews.
Review Strategy
Analyze code from four parallel perspectives:
- Architecture - Alignment with patterns and principles
- Security - Vulnerabilities and risks
- Performance - Optimization opportunities
- Quality - Maintainability and conventions
Architecture Review
Check for:
- Alignment with CORE_PRINCIPLES
- Consistency with established patterns (see INDEX.md)
- Proper separation of concerns
- Module boundaries and dependencies
- File organization
Report:
- Pattern violations with doc references
- Architectural inconsistencies
- Recommendations for better alignment
Security Review
Check for:
- Environment variable handling
- Authentication and authorization flows
- API endpoint security
- Input validation and sanitization
- Token/credential storage
- Sensitive data exposure
Report:
- Security vulnerabilities (critical)
- Potential risks (warnings)
- Best practice recommendations
Performance Review
Check for:
- Inefficient algorithms or data structures
- Unnecessary computations
- Resource-intensive operations
- Caching opportunities
- Bundle size impact (frontend)
- Database query optimization (backend)
Report:
- Performance bottlenecks
- Optimization opportunities
- Trade-offs to consider
Quality Review
Check for:
- Code readability and clarity
- Naming conventions
- Error handling
- Code duplication
- Test coverage
- Documentation completeness
Report:
- Code quality issues
- Maintainability concerns
- Convention violations
Output Format
Structure findings as:
✅ Strengths
Brief acknowledgment of what works well
🔴 Critical Issues
Must be fixed (security, broken functionality, principle violations)
🟡 Improvements
Important but not urgent (performance, maintainability)
💡 Suggestions
Nice-to-have enhancements (style, minor optimizations)
📋 Action Items
Numbered list of specific changes with file references
Review Process
- Analyze in parallel - Run all four perspectives simultaneously
- Synthesize findings - Combine results, remove duplicates
- Prioritize - Critical → Improvements → Suggestions
- Be specific - Reference files, patterns, and principles
- Be constructive - Acknowledge good patterns, explain reasoning
Responding to PR Review Comments
Workflow
- Triage — Read all comments first. For each one, write a brief description of what needs to change (one line is enough). This becomes your working checklist.
- Work one by one — Pick a comment, fix it, test it, commit it. Then move to the next. Do not batch fixes across comments.
- Reply — After all comments are addressed, reply to each comment thread with the corresponding commit hash and a brief explanation.
Reply format
Fixed in <commit-hash>
[Brief explanation of what changed and why, when non-obvious]
Why this matters
- Each comment maps to exactly one commit, so the reviewer can verify each fix independently
- The checklist with brief descriptions keeps you focused and prevents drift
- Committing after testing (not before) ensures every commit is clean and deployable
Progressive Improvement
If the developer corrects a behavior that this skill should have prevented, suggest a specific amendment to this skill to prevent the same correction in the future.