flutter-review-receive

name	flutter-review-receive
description	Use when receiving code review feedback - requires technical evaluation and verification, not performative agreement or blind implementation

Flutter Code Review Reception

Overview

Code review requires technical evaluation, not emotional performance.

Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

Announce at start: "I'm using the flutter-review-receive skill to process this feedback."

The Response Pattern

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against Flutter/Dart codebase reality
4. EVALUATE: Technically sound for THIS Flutter project?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, run flutter analyze after each

Forbidden Responses

NEVER:

• "You're absolutely right!"
• "Great point!" / "Excellent feedback!"
• "Let me implement that now" (before verification)

INSTEAD:

• Restate the technical requirement
• Ask clarifying questions
• Push back with technical reasoning if wrong
• Just start working (actions > words)

Flutter-Specific Verification

Before Implementing Any Feedback

# Check current state
flutter analyze
flutter test

# Check what feedback affects
git diff --stat

Clean Architecture Feedback

IF reviewer suggests architecture change:
  1. Check: Does current structure follow Clean Architecture?
  2. Check: Are dependencies pointing correct direction?
  3. Check: Will change break existing imports?

Example:
Reviewer: "Move UserModel to domain layer"
✅ VERIFY: "Models with fromJson/toJson belong in data layer, not domain.
           Entities in domain should be pure Dart. Is there a specific reason
           to move this?"

State Management Feedback

IF reviewer suggests state management change:
  1. Check: What pattern is currently used? (BLoC/Provider/Riverpod)
  2. Check: Is suggestion compatible with project patterns?
  3. Check: Will change break existing state flow?

Example:
Reviewer: "Use Provider instead of BLoC here"
✅ VERIFY: "Project uses BLoC consistently. Mixing patterns would add complexity.
           Is there a specific reason Provider is better for this case?"

Widget Feedback

IF reviewer suggests widget change:
  1. Check: Does widget need to be StatefulWidget?
  2. Check: Will change affect rebuild performance?
  3. Check: Does change follow composition patterns?

Example:
Reviewer: "Convert to StatefulWidget for animation"
✅ VERIFY: "Checking if AnimationController is needed... Yes, animation requires
           TickerProvider. Converting to StatefulWidget with SingleTickerProviderStateMixin."

Implementation Order

For multi-item feedback, implement in this order:

1. Clarify anything unclear FIRST

2. Then implement:

   • Critical issues (bugs, security)
   • Important issues (architecture, missing tests)
   • Minor issues (style, naming)

3. After each fix:

   flutter analyze
   flutter test
   

4. Commit atomically:

   git add <specific files>
   git commit -m "fix: <specific issue from review>"
   

When To Push Back

Push back when:

Clean Architecture Violations

Reviewer: "Just put the API call in the widget"
❌ WRONG: Implement anyway
✅ RIGHT: "This would violate Clean Architecture - API calls belong in
          DataSource/Repository, not Presentation. Current structure is correct."

YAGNI Violations

Reviewer: "Add caching, offline support, and sync"
✅ RIGHT: "Current requirements don't include offline support. Adding caching
          now would be YAGNI. Should we keep scope focused?"

Platform-Specific Concerns

Reviewer: "Use this iOS-only package"
✅ RIGHT: "This package is iOS-only but we support Android too.
          Should we find a cross-platform alternative?"

Test Coverage

Reviewer: "Add integration tests for everything"
✅ RIGHT: "Following project test priority: Repository/DataSource first,
          then State management, then Widget tests. Integration tests
          are optional. Current coverage follows this pattern."

Acknowledging Correct Feedback

When feedback IS correct:

✅ "Fixed. Updated AuthBloc to handle timeout errors."
✅ "Good catch - missing null check in UserModel.fromJson. Fixed."
✅ [Just fix it and show in the code]

❌ "You're absolutely right!"
❌ "Great point!"
❌ "Thanks for catching that!"

Why no thanks: Actions speak. Just fix it. The code itself shows you heard the feedback.

Common Flutter Review Issues

Feedback	Verification
"Add tests"	Check test priority - Repository first, then State, then Widget
"Use const"	Check if all parameters are compile-time constants
"Split widget"	Check if widget is > 100 lines or has multiple responsibilities
"Change state management"	Check project consistency - don't mix patterns
"Move to domain layer"	Check if it has framework dependencies (it shouldn't)
"Add error handling"	Check if BLoC/Provider has error state

Gracefully Correcting Your Pushback

If you pushed back and were wrong:

✅ "Checked flutter test output - you're right, the test fails on Android.
   Implementing the fix now."

✅ "Verified in DevTools - the rebuild is happening. Converting to const
   as suggested."

❌ Long apology
❌ Defending why you pushed back

The Bottom Line

External feedback = suggestions to evaluate, not orders to follow.

For Flutter specifically:

• Verify against Clean Architecture principles
• Check flutter analyze output
• Run flutter test before and after
• Maintain project patterns consistency

No performative agreement. Technical rigor always.