关于 domain-modeling
domain-modeling 是一项在开发过程中主动建立和完善领域模型的 Skill。它通过澄清术语、检验边界场景并及时记录决策，帮助团队保持模型与代码一致。
主要功能
- 01创建并维护领域术语表
- 02识别并澄清含糊术语
- 03用具体场景检验领域边界
- 04对照代码验证领域描述
- 05按需记录术语与架构决策
适用场景
- 01修改领域模型时统一术语
- 02讨论领域关系与边界情况
- 03发现领域描述和代码实现不一致
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/domain-modeling确认已加载。
附带文件ADR-FORMAT.mdCONTEXT-FORMAT.md
详细介绍
来自项目 README领域建模
在设计过程中主动构建和打磨项目的领域模型。这是一项主动的纪律：挑战术语、构造边界场景、在术语和决策刚成形的时刻就把它们写下来。（仅仅是读 CONTEXT.md 找术语不算这个 skill：那只是任何 skill 都能顺手做的一件小事。这个 skill 用在你正在改变模型、而不只是使用模型的时候。）
文件结构
大多数仓库只有一个上下文：
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
如果根目录存在 CONTEXT-MAP.md，仓库就有多个上下文，这个文件指向每个上下文所在的位置：
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← system-wide decisions
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← context-specific decisions
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
按需创建文件：有东西可写时才创建。如果没有 CONTEXT.md，在第一个术语确定时创建。如果没有 docs/adr/，在需要第一个 ADR 时创建它。多上下文时，先判断当前话题属于哪个上下文。判断不了就问。
会话过程中
对照术语表挑战
当用户使用的术语与 CONTEXT.md 中已有的术语冲突时，立刻指出。“你的术语表把‘取消’定义为 X，但你似乎在说 Y。到底是哪个？”用户确认要改术语时，先更新 CONTEXT.md 再继续。未确认前以文件中的定义为准。
锐化模糊语言
当用户使用模糊或含义重叠的词时，提出一个精确的标准术语。比如用户说“账户”时，问：指的是 Customer 还是 User？这是两个不同的概念。
讨论具体场景
当讨论领域关系时，用具体场景压测它们。构造场景探查边界情况，迫使用户把概念之间的边界说精确。
与代码交叉验证
当用户陈述某事怎么运作时，检查代码是否与之相符。发现矛盾就摆出来：“你的代码取消的是整个 Order，但你刚说支持部分取消。哪个对？”
当场更新 CONTEXT.md
术语确定时，当场更新 CONTEXT.md。不要攒着：发生就记。用 CONTEXT-FORMAT.md 中的格式。
CONTEXT.md 应当完全不包含实现细节。不要把 CONTEXT.md 当成任务要求、草稿本或实现决策的仓库。它就是术语表，不是别的。
克制地提议 ADR
只在以下三条同时为真时才提议创建 ADR：
- 难以撤销：事后改变主意的成本很大
- 缺乏上下文会令人困惑：未来的读者会想“他们为什么这么做？”
- 源于真正的权衡：存在真实的替代方案，你因特定理由选了其中一个
三条缺一条，就跳过 ADR。用 ADR-FORMAT.md 中的格式。