在讨论业务规则时澄清含糊概念，把确定下来的术语写入 CONTEXT.md，必要时记录架构决策。
安装与准备
在项目目录的终端执行以下命令，安装后在 Claude Code 中输入下方提示。这里选择项目内的可编辑文件安装。
npx skills@latest add mattpocock/skills --skill domain-modeling --agent claude-code
使用 Codex 时，把安装命令最后的 claude-code 换成 codex，对话里把 /domain-modeling 换成 $domain-modeling。如果使用完整的 Claude Code 插件，则选择 /mattpocock-skills:domain-modeling，不要再重复安装文件版本。
先打开实际代码仓库，提供现有术语表和业务规则。多业务域项目如果有 CONTEXT-MAP.md，应先确认当前讨论属于哪个上下文。
第一次使用
把下面的场景和路径替换成你的项目情况，在 Agent 对话里输入：
/domain-modeling
我们订单系统里“取消”和“退款”被混用了。请结合代码与现有 CONTEXT.md，讨论已付款、部分发货、部分退款这三个场景，统一术语。
怎样推进任务
用具体情景拆开概念
不要先让 Agent 生成一整套空泛词典。拿一张已经付款又部分发货的订单，讨论取消的是订单、剩余商品还是履约任务；退款是金额动作还是状态变化。边界清楚之后，再决定术语名称。
对照代码里的真实行为
如果业务讨论允许部分取消，而代码只能取消整个订单，让 Agent 把差异摆出来。决定是修改业务约定还是后续调整实现，然后再更新术语；否则新文档会让后来的人产生错误预期。
分开保存词义与决策
CONTEXT.md 只保存业务术语及其关系。真正有取舍、以后难改且需要解释原因的决定，才适合放进 docs/adr/。比如退款流水是否独立于订单状态值得讨论；变量重命名通常不用专门写 ADR。
完成后检查什么
拿最初的三个订单场景重新阅读术语表：同一个词是否只指同一个概念，关键边界是否清楚，文档和代码之间的差异是否已安排后续处理。检查文件修改后再交给团队使用。
常见问题
会自动设计数据库吗？ 它帮助讨论领域模型，具体数据库设计仍需另外明确任务。
没有 CONTEXT.md？ 确定第一个术语后才需要创建，先讨论具体问题即可。
什么时候用 grill-with-docs？ 需要持续追问需求并同步记录术语时，可用它组织整段访谈。
让术语能约束下一次讨论
确定一个词以后，不只写“取消是结束订单”，还要写它不包含什么，并列出以后应避免使用的混淆旧词。例如“取消未履约部分”不能被叫成“退款”，因为前者改变履约范围，后者涉及已付金额。作者的格式允许用 Avoid 标出被放弃的称呼；下次需求、代码和客服话术再次出现旧词时，就能及时追问。条目应在讨论中逐步落盘，而不是会后一次生成完整词典。
如果 CONTEXT.md 越来越长，先删掉实现细节、操作计划和临时决定；它应保留词义，不承担规格书的工作。只有词典已经精简、业务域仍彼此独立时，再考虑由 CONTEXT-MAP.md 指向多个上下文文件。ADR 的门槛更高：需要有真实取舍、以后难以随意撤回，而且原因值得未来的人理解。能轻易改回的命名或格式选择不必硬写成一项架构决策。
试用转付费时，先把“用户”拆开
另一个适用场景是订阅产品里“试用结束后自动续费”：购买者、受益者和管理账号可能并非同一人。可以输入：“用 domain-modeling 澄清订阅、席位、试用和账单归属；先检查代码里 trialEndsAt、subscriptionOwner 的实际用法，再用家庭套餐里成员退出的情景检验术语。”让 Agent 写出每个词指什么、不指什么，并列出应避免的旧称呼。
验收时拿同一情景逐条套入 CONTEXT.md：成员退出后是取消席位、取消订阅，还是停止下一次扣费？如果文档说一个意思而代码执行另一个，应将差异列成后续工作，不要直接用好看的定义掩盖实现。若 Agent 一开始写出十几个词却没有通过具体情景追问，说明它在批量造词典，先收回到眼前的争议。
从一个有争议的词开始
一份实际使用教程举过 “account” 同时指客户和登录用户的例子：先让 Agent 查出现有代码如何使用这个词，再讨论哪些含义应拆成 Customer、User 等明确术语，确认后立即写入 CONTEXT.md。若是多年积累、几乎没文档的大仓库，增量记录无法一次覆盖所有领域；可先只读梳理候选词和冲突，再由熟悉业务的人逐项确认，不要让 Agent 把猜出的术语直接当成正式规范。