Code Review Assistant

This skill performs comprehensive code review following Phoenix/FAAD HMI standards.

When to Use

• Reviewing pull requests or merge requests
• Before creating a commit or PR
• Validating new implementations
• Checking code against standards
• Finding common mistakes before CI/CD

Review Process

Step 1: Read Review Standards (CRITICAL - Do This First!)

ALWAYS start by reading the complete review checklist:

Read ai-guide/_REFERENCE/REVIEW.md

This is the Single Source of Truth for all code review standards, patterns, and checks. It contains:

• MobX patterns and critical checks
• UI component requirements
• Property ViewModel patterns
• Entity ViewModel standards
• Architecture guidelines
• Testing requirements
• Common pitfalls to avoid
• Code quality standards

Do not proceed without reading REVIEW.md - it contains the most up-to-date guidance.

Step 2: Identify Files to Review

Ask User First

• Are you reviewing an MR? (If yes, get MR number)
• Or reviewing local changes before creating MR?
• Specific files/directories to focus on?

For Merge Request Reviews

Use glab CLI to get the complete picture:

• MR description and author's intent
• Existing discussions and reviewer feedback
• CI/CD status
• Full diff with context

Why this matters: MR description tells you the "why" - without it, you might flag intentional decisions as mistakes.

For Local Reviews

Use git diff against the base branch (usually origin/development).

Files to Look For

Once you have the file list, identify:

• ViewModels (*.ts extending BaseViewModel)
• Views (*.tsx with React components)
• Entity ViewModels (*EntityViewModel.ts)
• Model files (/model/*/src/)
• Test files (*.test.ts, *.test.tsx)

Step 3: Apply REVIEW.md Checklist

Follow all categories from REVIEW.md systematically:

1. MobX Patterns - Constructors, observables, actions, async operations
2. UI Components - Phoenix components, observer wrapper, SelectPortal
3. Property ViewModels - Correct VM types, commanded pattern, label converters
4. Entity ViewModels - Base classes, required methods, adapters
5. Architecture - MVVM separation, proper layering, services
6. Testing - Coverage, mocking, edge cases
7. Common Pitfalls - Known issues documented in COMMON_PITFALLS.md
8. Code Quality - Naming, file size, self-documenting code

Important: For each category in REVIEW.md, also read the referenced deep-dive documentation:

• MOBX_ESSENTIALS.md for MobX details
• UI_COMPONENT_GUIDELINES.md for UI standards
• PROPERTY_VIEWMODEL_GUIDE.md for property VM patterns
• ENTITY_ARCHITECTURE.md for entity VM standards
• COMMON_PITFALLS.md for known issues

Step 4: Check Supporting Documentation

If reviewing specific areas, read the relevant guides:

• Model changes → Read MODEL_GENERATION_GUIDE.md
• Server code → Read _SERVER/SERVER.md
• Cross-stack changes → Read CLIENT_SERVER_BRIDGE.md

Step 5: Provide Structured Feedback

If reviewing an MR: Include context from glab mr view at the top:

• MR title and description
• Stated goals/intent
• Any existing reviewer feedback to address

Structure your review output as:

## Code Review Summary

**MR Context** (if applicable):
- MR #123: "Add tactical ballistic missile counting"
- Author's intent: Replace icon string parsing with enum-based filtering
- Existing feedback: None / [summarize existing comments]

### Critical Issues (Must Fix)
1. [File:Line] Issue description with reference to REVIEW.md section
   - Why: Explanation of impact
   - Fix: Suggested solution

### High Priority
1. [File:Line] Issue description
   - Why: Impact explanation
   - Fix: Suggested solution

### Medium Priority
1. [File:Line] Issue description
   - Why: Impact explanation
   - Fix: Suggested solution

### Low Priority / Suggestions
1. [File:Line] Suggestion
   - Why: Improvement reasoning
   - Consider: Alternative approach

### Positive Observations
- ✅ What was done well (be specific)
- ✅ Good patterns to highlight
- ✅ Commendable practices

Severity Levels

Use these consistently based on impact:

• CRITICAL: Breaks build, violates core requirements, data loss risk, changes will be overwritten
• HIGH: Runtime errors likely, major functionality broken, security issues
• MEDIUM: Bugs possible, inconsistent with patterns, poor UX, maintainability concerns
• LOW: Code quality, minor inconsistencies, suggestions for improvement

Questions to Ask User

Before starting the review:

• Which files/directories should I review?
• Full review or specific categories (MobX, UI, Architecture, etc.)?
• Should I suggest fixes or just identify issues?
• Are there specific concerns to focus on?
• Is this for a merge request review?

Key References

When the skill is invoked, always read:

1. REVIEW.md - Complete review checklist (SSoT)
2. Supporting docs as needed based on what's being reviewed:
   • MOBX_ESSENTIALS.md - MobX patterns
   • UI_COMPONENT_GUIDELINES.md - UI standards
   • PROPERTY_VIEWMODEL_GUIDE.md - Property VMs
   • ENTITY_ARCHITECTURE.md - Entity VMs
   • COMMON_PITFALLS.md - Known issues
   • TESTING_GUIDE.md - Testing patterns

Notes

• Always be constructive and specific in feedback
• Reference exact file locations with line numbers
• Cite which standard/pattern from documentation is violated
• Provide actionable fixes, not just criticism
• Acknowledge what's done well to encourage good patterns