关于 domain-modeling
用于在设计过程中主动完善项目领域模型的技能，帮助团队厘清术语、通过具体场景和代码检验领域边界，并维护词汇表及必要的 ADR。
主要功能
- 01对照词汇表审视术语
- 02厘清含糊的领域语言
- 03用场景测试边界情况
- 04依据代码核对描述
- 05及时更新 CONTEXT.md
- 06有选择地编写 ADR
适用场景
- 01解决相互冲突的领域术语
- 02区分含义重叠的概念
- 03对照实现检查领域规则
- 04记录确定的词汇与决策
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/domain-modeling确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
ADR-FORMAT.mdCONTEXT-FORMAT.mdagents/openai.yaml详细介绍
领域建模
在设计过程中，主动构建并完善项目的领域模型。这是一项主动的实践——质疑术语、构思边界场景，并在术语和决策明确时立即记录到词汇表中。（只是阅读 CONTEXT.md 来了解词汇并不属于这项技能——那是一行代码就能完成的习惯，任何技能都可以做到。这项技能针对的是你正在改变模型，而不只是使用模型的情况。）
文件结构
大多数仓库只有一个上下文：
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
如果根目录下存在 CONTEXT-MAP.md，则说明仓库包含多个上下文。该映射会指出每个上下文的位置：
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← decisões de sistema
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← decisões específicas do contexto
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
仅在需要写入内容时才创建文件。如果不存在 CONTEXT.md，就在第一个术语得到确认时创建。如果不存在 docs/adr/，就在需要编写第一个 ADR 时创建。
会话期间
对照词汇表提出质疑
当用户使用的术语与 CONTEXT.md 中已有的用法冲突时，立即指出。“你的词汇表将 ‘cancellation’ 定义为 X，但你似乎想表达 Y——你指的是哪一个？”
准确表达模糊的语言
当用户使用模糊或含义过多的术语时，提出一个精确的规范术语。“你说的是 ‘account’——指的是 Customer 还是 User？它们是不同的概念。”
讨论具体场景
讨论领域关系时，用具体场景进行压力测试。构思能够探查边界情况、促使用户明确概念之间界限的场景。
对照代码核查
当用户说明某项功能如何运作时，核查代码是否一致。如果发现矛盾，就指出来：“你的代码会取消整个 Order，但你刚才说可以部分取消——哪一种说法才正确？”
直接更新 CONTEXT.md
术语得到确认后，立即在原处更新 CONTEXT.md。不要积攒内容——确认时就记录。使用 CONTEXT-FORMAT.md 中的格式。
CONTEXT.md 不得包含任何实现细节。不要把 CONTEXT.md 当作规范、草稿或实现决策的存储库。它只是词汇表，仅此而已。
谨慎提出 ADR
只有同时满足以下三个条件时，才建议创建 ADR：
- 难以撤销——之后改变主意的成本很高
- 没有背景信息就会令人意外——未来的读者会想知道“他们为什么要这么做？”
- 源于真实的权衡——存在真正的备选方案，并且你基于特定原因选择了其中一个
缺少任何一个条件，都不要创建 ADR。使用 ADR-FORMAT.md 中的格式。