Skip to content

Instantly share code, notes, and snippets.

@Meghatronics

Meghatronics/code-reviewer.SKILL.md

Created March 18, 2026 09:25
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save Meghatronics/3693398f6dfe0b99ac31cf9448f38c3e to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save Meghatronics/3693398f6dfe0b99ac31cf9448f38c3e to your computer and use it in GitHub Desktop.
Download ZIP
Claude Code Reviewer Skill for Flutter apps written with MajorE's playbook
Raw
code-reviewer.SKILL.md
name code-review
description Comprehensive code review skill performing 7-part analysis: 1. Static analysis check 2. Documentation vs implementation comparison 3. Anti-pattern detection against playbook 4. Security audit 5. Dependency evaluation 6. Engineering review 7. Product/UX review TRIGGERS: "review code", "code review", "review pr", "check quality"
allowed-tools Read, Grep, Glob, Bash
env
SKILL_CODE_REVIEW
1

Code Review Skill

Perform comprehensive 7-part code review following team standards.

Review Framework

Part 1: Static Analysis Check

Run Flutter analyze:

flutter analyze

Check for:

  • ❌ Analysis errors (MUST be fixed)
  • ⚠️ Analysis warnings (should be addressed)
  • ℹ️ Analysis info (optional improvements)

Document:

  • Total issues found by severity
  • Specific errors/warnings that block merge
  • Files with most issues

Part 2: Documentation vs Implementation

Compare mission doc against actual implementation:

  1. Read mission doc from .docs/ or lib/features/[feature]/.docs/

  2. Check "What?" section (Scope)

    • ✅ All "In Scope" items implemented
    • ❌ Any "Out of Scope" items accidentally included
    • 📋 Any scope creep detected

  3. Check "Where?" section (Files)

    • ✅ All planned files created/modified
    • ❌ Missing expected files
    • ⚠️ Unexpected files modified

  4. Check "How?" section (Implementation Plan)

    • ✅ Followed proposed technical approach
    • ❌ Deviated from plan without documentation
    • Compare actual architecture vs planned

  5. Check Acceptance Criteria

    • ✅ All criteria met
    • ❌ Incomplete criteria
    • List which criteria are satisfied

Document:

  • Match score (% of requirements met)
  • Critical gaps in implementation
  • Critical gaps in documentation (if implementation exceeds doc)
  • Deviations from plan

Part 3: Anti-Pattern Detection

Check against playbook anti-patterns:

Reference: .playbook/shared/anti-patterns.md

Common anti-patterns to check:

  • ❌ Building widgets with methods instead of classes
  • ❌ Hardcoded values (colors, strings, assets)
  • ❌ Business logic in UI layer
  • ❌ Direct API calls from ViewModels (should use Repository)
  • ❌ God classes (ViewModels with >500 lines)
  • ❌ Missing error handling
  • ❌ Improper dependency injection
  • ❌ Mixing async patterns (Future + Stream incorrectly)
  • ❌ Not following MVVM architecture
  • ❌ Not following Domain → Data → UI layer separation

Check layer-specific patterns:

Domain Layer (lib/**/domain/):

  • ViewModels use ChangeNotifier or StateNotifier
  • No direct repository instantiation (use DI)
  • Business logic properly encapsulated
  • Models are immutable with @freezed or @mappable

Data Layer (lib/**/data/):

  • Repositories handle data access only
  • Proper error handling with Result/Either pattern
  • No business logic in repositories

UI Layer (lib/**/ui/):

  • Views only render and delegate to ViewModel
  • Widgets extracted appropriately (not methods)
  • Proper use of design system components

Services (lib/services/):

  • Services wrap external SDKs properly
  • Registered as singletons/lazy singletons
  • No feature-specific logic

Document:

  • List of anti-patterns found (with file:line references)
  • Severity: Critical / Major / Minor
  • Suggested fixes

Part 4: Security Audit

Check for vulnerabilities:

Authentication & Authorization:

  • ❌ Hardcoded credentials, API keys, tokens
  • ❌ Sensitive data in logs
  • ❌ Insecure storage (should use FlutterSecureStorage)
  • ✅ Proper token refresh handling

Input Validation:

  • ❌ Missing input validation
  • ❌ SQL injection risks (if using raw queries)
  • ❌ Command injection risks
  • ❌ XSS risks (if WebView usage)

