Domain Modeling 是一项在设计中主动构建并打磨项目领域模型的技能。它强调主动的纪律性工作：质疑术语、构造边界案例场景，并在术语与决策定型的那一刻把它们写下来。仅仅为了获取词汇而阅读词汇表并不是这项技能——那是任何技能都能做到的简单习惯。这项技能用于你正在改变模型时，而不仅仅是消费模型时。
词语存放的位置
词汇表是 /project-context 技能内的一个参考文件：
/
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── skills/internal/project-context/
├── SKILL.md
├── glossary.md words used across domains
└── domains/
└── <domain>.md words used inside one domain, under ## Words
每个仓库一份词汇表。跨领域使用的术语属于 glossary.md，它在每次会话中都会加载。仅在某一个领域内重要的术语属于该领域文件的 Words 章节，这样一个从不进入该领域的任务就不必为其付出成本。
当你解决一个术语时，先判断它属于这两者中的哪一种，然后再写入。
如果 /project-context 尚不存在，告诉用户运行 /setup-project-context。不要把词汇表散落在仓库根目录。
docs/adr/ 目录在需要第一条 ADR 时才惰性创建。
会话期间
对照词汇表提出质疑
当用户使用的术语与现有语言冲突时，立即指出。“你的词汇表把 'cancellation' 定义为 X，但你的意思似乎是 Y。到底是哪个？”
锐化模糊语言
当用户使用含糊或过载的术语时，提出一个精确的规范术语。“你说的是 'account'：你指的是 Customer 还是 User？这是两个不同的东西。”
讨论具体场景
当讨论领域关系时，用具体场景对其进行压力测试。构造能探查边界案例的场景，迫使用户对概念之间的边界保持精确。
与代码交叉参照
当用户陈述某事物如何运作时，检查代码是否一致。如果发现矛盾，就把它揭示出来：“你的代码取消整个 Order，但你刚才说部分取消是可能的。哪个是对的？”
内联写下术语
当一个术语被解决时，当场写入 glossary.md 或领域文件的 Words。不要批量积攒：在它们发生时捕获。使用 GLOSSARY-FORMAT.md 中的格式。
词汇表只存放词语，别的什么都不放。它不承载实现细节、规格、草稿笔记或决策。决策是领域文件中的 Reason 或 Fence，或者是 ADR。
有节制地提议 ADR
仅当以下三点同时成立时，才提议创建 ADR：
- 难以逆转：日后改变主意的成本是有意义的
- 无上下文时令人意外：未来的读者会疑惑“他们为什么这样做？”
- 是真实权衡的结果：存在真正的备选方案，而你出于特定理由选择了其中一个
如果三点中有任何一点缺失，跳过 ADR。使用 ADR-FORMAT.md 中的格式。
ADR 是一份固定于其撰写时刻的记录，因此永不被修剪。决策的现行影响应写在领域文件的 Reasons 中，用一两句话说明，并链接回该 ADR。