Claude-skill-registry-data moai-alfred-code-reviewer
Enterprise systematic code review orchestrator with TRUST 5 principles, multi-language support, Context7 integration, AI-powered quality checks, SOLID principle validation, security vulnerability detection, and maintainability analysis across 25+ programming languages; activates for code reviews, quality standard validation, TRUST 5 enforcement, architectural audits, and automated review automation
git clone https://github.com/majiayu000/claude-skill-registry-data
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry-data "$T" && mkdir -p ~/.claude/skills && cp -r "$T/data/moai-alfred-code-reviewer-ajbcoding-claude-skill-eval" ~/.claude/skills/majiayu000-claude-skill-registry-data-moai-alfred-code-reviewer && rm -rf "$T"
data/moai-alfred-code-reviewer-ajbcoding-claude-skill-eval/SKILL.mdEnterprise Systematic Code Review Orchestrator v4.0.0
Skill Metadata
| Field | Value |
|---|---|
| Skill Name | moai-alfred-code-reviewer |
| Version | 4.0.0 Enterprise (2025-11-12) |
| Core Framework | TRUST 5 principles, Context7 integration |
| AI Integration | ✅ Context7 MCP, AI quality checks, pattern matching |
| Auto-load | When conducting code reviews or quality checks |
| Languages | 25+ (Python, JavaScript, Go, Rust, Java, etc.) |
| Lines of Content | 950+ with 15+ production examples |
| Progressive Disclosure | 3-level (framework, patterns, advanced) |
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
| Principle | Focus | Review Question |
|---|---|---|
| Single Responsibility | One reason to change | Does this class/function do one thing? |
| Open/Closed | Open for extension, closed for modification | Can behavior be extended without modifying? |
| Liskov Substitution | Substitutable subtypes | Can derived classes replace base without breaking? |
| Interface Segregation | Minimal, specific interfaces | Are clients forced to depend on methods they don't use? |
| Dependency Inversion | Depend on abstractions, not concretions | Do high-level modules depend on low-level implementations? |
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
| Change Type | Severity | Automation | Review Time | Focus Areas |
|---|---|---|---|---|
| Security fix | 🔴 Critical | Full scan | 30+ min | Vulnerabilities, test coverage, audit trail |
| Core architecture | 🔴 Critical | Partial | 45+ min | Design patterns, scalability, consistency |
| Feature (new) | 🟡 Major | Full scan | 30 min | Completeness, TRUST 5, documentation |
| Bug fix | 🟢 Minor | Partial | 15 min | Root cause, test coverage, regressions |
| Documentation | 🟢 Minor | Basic | 5 min | Accuracy, completeness, examples |
| Configuration | 🟡 Medium | Full | 10 min | Security, best practices, side effects |
| Refactoring | 🟢 Minor | Full | 15 min | Behavior preservation, performance |
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
(Code patterns and best practices)moai-alfred-practices
(Refactoring strategies)moai-essentials-refactor
For detailed review checklists: reference.md
For real-world examples: examples.md
Last Updated: 2025-11-12
Status: Production Ready (Enterprise v4.0.0)