Data Protection:

  • ❌ Sensitive data in SharedPreferences (should use secure storage)
  • ❌ PII exposure in error messages
  • ❌ Unencrypted sensitive data transmission
  • ✅ Proper HTTPS usage

Dependencies:

  • ⚠️ Known vulnerabilities in packages
  • ⚠️ Outdated packages with security fixes

Permissions:

  • ⚠️ Unnecessary permissions requested
  • ✅ Proper permission request flow

Document:

  • Security issues found (severity: Critical / High / Medium / Low)
  • Files and lines with vulnerabilities
  • Recommended fixes
  • OWASP Top 10 relevance (if applicable)

Part 5: Dependency Evaluation

If new packages added, evaluate each:

Check pubspec.yaml diff for new dependencies.

For each new package, assess:

  1. Popularity & Maintenance

    • pub.dev likes and pub points
    • Last updated date (< 6 months is good)
    • GitHub stars and activity
    • Number of open issues vs closed

  2. Security

    • Known vulnerabilities
    • Security audit history
    • Permissions requested

  3. Alternatives

    • Are there better alternatives?
    • Why was this package chosen?

  4. Bundle Size Impact

    • Will it significantly increase APK/IPA size?

  5. Platform Support

    • Supports required platforms (Android/iOS)
    • Platform-specific implementation quality

  6. License

    • Compatible with project license
    • No restrictive licenses (GPL, etc.)

Document:

  • List of new packages
  • Assessment for each (✅ Good / ⚠️ Concerns / ❌ Recommend alternative)
  • Bundle size impact estimate
  • Recommended alternatives if concerns exist

Part 6: Engineering Review

General code quality:

Architecture:

  • ✅ Follows MVVM + Clean Architecture
  • ✅ Proper layer separation (Domain / Data / UI)
  • ✅ Dependency injection used correctly
  • ✅ Single Responsibility Principle

Code Quality:

  • ✅ Code is readable and maintainable
  • ✅ Appropriate abstractions (not over-engineered)
  • ✅ DRY principle (no unnecessary duplication)
  • ✅ Proper error handling
  • ✅ Meaningful variable/function names
  • ✅ Comments where logic isn't obvious
  • ⚠️ Complex functions (>50 lines should be split)
  • ⚠️ High cyclomatic complexity

Testing:

  • ✅ Unit tests for ViewModels
  • ✅ Tests for complex business logic
  • ⚠️ Missing tests for critical paths
  • ✅ Tests are meaningful (not just coverage)

Performance:

  • ⚠️ Potential performance bottlenecks
  • ⚠️ Inefficient algorithms
  • ⚠️ Memory leaks (listeners not disposed)
  • ⚠️ Unnecessary rebuilds

Maintainability:

  • ✅ Code is easy to understand
  • ✅ Easy to extend without major changes
  • ✅ Minimal technical debt introduced

Document:

  • Code quality score (1-10)
  • Architectural concerns
  • Testing gaps
  • Performance concerns
  • Maintainability issues
  • Technical debt introduced

Part 7: Product/UX Review

For UI changes or user-facing features:

User Experience:

  • ✅ Intuitive and easy to use
  • ✅ Follows platform conventions (Material/Cupertino)
  • ✅ Consistent with existing app UX
  • ⚠️ Confusing flows or interactions
  • ⚠️ Too many steps to complete task
  • ⚠️ Poor information hierarchy

Visual Design:

  • ✅ Uses design system components (from Zero or project)
  • ✅ Consistent spacing, typography, colors
  • ⚠️ Hardcoded colors instead of theme
  • ⚠️ Inconsistent styling
  • ⚠️ Poor contrast/accessibility

Error Handling:

  • ✅ Clear, actionable error messages
  • ✅ Loading states handled gracefully
  • ✅ Empty states handled
  • ⚠️ Generic error messages
  • ⚠️ No loading indicators

Accessibility:

  • ✅ Proper semantics for screen readers
  • ✅ Sufficient touch target sizes (44x44 minimum)
  • ✅ Keyboard navigation support (if applicable)
  • ⚠️ Missing accessibility labels
  • ⚠️ Poor contrast ratios

Edge Cases:

  • ✅ Long text handled (ellipsis, wrapping)
  • ✅ Small/large screen sizes considered
  • ✅ Offline behavior handled
  • ⚠️ UI breaks with edge case data

