Moai Alfred Code Reviewer

Enterprise Systematic Code Review Orchestrator v4.0.0

Skill Metadata

---

What It Does

Provides systematic guidance for enterprise-grade code review processes applying TRUST 5 principles, validating SOLID principles, identifying security issues, ensuring maintainability, and automating quality gates across all programming languages.

---

The TRUST 5 Review Framework

T - Test First

Focus: Test coverage, quality, comprehensiveness

Key Questions:

• Are tests comprehensive? Do they cover happy path + edge cases?
• Test coverage ≥ 85%?
• Tests verify behavior, not just implementation?
• Edge cases handled: null, empty, boundary values?
• Async/​concurrent scenarios tested?

Tools: pytest coverage, jest --coverage, go test -cover, cargo test

Examples:

# ❌ Bad: Tests implementation, not behavior
def test_add():
    assert add(2, 2) == 4

# ✅ Good: Tests behavior with edge cases
def test_add_positive_numbers():
    assert add(2, 2) == 4
    assert add(-1, 1) == 0
    assert add(0, 0) == 0
    
def test_add_boundary():
    assert add(int.max, 1) == overflow_behavior()

R - Readable

Focus: Code clarity, self-documentation, maintainability

Key Questions:

• Are function/​variable names meaningful and clear?
• Can a new team member understand the intent?
• Comments explain WHY, not WHAT (code shows what)?
• Cyclomatic complexity reasonable (<10)?
• Functions single responsibility?
• Magic numbers extracted as constants?

Tools: linters, code formatters, readability checkers

Examples:

# ❌ Bad: Unclear intent
def calc(x, y, z):
    return x * (1 + y / 100) - z * 0.05

# ✅ Good: Clear intent with constants
DISCOUNT_RATE = 0.05
TAX_RATE = 0.05

def calculate_final_price(base_price: float, tax_percent: float, discount: float) -> float:
    """Calculate final price after tax and discount.
    
    Args:
        base_price: Original product price
        tax_percent: Tax percentage (0-100)
        discount: Discount amount to subtract
    """
    with_tax = base_price * (1 + tax_percent / 100)
    return with_tax - (discount * DISCOUNT_RATE)

U - Unified

Focus: Consistency, patterns, architectural cohesion

Key Questions:

• Does code follow team patterns and conventions?
• Consistent with codebase style?
• Uses established error handling patterns?
• Logging strategy aligned?
• Database access follows repository pattern?
• API design consistent with existing endpoints?

Tools: style guides, architectural patterns, linters

Examples:

# ❌ Bad: Inconsistent error handling
def get_user(user_id):
    try:
        return fetch_from_db(user_id)
    except Exception as e:
        return None  # Inconsistent with rest of codebase

# ✅ Good: Consistent error handling
def get_user(user_id: int) -> User:
    """Get user by ID.
    
    Raises:
        UserNotFoundError: If user doesn't exist
        DatabaseError: If database connection fails
    """
    try:
        return self.user_repository.find_by_id(user_id)
    except DatabaseConnectionError as e:
        logger.error(f"Database error: {e}")
        raise DatabaseError(str(e)) from e
    except Exception as e:
        logger.error(f"Unexpected error: {e}")
        raise

S - Secured

Focus: Security vulnerabilities, input validation, secret handling

Key Questions:

• Are inputs validated before use?
• No hardcoded credentials, API keys, or secrets?
• SQL injection prevention (parameterized queries)?
• XSS prevention (output escaping)?
• CSRF tokens used for state-changing operations?
• Authentication required for sensitive operations?
• Rate limiting on public endpoints?
• Dependency vulnerabilities scanned?

Tools: bandit, safety, npm audit, go vet, security scanners

Examples:

# ❌ Bad: SQL injection vulnerability
def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"  # Vulnerable!
    return db.execute(query)

# ✅ Good: Parameterized query
def get_user(user_id: int) -> User:
    query = "SELECT * FROM users WHERE id = ?"
    return db.execute(query, [user_id])

T - Trackable

Key Questions:

• Changelog entry added?
• Git history clear and atomic?
• Breaking changes documented?
• Migration guides for version updates?

Examples:

# ❌ Bad: No traceability
def calculate_discount(price, customer_type):
    if customer_type == "vip":
        return price * 0.8
    return price

# ✅ Good: Full traceability
def calculate_discount(price: float, customer_type: str) -> float:
    """Calculate discount based on customer type.
    
    Implements SPEC-042: VIP customers receive 20% discount
    
    Linked to:
    - SPEC-042: VIP pricing requirements
    - TEST-042-001: VIP discount validation
    - PR #1234: Feature implementation
    """
    VIP_DISCOUNT_RATE = 0.20
    
    if customer_type == "vip":
        return price * (1 - VIP_DISCOUNT_RATE)
    return price

---

SOLID Principles Checklist

---

Code Review Process (4-Step)

Step 1: Automated Checks (5 min)

✓ Linting & formatting
✓ Security scanning (bandit, safety, npm audit)
✓ Dependency vulnerabilities
✓ Test coverage ≥85%
✓ Type checking (mypy, TypeScript, etc.)

Step 2: Architecture Review (15 min)

✓ SOLID principles
✓ Design patterns appropriate?
✓ Consistency with codebase
✓ Scalability implications?
✓ Performance implications?

Step 3: Security Audit (10 min)

✓ Input validation
✓ No hardcoded secrets
✓ Authentication/​authorization correct?
✓ SQL injection prevention
✓ XSS prevention
✓ CSRF tokens present

Step 4: Implementation Review (20 min)

✓ TRUST 5 checklist
✓ Edge cases handled?
✓ Error messages helpful?
✓ Documentation complete?

---

Review Depth Matrix

---

Best Practices

DO

• Automate repetitive checks: Linting, coverage, formatting
• Focus human review on high-value areas: Architecture, security, design
• Be constructive: Review code, not people
• Explain WHY: Help reviewer understand the reasoning
• Request specific changes: Not vague "improve this"
• Provide examples: Show the better approach
• Flag trade-offs: Explain choices made
• Document decisions: Comment on why certain patterns chosen

DON'T

• Nitpick style: Let linters handle formatting
• Reject without alternatives: Always suggest improvements
• Make personal comments: Focus on code quality
• Review when tired: Quality suffers
• Block on minor issues: Distinguish critical from nice-to-have
• Skip security review: Always check authentication, validation, secrets
• Ignore test coverage: Enforce ≥85% requirement

---

Integration with Context7

Live Security Scanning: Get latest vulnerability patterns from official databases
Best Practice Integration: Apply latest security recommendations from official docs
Version-Aware Checks: Context7 provides version-specific security guidance
Automated Fix Suggestions: Context7 patterns for common vulnerability fixes

---

Related Skills

• moai-alfred-practices (Code patterns and best practices)
• moai-essentials-refactor (Refactoring strategies)

---

For detailed review checklists: reference.md
For real-world examples: examples.md
Last Updated: 2025-11-12
Status: Production Ready (Enterprise v4.0.0)