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:
-
Clarify anything unclear FIRST
-
Then implement:
- Critical issues (bugs, security)
- Important issues (architecture, missing tests)
- Minor issues (style, naming)
-
After each fix:
flutter analyze flutter test -
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.