Systematic code review guidance and automation. Apply TRUST 5 principles, check code quality, validate SOLID principles, identify security issues, and ensure maintainability...
| Field | Value |
|---|---|
| Version | 1.0.0 |
| Tier | Quality |
| Auto-load | When conducting code reviews or quality checks |
체κ³μ μΈ μ½λ 리뷰 νλ‘μΈμ€μ μλν κ°μ΄λλ₯Ό μ 곡ν©λλ€. TRUST 5 μμΉ μ μ©, μ½λ νμ§ κ²μ¦, SOLID μμΉ μ€μ, 보μ μ΄μ μλ³, μ μ§λ³΄μμ± λ³΄μ₯μ λ€λ£Ήλλ€.
Code review is a quality assurance process that ensures code meets standards, follows best practices, and maintains long-term maintainability. This skill provides systematic guidance for conducting thorough, effective code reviews.
| Principle | Review Focus | Key Questions | Tools |
|---|---|---|---|
| T - Test First | Test coverage & quality | Are tests comprehensive? Do they test edge cases? | pytest coverage, jest --coverage |
| R - Readable | Code clarity & maintainability | Is code self-documenting? Are names meaningful? | linters, code formatters |
| U - Unified | Consistency & standards | Does it follow team patterns? Is it cohesive? | style guides, architectural patterns |
| S - Secured | Security & vulnerabilities | Are inputs validated? Are secrets handled properly? | security scanners, static analysis |
| T - Trackable | Documentation & traceability | Is code linked to requirements? Are changes documented? | @TAG system, git history |
## Review Decision Matrix
| Change Type | Review Level | Automation | Focus Areas |
|-------------|--------------|------------|-------------|
| Critical security | π΄ Mandatory | Full scan | Vulnerabilities, input validation |
| Core architecture | π‘ Deep review | Partial | Design patterns, scalability |
| Bug fixes | π’ Standard | Automated | Root cause, test coverage |
| Documentation | π’ Light | Basic | Accuracy, completeness |
| Configuration | π’ Automated | Full | Security, best practices |
β
Psychological Safety: Reviews are about code, not people
β
Learning Opportunity: Reviews transfer knowledge and standards
β
Constructive Feedback: Focus on improvement, not criticism
β
Consistent Standards: Apply same criteria to all code
β
Efficient Process: Automated checks first, human review for value-add
β Nitpicking: Focus on style over substance
β Authoritarian: "Do it this way because I said so"
β Incomplete: "Looks good" without specific feedback
β Delayed: Reviews blocking progress for days
β Inconsistent: Different standards for different people
## Review Workflow
1. PRE-REVIEW AUTOMATION (2-5 min)
a. Run linters and formatters
b. Execute test suite with coverage
c. Scan for security vulnerabilities
d. Check for @TAG compliance
2. CODE COMPREHENSION (5-10 min)
a. Read commit message and PR description
b. Understand the problem being solved
c. Identify affected components
d. Review test changes first
3. DETAILED REVIEW (10-20 min)
a. Apply TRUST 5 framework systematically
b. Check architectural consistency
c. Validate error handling
d. Assess performance implications
4. FEEDBACK SYNTHESIS (5 min)
a. Categorize issues: Must-fix, Should-fix, Nice-to-have
b. Provide specific, actionable feedback
c. Explain reasoning behind suggestions
d. Offer to discuss complex changes
## Code Review Checklist
### π§ͺ Test Coverage (T)
- [ ] New features have corresponding tests
- [ ] Test coverage β₯ 85% (or team standard)
- [ ] Edge cases and error conditions tested
- [ ] Integration tests included where appropriate
- [ ] Tests are readable and maintainable
### π Readability (R)
- [ ] Function and variable names are descriptive
- [ ] Complex logic is commented or extracted
- [ ] File length β€ 300 LOC (or team standard)
- [ ] Function length β€ 50 LOC (or team standard)
- [ ] No magic numbers or hardcoded values
### π Unity (U)
- [ ] Follows established team patterns
- [ ] Consistent with existing codebase style
- [ ] Uses shared utilities and libraries
- [ ] Architecture aligns with project structure
- [ ] Imports and dependencies are organized
### π Security (S)
- [ ] Input validation for all user inputs
- [ ] No hardcoded secrets or credentials
- [ ] Proper error handling without information leakage
- [ ] Authentication and authorization checked
- [ ] SQL injection and XSS protection in place
### π·οΈ Traceability (T)
- [ ] Code changes linked to SPEC or issue
- [ ] @TAG references are correct and complete
- [ ] Commit message is clear and descriptive
- [ ] Documentation updated as needed
- [ ] Breaking changes are documented
#!/bin/bash
# .claude/skills/moai-alfred-code-reviewer/scripts/pre-review-check.sh
set -e
echo "π Running automated code review checks..."
# Test Coverage Check
echo "π Checking test coverage..."
python -m pytest --cov=src --cov-fail-under=85 --cov-report=term-missing
# Code Quality Checks
echo "π§Ή Running linters..."
python -m ruff check src/ --show-source
python -m mypy src/ --strict
# Security Scanning
echo "π Scanning for security issues..."
python -m bandit -r src/ -f json -o bandit-report.json
echo "β
All automated checks passed!"
# .pre-commit-config.yaml
repos:
- repo: local
hooks:
- id: security-review
name: Security Review
entry: .claude/skills/moai-alfred-code-reviewer/scripts/security_review.py
language: script
args: [src/]
pass_filenames: false
β
Start with understanding: Read the PR description first
β
Automate first: Let tools catch the obvious issues
β
Focus on value: Spend time on architectural and security concerns
β
Be specific: Provide exact locations and suggestions
β
Explain why: Help the author understand the reasoning
β
Self-review first: Run all automated checks before submitting
β
Write clear descriptions: Explain what and why
β
Keep PRs small: Large changes are harder to review effectively
β
Respond promptly: Address feedback in a timely manner
β
Learn from feedback: Use reviews as learning opportunities
Reference: Code Review Best Practices, TRUST 5 Principles
Version: 1.0.0