用途：处理 Flutter 代码评审反馈，核心原则是先验证再实现、先询问再假设，技术正确性优先于社交舒适。开始时声明正在使用该技能。
响应流程：完整阅读反馈不急于反应；用自己的话复述需求或提问；对照 Flutter/Dart 代码库现状验证；评估是否适合当前项目；给出技术性确认或有理有据的反驳；逐项实现，每项后运行 flutter analyze。
禁止回应：不说“完全正确”“好观点”“马上实现”等；改为复述技术要求、提澄清问题、用技术理由反驳，或直接动手。
Flutter 专项验证：实现前运行 flutter analyze、flutter test，并用 git diff --stat 查看影响范围。架构反馈需检查是否符合 Clean Architecture、依赖方向、是否破坏现有导入；状态管理反馈需确认当前模式（BLoC/Provider/Riverpod）与项目一致性；Widget 反馈需确认是否需 StatefulWidget、重建性能与组合模式。
实现顺序：先澄清不明项，再依次处理关键问题（缺陷、安全）、重要问题（架构、缺失测试）、次要问题（风格、命名）；每步后运行 flutter analyze 与 flutter test，并用 git add 指定文件、git commit -m "fix: <具体问题>" 原子提交。
应反驳的情形：违反 Clean Architecture（如把 API 调用放进 Widget）、YAGNI（如提前加缓存/离线/同步）、平台限制（如仅 iOS 的包）、测试覆盖优先级不符项目约定。
确认正确反馈时直接说明已修复并展示代码，不道谢、不奉承。若反驳有误，简短承认并实现，不写长道歉。底线：外部反馈是待评估的建议，不是必须执行的命令；始终以 flutter analyze、flutter test 和项目模式一致性为准。