Menü
模块化拆分与模块间通信的决策技能。在进行架构设计、模块划分、文件结构规划时激活，确保拆分合理、依赖清晰。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
GitHub Release 发布操作规范。在需要发布版本、上传安装包到 GitHub Release 时激活，确保使用正确的命令和流程。
确认/删除等交互弹框统一使用 showTolyPopPicker 底部弹出样式。在需要弹出确认框、删除确认、操作选择时激活，确保交互风格一致。
后端服务启动与数据库操作规范。在需要启动后端服务、运行 API 测试、执行数据库迁移或遇到连接错误时激活，确保使用正确的命令和流程。
功能归档规范。在归档功能版本、更新功能网、创建存档快照时激活，确保节点编号正确、网络图完整。
使用 tolyui_mediax 实现媒体预览。适用于图片九宫格展示、全屏预览、手势缩放、视频播放、Hero 动画等场景。
Flutter Widget/Page 组件代码评审技能。在需要审查组件代码质量、发现设计问题时激活，确保输出结构化的问题清单和改进建议。
Basierend auf der SOC-Berufsklassifikation
| name | modular-design |
| description | 模块化拆分与模块间通信的决策技能。在进行架构设计、模块划分、文件结构规划时激活，确保拆分合理、依赖清晰。 |
| metadata | {"model":"manual","last_modified":"Mon, 12 May 2026 00:00:00 GMT"} |
问：这段代码应该留在当前模块，还是拆出去？
判断流程：
1. 能用一句话说清楚当前模块的职责吗？
→ 能 → 不拆
→ 需要用"和"连接两件事 → 考虑拆
2. 这两块代码的变更理由相同吗？
→ 相同（都是因为"聊天功能变了"才改）→ 不拆，内部分目录就够
→ 不同（一个因为"认证流程变了"，一个因为"用户资料变了"）→ 拆
3. 拆完之后两个模块之间会大量来回调用吗？
→ 会 → 不该拆，它们本来就是一个东西
→ 不会 → 拆
核心原则：按业务域拆，不按技术层。一个业务模块内部包含 data/logic/view 是正常的，不要拆成 chat_network + chat_cache + chat_ui 三个独立包。
问：用目录分区够了，还是需要独立 package/crate？
判断流程：
1. 模块边界稳定了吗？
→ 还在探索阶段，边界可能变 → 逻辑隔离（目录分区）
→ 边界已经清晰稳定 → 考虑物理隔离
2. 有没有出现"不小心 import 了不该 import 的东西"？
→ 没有 → 逻辑隔离够用
→ 有，而且靠 code review 拦不住 → 物理隔离
3. 这个模块需要被多个项目复用吗？
→ 是 → 物理隔离
→ 否 → 看前两条
物理隔离后：barrel file（入口文件）就是模块的公开 API。没导出的，对外界就是不存在的。内部随便重构，只要 barrel file 不变，外界无感。
问：A 模块需要和 B 模块交换信息，用什么方式？
优先级（从简单到复杂）：
1. 直接调用 → A import B 的公开 API，直接调方法
适用：A 依赖 B，方向清晰，B 的接口稳定
2. 回调/闭包 → A 把函数注入 B，B 在合适时机调用
适用：B 需要 A 的信息但不能依赖 A（如底层需要高层的 Token）
3. Stream/事件 → B 广播事件，A 订阅监听
适用：一对多通知，发布方不关心谁在听
4. 组装层中转 → A 和 B 互不依赖，由 main.dart 把 A 的输出接到 B 的输入
适用：两个平级业务域完全独立
选择原则：能用 1 解决的别用 2，能用 2 解决的别用 3。
问：这个依赖关系安全吗？
规则：
- 短命依赖长命 → 安全（聊天页依赖 WsClient ✓）
- 长命依赖短命 → 危险（WsClient 持有聊天页引用 ✗）
- 上层依赖下层 → 正常（View → Cubit → Repository ✓）
- 下层依赖上层 → 违规（Repository import View ✗）
- 平级互相依赖 → 循环依赖，需要重构
长命通知短命的正确方式：Stream/事件。短命的订阅，用完取消，互不牵连。
问：这个类/组件应该放到 shared 模块吗？
判断流程：
1. 它被几个模块使用？
→ 只有一个 → 留在那个模块里
→ 两个及以上 → 考虑放 shared
2. 它和业务逻辑有关吗？
→ 有（如 Conversation 模型）→ 放到对应的业务模块，让其他模块依赖它
→ 没有（如 AvatarWidget、SearchBar）→ 放 shared
3. shared 模块是不是越来越大了？
→ 是 → 审视一下，有没有只被一个模块用的东西混进来了
改了底层模块的类，上层所有引用该类的模块都可能需要同步更新。
问：一个新功能应该加到现有模块里，还是独立出去？
判断流程：
1. 现有模块是否已经稳定（很少变更）？
→ 是 → 继续判断
→ 否（本身也在频繁变更）→ 加进去，一起迭代
2. 新功能是否可能频繁变更、反复调整？
→ 是 → 独立出去，不要让不稳定的部分拖累稳定的模块
→ 否（一次性做完就不动了）→ 加进去
3. 新功能的变更是否会导致现有模块的消费方被迫跟着改？
→ 会 → 必须独立，否则每次调整都是连锁反应
→ 不会（内部变更，公开 API 不变）→ 可以加进去
核心原则：稳定的模块是系统的地基，不要往地基里塞实验性的东西。把不确定的、可能反复调整的功能隔离到独立模块，让它自己折腾，不影响已经稳定运行的部分。
问：这段代码将来可能被其他模块/项目复用吗？
判断流程：
1. 它是否和具体业务逻辑无关（纯工具、纯 UI 组件、纯算法）？
→ 是 → 适合独立成可复用模块
→ 否 → 留在业务模块内部
2. 它的接口是否足够通用（不依赖特定的业务类型）？
→ 是 → 可以抽出来
→ 否（参数里有业务模型）→ 先留着，等第二个消费方出现再抽
3. 现在就有多个消费方吗？
→ 是 → 抽出来
→ 否（只是"将来可能"）→ 不要过早抽象，等真正需要时再动
核心原则：不要为了"将来可能复用"就提前抽象。过早抽象的代价是：接口设计基于猜测而非真实需求，等真正的第二个消费方出现时，往往发现接口不对，还得重来。等到第二个消费方真的出现了，再抽也不迟。