菜单
Use when receiving code review feedback - requires technical evaluation and verification, not performative agreement or blind implementation
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| 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.
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