/domain-modeling 技能

它的作用

domain-modeling 构建并打磨一个项目的 通用语言 在你设计时——挑战与词汇表冲突的术语、在你用模糊词的地方强推精确词、用具体场景压力测试关系直到边界精确。

它是 active 纪律，而不是被动的那一种。阅读 CONTEXT.md 借用它的词汇是任何技能都能做到的一行习惯；这个技能是为当你 changing 模型。这正是它打断的原因。它把已解决的术语写入 CONTEXT.md 在它被解决的当下、对话中途，而不是在最后产出整洁的词汇表——因为批处理版本是一个 会话，而内联版本才是会话的实际输出。

何时使用

输入 /domain-modeling，或当任务合适时智能体会自动调用它。实际上，自动调用是技能最薄弱的部分：当 grill-with-docs or wayfinder 说要加载它， models 频繁加载 grilling 并跳过这个。如果一个 追问审视 会话运行并 CONTEXT.md 在最后没有被触碰，那就是发生的情况——连同另一个技能一起点名调用它。

当 words 是问题所在：

前置条件

开头什么都没有。技能写入两个地方，且都惰性创建：

• CONTEXT.md 位于仓库根目录，由第一个被解决的术语创建。在一个有 CONTEXT-MAP.md 在根目录，术语进入每个上下文的 CONTEXT.md 地图指向的东西。
• docs/adr/，由首个达标并记录的 ADR 创建。

开始前什么都不需要存在，也没有任何东西被投机性地创建。

两种产物，两条标准

词汇表和 ADR 被按不同标准对待，而把它们混为一谈正是这个技能大部分麻烦的来源。

ADR 的三项测试缺一不可，否则就没有 ADR。容易逆转的决策只会被逆转；不出意外的决策没人会问；没有真实替代方案的决策，记录的是你做了显而易见的事。

这个 CONTEXT.md 规则才是真正要抓住的那条，因为它是实地会失效的那条。 它是一个词汇表，仅此而已。 如果不加约束，模型会把「写入 CONTEXT.md」当作允许它把你给出的每个答案都持久化的许可，文件就变成了一份不断演进的规格——这是该技能被报告最多的问题，横跨多个模型。

交叉引用，及其边界

让技能运转起来的一招：当你陈述某物如何工作时，它检查代码并浮出矛盾。 「你的代码会取消整个订单，但你刚才说可以部分取消——哪个是对的？」 语言和代码被要求大声对齐，在任何一方被改变之前。

这个局限值得了解。它交叉引用 code 以及已提交的 CONTEXT.md/ADRs 文件夹，仅此而已。它不会搜索你的 issue 追踪器，所以一个几个月前在已关闭 issue 里争论过并有意敲定的命名冲突，会被当作新问题浮出水面。目前 一个开放的请求 来修复；在那之前，变通方案是把指令放进你自己的 docs/agents/domain.md，技能们已经在读取它。

常见问题

我的 CONTEXT.md 有 500 行。1000 行。3000 行。我该怎么办？ 大小是症状，不是病——文件吸收了从不是词汇表材料的实现细节和决策。修复是一条直接指令： /grill-with-docs make my CONTEXT.md more concise and remove any implementation details from it。用它扫描一个臃肿的文件，大部分内容都会消失。只有在 CONTEXT-MAP.md 只在文件真正精简、却仍覆盖读者不愿同时持有的两个领域时拆分；拆分臃肿的文件只会给你几个臃肿的文件。技能在这方面的指引还不够强，无法从一开始就阻止增长，相关的 issue 仍然开放。

