在 Flutter 项目中设计/重构/审查架构时，用…

当需要为 Flutter 应用添加功能、审查层依赖、修复跨 feature 导入、迁移到 feature-first 或选择架构时，按项目现状落地 MVVM、分层与依赖规则。

适用场景

解决思路

1. 通过检查 `pubspec.yaml`、`lib/` 以及现有的状态管理、路由、DI、网络、持久化和测试约定，确认目标是 Flutter 或 Dart 包。
2. 除非与明确的架构要求冲突或用户明确要求迁移，否则保留现有约定。
3. 选择适合项目的最小架构：中大型应用、团队协作、频繁功能变更或边界清晰的业务能力用 feature-first；小型应用、个人开发或简单 CRUD 流程用 layer-first；只有复杂、可复用或跨多个 Repository 的业务逻辑才加 Domain 层，简单流程中 ViewModel 可直接调用 Repository。
4. 保持 View 声明式且轻薄，ViewModel 负责 UI 状态和命令，Repository 作为应用数据的唯一事实来源，Service 作为外部数据源的无状态包装。
5. 实现任务中，优先按本地模式修改项目结构和代码；只有在确认模板的 import、Dart SDK 特性、状态管理风格和命名与项目匹配后，才引入本技能的模板。
6. 审查任务中，优先报告层违规、跨 feature 导入、状态归属问题、缺失测试和依赖边界不清，而不是泛泛的风格建议。
7. 用仓库的常规命令验证，优先使用 `flutter analyze` 和相关 `flutter test` 套件；否则说明缺失的验证。
8. 仅在高影响决策无法从项目推断时询问用户：新功能的产品边界；结构选择不明确时团队或应用的预期规模；offline-first、同步或冲突解决需求；迁移是增量还是全量。
9. 如果项目不可用或不是 Flutter 项目，基于提供的上下文给出架构计划或审查，不要编造仓库事实，并说明无法进行代码验证。
10. 按需只读取当前任务所需的参考：基础原则或词汇读 `references/concepts.md`；层边界或测试读 `references/layers.md`；feature-first 结构或迁移读 `references/feature-first.md`；MVVM 关系读 `references/mvvm.md`；Command、Result、Repository、DI、offline、optimistic UI 读 `references/design-patterns.md`；Command 模板读 `assets/command.dart`；Result 模板读 `assets/result.dart`；示例片段读 `assets/examples/README.md`。
11. 遵循规范依赖规则：低层不得依赖高层；简单操作中 ViewModel 可直接调用 Repository，只有减少重复或隔离复杂业务逻辑时才引入 use-case。
12. feature 模块不应导入另一个 feature 的实现文件；将共享行为移到 `shared/`，通过 DI 依赖稳定接口，或在边界人为时合并 feature。
13. Repository 拥有其数据类型的变更和同步；Service 应保持无状态，不应拥有业务状态。
14. 不要为了满足架构图而添加文件夹；空的 `domain/`、`use-cases/` 或 barrel 文件在 feature 需要前都是可选的。
15. 完成实现或审查前：检查新 import 是否遵守所选 feature/layer 边界。
16. 检查 ViewModel 是否不直接执行平台、文件或网络 I/O。
17. 检查 Repository 是否保持 UI 无关，Service 交互是否可测试。
18. 运行最接近的可用验证：`flutter analyze`；针对变更 feature 的聚焦 `flutter test` 套件；对复制的 Dart 资产用 `dart format --output=none --set-exit-if-changed` 做仅模板验证。
19. 报告运行的命令、失败、跳过的检查和残留的架构风险。

适用边界 · 注意事项

• 项目不是 Flutter/Dart 包或无法访问仓库时，不要编造仓库事实或假装完成代码验证。
• 不要为了套用架构图而添加空文件夹或 barrel 文件。
• 不要在没有明确需求或减少重复/隔离复杂逻辑价值时引入 use-case 或 Domain 层。