Menu
Use when receiving code review feedback - requires technical evaluation and verification, not performative agreement or blind implementation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Creates a new Flutter project with Clean Architecture, domain pattern boilerplate, and production-ready setup
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation using Clean Architecture principles.
Use when you have a written implementation plan to execute with review checkpoints
Use when facing 2+ independent Flutter tasks that can be worked on without shared state or sequential dependencies
Use when you have a design or requirements for a multi-step Flutter feature, before touching code
Use when executing Flutter implementation plans with independent tasks in the current session
| name | flutter-review-receive |
| description | Use when receiving code review feedback - requires technical evaluation and verification, not performative agreement or blind implementation |
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."
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
NEVER:
INSTEAD:
# Check current state
flutter analyze
flutter test
# Check what feedback affects
git diff --stat
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?"
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?"
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."
For multi-item feedback, implement in this order:
Clarify anything unclear FIRST
Then implement:
After each fix:
flutter analyze
flutter test
Commit atomically:
git add <specific files>
git commit -m "fix: <specific issue from review>"
Push back when:
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."
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?"
Reviewer: "Use this iOS-only package"
✅ RIGHT: "This package is iOS-only but we support Android too.
Should we find a cross-platform alternative?"
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."
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.
| 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 |
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
External feedback = suggestions to evaluate, not orders to follow.
For Flutter specifically:
No performative agreement. Technical rigor always.