为什么它 CONTEXT.md 而不是 GLOSSARY.md? 这是整个技能集里争论最多的命名问题，没有定论。反对当前名字的理由很充分：如果它「只是一个词汇表」， GLOSSARY.md 这么说，而且——正如一位读者所说——「有了 AI 智能体，一切都是 context」。它的存在理由是地图： CONTEXT-MAP.md 指向多个 CONTEXT.md 文件的阅读自然程度，是 GLOSSARY-MAP.md 不会，而且 context 是 DDD 中描述模型有界区域的惯用词。至少有一个人维护本地 fork 纯粹是为了重命名该文件。你也可以这样做，但套装里的每个其他技能都在找 CONTEXT.md，因此一次重命名意味着要修改全部这些地方。

原来的 /ubiquitous-language 去哪了？ 它被移除了，而且不是被弃用。它的工作移入了 domain-modeling，它持续维护整个模型，而不是把一次对话的词汇表倒出来。词汇强制执行的承载更重了，而不是更轻——它现在运行在 追问审视、分流与制图，而不是作为你需要记得单独做的一遍。

怎么为一个没有词汇表的代码库建立词汇表？ 明确地要求它，而不是等它自己积累。 /grill-with-docs help me scaffold my existing repo with a CONTEXT.md 是文档化路线；做好长时间审问的准备——一位用户报告说文件成型前有 50+ 个问题。在存量代码库上，附带式使用构建词汇表的速度太慢了。

我能保留领域模型、同时用我自己的 ADR 格式吗？ 今天还不能干净地做到。词汇表一半和 ADR 一半打包在一个技能里，所以有既定 ADR 惯例的团队——不同模板、不同位置、不同命名——会得到与其内部风格冲突的指令。目前的选择是本地复制技能并编辑，或在仓库自己的智能体文档中覆盖 ADR 惯例。把两者拆开 一个开放的请求.

词汇表真的值回票价吗？它是又一个需要审查的产物，还可能过时。 有时候并不成立，值得诚实地说清在哪里。DDD 越接近实现越没用——回报在上游，在命名和概念对齐上，不在聚合和分层仪式上。同义词控制只在命名边界上重要：模块名、表名、状态枚举、issue 标题、CLI 命令。在普通散文中它重要得多地少。还有一个活跃的反对意见：领域术语压缩沟通 人与人之间 已经共享它们的人，而且智能体对通俗英语描述的反应相同——按这种读法，词汇表的价值是让你和审查者与智能体在做什么保持对齐，而不是让智能体更好。一天的构建，跳过它。而未经过审阅、由智能体撰写的词汇表比没有更糟：它会变成听起来自信的传说，后来的会话把它当作真理。

它能帮我把模糊的提示词转成领域语言吗？ 不，也没有计划做这样一个技能。你自己都不理解的领域语言，一旦写下来就变成毫无意义的废话。这个技能在你有理解之后强制执行精确性——它不制造你没有的词汇。相关的陷阱是只使用领域词汇而不做建模：正确的名词盖在错误的概念结构上，产出的东西读起来正确，其实不然。

做到以下就算成功

• 它在你话说到一半时打断，问你是两个意思中的哪一个，而不是选一个继续。
• CONTEXT.md changes during 对话中，而不是最后一次性涌出。
• 它拒绝为你明天就能撤销的事情写 ADR——并说出三项测试中哪一项失败了。
• 新条目定义某物 is 用一两句话，并点明你在 _Avoid_.
• 当你的代码和你的话不一致时，它把你的代码原样抛回给你。
• CONTEXT.md 变短和变长的频率一样高。

在流程中的位置

domain-modeling 是一个 模型自动调用的参考 运行 underneath 被其他技能使用的频率比它自己单独运行更高。 grill-with-docs 通过一次审问会话驱动它， wayfinder 在绘制地图时加载它， triage 用它来保持 tickets 用项目自己的话，并且 improve-codebase-architecture 在决策成型时调用它。它最近的同类是 codebase-design：这两者是一切之下的词汇层，这一个用于 domain，那个用于模块的 shape。当你只想要这套纪律、而不想走通常引入它的那个技能的步骤时，也可以直接调用它。当你不确定哪个技能合适时， ask-matt 为你指路。