快速开始
npx skills add mattpocock/skills --skill=domain-modelingnpx skills update domain-modeling功能说明
domain-modeling 在您设计的过程中构建和精炼项目的通用语言——挑战模糊的术语、通过具体场景对关系进行压力测试，并在术语和决策确定的瞬间将其记录下来。
这是一门主动的学科，而非被动的。仅仅阅读 CONTEXT.md 来借用其词汇是任何技能都能做的简单习惯；这个技能是为您正在改变模型时准备的——创造一个新术语、发现代码与您刚说的内容之间的矛盾、记录一个难以逆转的决策。它保持术语表的整洁：CONTEXT.md 是术语表，仅此而已——没有实现细节、没有规格说明、没有草稿。
何时使用
输入 /domain-modeling，或者当任务匹配时智能体会自动调用它——当您正在确定术语、解决一个歧义词或记录一个架构决策时。
当词汇是问题时使用它：两个人对"取消"有不同的理解，"账户"承担了三种职责，或者一个设计对话反复卡在一个从未被精确定义的概念上。如果问题是模块的形态——接缝在哪里、接口有多深——请使用 codebase-design。如果您想在构建之前让计划本身受到质询，请使用 grilling。
前置条件
该技能写入两个位置，两者都是延迟创建的——只有在有内容需要记录时才会创建。已确定的术语进入根目录下的 CONTEXT.md（或者，在由 CONTEXT-MAP.md 标记的多上下文仓库中，进入每个上下文各自的 CONTEXT.md）。决策进入 docs/adr/。不需要预先存在任何东西；第一个确定的术语创建术语表，第一个真正的权衡创建 ADR。
术语表与 ADR
两种产物，两种不同的门槛：
- 术语表（
CONTEXT.md）记录语言。每当一个模糊的术语被规范化，它就会被实时写入——而不是批量写入——这样共享词汇就能与对话保持同步。它始终严格不含任何实现细节。
- ADR 记录一个决策，而且门槛很高：仅在选择难以逆转、脱离上下文令人费解且是真正权衡的结果时才会提出。缺少三者中的任何一个，就不产生 ADR。这就是保持
docs/adr/是重大分支的记录而非日记的原因。
让它发挥作用的关键动作：当您陈述某物如何工作时，该技能会交叉引用代码并揭示矛盾——"您的代码取消的是整个 Order，但您刚才说部分取消是可能的——哪个是对的？"语言和代码被迫达成一致。
有意独立出来
domain-modeling 是构建项目通用语言的单一事实来源，作为一个独立的模型主动调用技能拆分出来，以便任何其他技能都可以调用它。grill-with-docs 在拷问会话运行时依赖它来记录术语和决策，triage 使用它来保持任务使用项目自身的语言，improve-codebase-architecture 在工作时也会调用它。
保持它独立意味着您也可以直接调用它——作为如何精炼模型的参考——而无需承诺这些技能所要求的任何步骤。语言存在于一个地方，所有需要它的东西都指向那里。
在整个流程中的位置
domain-modeling 是一个随时可调用的独立技能，它既可以在固定步骤中运行，也经常在其他技能之下运行。它最接近的相邻技能是 codebase-design，因为共享语言正是让您能够精确命名一个深层模块及其接缝的基础；在下游，一个已确定的术语表正是 to-spec 用来合成为用项目自身语言编写的规格说明的基础。当您不确定哪个技能或流程适合时，可以找 ask-matt 帮您导航。