domain-modeling

技能简介

本技能帮助你在设计过程中主动构建并打磨项目的领域模型。它解决“团队对代码库关键术语理解不一致”的问题，引导你在会话中即时记录术语决议，并把必要的架构决策沉淀为 ADR（架构决策记录）。

使用场景

• 讨论代码库术语时，检验用词是否与现有 CONTEXT.md 定义冲突
• 用户使用“account”这类模糊词汇时，澄清其到底指 Customer 还是 User
• 设计领域关系时，用边界场景验证概念之间的界限是否清晰
• 用户描述的实现方式与代码行为不一致时，找出矛盾
• 术语刚确定时，立即更新 CONTEXT.md 或判断是否值得创建 ADR

使用方法

该技能无需额外安装，作为 Agent 内置技能自动生效。核心工作流程如下：

1. 挑战术语表：当用户用词与 CONTEXT.md 冲突时，立即指出并请其确认；
2. 澄清模糊语言：将宽泛或过载的词汇细化为精确的规范术语；
3. 推演具体场景：构造边界案例，压力测试领域关系；
4. 与代码交叉验证：发现描述与代码实现矛盾时，直接说明；
5. 内联更新 CONTEXT.md：术语确定后立刻写入，使用 CONTEXT-FORMAT.md 的格式，不批量积压；
6. 按需生成 ADR：仅当决策难以逆转、未来读者会困惑、且确实经过真实权衡这三条同时成立时才创建，格式见 ADR-FORMAT.md。

文件结构方面：大多数仓库是单一上下文，CONTEXT.md 位于根目录，ADR 位于 docs/adr/。若存在 CONTEXT-MAP.md，则表示仓库包含多个上下文，需按映射分别管理各自的 CONTEXT.md 和 ADR 目录。

注意事项

• CONTEXT.md 只是术语表：不写入实现细节，不充当规范文档或草稿板；
• 文件要“懒创建”：有实际内容要记录时才新建，不提前铺路；
• ADR 宁缺毋滥：上述三个条件缺一不可。