关于 domain-modeling
domain-modeling 是用于设计、构建或审查领域模型变更的主动式技能。它通过具体场景检验术语与关系，并将已确定的词汇和重要决策记录在仓库文档中。
主要功能
- 01依据项目词汇表审视术语
- 02澄清模糊或多义表述
- 03用边界场景检验关系
- 04对照代码核查行为描述
- 05及时更新已明确的词汇
- 06为重要权衡酌情提出 ADR
适用场景
- 01设计或修改领域模型
- 02对照实现审查模型行为
- 03在设计过程中记录明确术语
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/domain-modeling确认已加载。
附带文件GLOSSARY-FORMAT.mdADR-FORMAT.md
详细介绍
领域建模
设计时，主动构建并完善项目的领域模型。
这是主动实践：质疑术语、构思边界场景，并在概念明确时立刻记录术语表和决策。
（只是为了了解词汇而阅读 GLOSSARY.md 并不算这项技能：那只是任何技能都能做到的一行习惯。
这项技能适用于你正在改变模型，而不只是使用模型的情况。）
只要模型发生变化，这项实践就适用：无论是设计、构建还是评审。
文件结构
如果项目已有术语表或 ADR，且存放在其他位置或采用其他名称
（例如 CONTEXT.md，或其 AGENTS.md 中所述的位置），就使用现有文件。否则，采用以下布局：
/
├── GLOSSARY.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
按需创建文件：只有需要记录内容时才创建。
如果不存在 GLOSSARY.md，就在第一个术语确定后创建。
如果不存在 docs/adr/，就在需要记录第一个 ADR 时创建。
会话期间
对照术语表提出质疑
当用户使用的术语与 GLOSSARY.md 中的既有用法冲突时，立即指出。
“你的术语表将‘取消’定义为 X，但你似乎指的是 Y。到底是哪一种？”
精确含糊的表述
当用户使用含糊或多义的表述时，提出一个精确的规范术语。 “你说的是‘账户’：指客户还是用户？这是两个不同的概念。”
讨论具体场景
讨论领域关系时，用具体场景进行压力测试。 构思能探查边界情况、促使用户明确概念边界的场景。
对照代码交叉核验
当用户说明某项功能的工作方式时，检查代码是否与之相符。如果发现矛盾，就提出来： “你的代码会取消整个订单，但你刚才说可以部分取消。哪种说法才对？”
在会话中更新 GLOSSARY.md
术语一旦确定，就立即在原处更新 GLOSSARY.md。不要攒到最后再处理：及时记录。
使用 GLOSSARY-FORMAT.md 中的格式。
GLOSSARY.md 中不得包含任何实现细节。
不要把 GLOSSARY.md 当作规范、草稿或实现决策的存放处。
它只是术语表，仅此而已。
谨慎提出 ADR
只有以下三项条件全部满足时，才提出创建 ADR：
- 难以撤销：日后改变主意的代价很高
- 缺少背景时会令人意外：未来的读者会想知道“为什么要这样做？”
- 源自实际权衡：确实存在多个备选方案，并且你基于具体理由选择了其中一个
只要有一项不满足，就跳过 ADR。使用 ADR-FORMAT.md 中的格式。
保持内容最新
当会话中的变更影响到已有记录时，在同一变更中修正记录：
- 术语含义发生变化 → 更新对应条目。
- 决策被撤销或取代 → 编写新的 ADR，并将旧 ADR 标记为
superseded by ADR-NNNN。 不要重写旧 ADR。 - ADR 只有少量事实信息已过时（例如模块重命名、文件移动）→ 直接更正。