Document:

  • UX score (1-10)
  • User flow concerns
  • Visual design issues
  • Accessibility issues
  • Edge cases not handled

Review Output Format

Generate a comprehensive review document:

# Code Review: [PR/Branch/Feature Name]

**Reviewer:** code-review skill
**Date:** [YYYY-MM-DD]
**PR/Branch:** [identifier]
**Mission Doc:** [path if found]

---

## Executive Summary

[2-3 sentence overview of the review]

**Overall Score:** [X/100]
**Verdict:** [LGTM | REQUEST CHANGES]

---

## Part 1: Static Analysis ✓

**Status:** [PASS | FAIL]

- **Errors:** [count]
- **Warnings:** [count]
- **Info:** [count]

### Issues Found:
[List critical issues or "None"]

---

## Part 2: Documentation vs Implementation ✓

**Match Score:** [X%]

### Scope Compliance:
- ✅ [Requirement 1] - Implemented
- ❌ [Requirement 2] - Missing
- ⚠️ [Item] - Out of scope but included

### File Compliance:
- ✅ All planned files present
- ❌ Missing: [files]
- ⚠️ Unexpected: [files]

### Critical Gaps:
[List or "None"]

---

## Part 3: Anti-Pattern Detection ✓

**Anti-Patterns Found:** [count]

### Critical:
[List or "None"]

### Major:
[List or "None"]

### Minor:
[List or "None"]

---

## Part 4: Security Audit ✓

**Security Score:** [PASS | FAIL]

### Critical Issues:
[List or "None"]

### High Priority:
[List or "None"]

### Medium/Low:
[List or "None"]

---

## Part 5: Dependency Evaluation ✓

**New Packages:** [count]

[For each package:]
### [Package Name]
- **Assessment:** [✅ Good | ⚠️ Concerns | ❌ Recommend alternative]
- **Pub Points:** [score]
- **Last Updated:** [date]
- **Concerns:** [list or "None"]

---

## Part 6: Engineering Review ✓

**Code Quality Score:** [X/10]

### Strengths:
[List positive aspects]

### Concerns:
[List issues]

### Testing:
- **Coverage:** [good | needs improvement]
- **Gaps:** [list or "None"]

### Performance:
[Concerns or "No issues"]

### Technical Debt:
[Debt introduced or "Minimal"]

---

## Part 7: Product/UX Review ✓

**UX Score:** [X/10] (N/A if no UI changes)

### Strengths:
[List or "N/A"]

### Issues:
[List or "None"]

### Accessibility:
[Issues or "Good"]

### Edge Cases:
[Concerns or "Handled well"]

---

## Final Verdict

**Overall Score: [X/100]**

### Scoring Breakdown:
- Static Analysis: [X/15]
- Documentation Match: [X/15]
- Anti-Patterns: [X/15]
- Security: [X/20]
- Dependencies: [X/10]
- Engineering: [X/15]
- Product/UX: [X/10]

### Verdict: [LGTM ✅ | REQUEST CHANGES ⚠️]

### Blocking Issues (must fix):
[List critical issues that prevent merge, or "None"]

### Recommended Improvements:
[List non-blocking suggestions]

### Summary:
[2-3 sentences summarizing the review and recommendation]

Scoring Guide

Overall Score Calculation:

Component Max Points Weight
Static Analysis 15 Must be 0 errors for LGTM
Documentation Match 15 >80% required for LGTM
Anti-Patterns 15 No critical patterns for LGTM
Security 20 No critical/high issues for LGTM
Dependencies 10 All packages assessed well
Engineering 15 Code quality >7/10
Product/UX 10 UX score >7/10 or N/A

LGTM Criteria:

  • Overall score ≥ 80/100
  • Zero analysis errors
  • Zero critical security issues
  • Zero critical anti-patterns
  • All acceptance criteria met

REQUEST CHANGES Criteria:

  • Overall score < 80/100
  • OR any critical issues present
  • OR significant gaps in requirements

Usage

This skill should be invoked by the /review command or code-reviewer agent.

Input needed:

  • PR number/URL, branch name, or mission doc path
  • Access to changed files
  • Access to mission doc

Output:

  • Comprehensive review markdown document
  • Saved to .docs/reviews/[pr-number]-review.md
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment