关于 domain-modeling
domain-modeling 是用于完善项目术语并将确定的定义写入 CONTEXT.md 的技能。它会审视含糊或冲突的术语、对照代码核查，并将决策和 ADR 记录到相应位置。
主要功能
- 01完善并维护项目术语表
- 02质疑含糊或冲突的术语
- 03对照代码核查术语
- 04术语确定时记录定义
- 05通过三项条件判断是否记录 ADR
适用场景
- 01厘清含义重叠的领域术语
- 02解决术语表与代码不一致
- 03记录项目的规范术语
- 04判断某项选择是否需要 ADR
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/domain-modeling确认已加载。
详细介绍
领域建模
在设计过程中积极构建并完善项目术语表。仅仅为了查阅词汇而阅读 CONTEXT.md 是任何技能都会做的事；此技能用于更改模型——质疑术语、探查边界，并在达成共识的当下立即记录下来。
对话期间
当另一项技能负责访谈时（例如 brainstorm 中的 grilling），你应作为被动的副作用运行，而不是充当第二位访谈者。直接默默完成工作——将已确定的术语记录到 CONTEXT.md，交叉核对代码——但任何需要用户参与的事项（质疑、消除歧义、探查边界情况）都不能单独占用一轮：将其交给访谈的单一提问渠道，按依赖顺序一次只问一个问题。只有在你被单独调用时，才由你自己主导提问。
对照术语表质疑术语。 当用户的用法与 CONTEXT.md 冲突时，立即指出：“你的术语表将取消定义为作废整个订单，但你似乎指的是移除一个订单项——到底是哪一种？”
明确模糊的措辞。 当某个术语含糊或含义过多时，提出一个精确的规范术语：“你一直在说账户——你指的是 Customer 还是 User？它们在这里并不相同。”
用边界情况场景进行压力测试。 当概念之间的关系出现时，构造具体场景来考验边界：“一名 Member 在计费周期中途离开，且有一张未付款的 Invoice——他们的 Workspace 会怎样？”要求明确陈述边界，而不是含糊带过。
交叉核对代码。 当用户声称某件事的运作方式时，检查代码是否一致。明确指出矛盾：“术语表（以及你）说支持部分退款，但代码只能全额退款——哪边是对的？”绝不让术语表和代码在不知不觉中相互矛盾。
更新 CONTEXT.md
在术语确定的当下，立即就地更新 CONTEXT.md——绝不把术语表编辑攒到以后；攒下来的术语会被遗忘。如果尚无 CONTEXT.md，则在第一个术语确定时按需创建（从技能集的 templates/CONTEXT.md 开始：作为插件安装时使用 ${CLAUDE_PLUGIN_ROOT}/templates，否则使用相对于此 SKILL.md 的 ../../../templates）。
CONTEXT.md 中只能有一种条目：术语定义。决策写入 ADR；实现细节和规范片段写入规范文档。术语格式：
**Workspace**:
The top-level container a team collaborates in; owns all Notes and Folders.
_Avoid_: project, space, tenant
要有主见：只保留一个规范术语，将其他候选词列入 _Avoid_ 清单并弃用。定义保持简洁，限一到三行——说明事物是什么，而不是如何构建。只收录项目特有的概念；不收录通用编程词汇。
ADR——谨慎使用，通过三项门槛
只有在以下三项全部满足时才提出 ADR：
- 难以撤销——之后改变方向会带来实际成本。
- 脱离上下文会令人意外——未来的读者会问“为什么偏偏要这么做？”
- 确实存在权衡——有真实的备选方案，且因特定理由选择了其中一个。
缺少任何一项 → 不写 ADR。举例来说，一个决定虽然令人意外且确实存在权衡，但容易撤销，则不需要 ADR：搜索框采用 200 ms 防抖，权衡了响应速度和请求量，但之后调整只需改一行代码，因此不满足“难以撤销”。将其记录在代码中，而不是 ADR。格式：docs/adr/NNNN-slug.md（按需创建目录），编号依次递增——扫描已有编号中的最大值，然后加一。正文由简短标题和1–3 句话组成：背景、决策、理由。文档仅此而已；记录决策及其理由才有价值，而不是填满各个章节。
如果新决策与现有 ADR 矛盾，向用户指出冲突并明确解决（按编号取代旧 ADR）。