| name | domain-modeling |
| description | Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model. |
| 触发词 | 构建和打磨项目的领域模型。当用户想要确定领域术语或通用语言、记录架构决策，或其他技能需要维护领域模型时使用。 |
Build and sharpen a project's domain model.
Actively build and sharpen the project's domain model as you design. This is the active discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely reading CONTEXT.md for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
在设计过程中主动构建和打磨项目领域模型。这是主动的训练——质疑术语、构思边缘场景、在词汇和决策形成的瞬间就把它们写下来。（仅仅读 CONTEXT.md 来获取词汇不算这个技能——那是任何技能都能做的一行功夫。这个技能是为改变模型而存在的，不只是消费它。）
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src//
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/If a CONTEXT-MAP.md exists at the root, the repo has multiple contexts. The map points to where each one lives:
如果根目录存在 CONTEXT-MAP.md，说明仓库有多个上下文。映射表指明了每个上下文的位置：
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← system-wide decisions
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← context-specific decisions
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr//
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← 全系统级决策
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← 上下文专属决策
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/Create files lazily — only when you have something to write. If no CONTEXT.md exists, create one when the first term is resolved. If no docs/adr/ exists, create it when the first ADR is needed.
惰性创建文件——只在有内容要写的时候才创建。如果还不存在 CONTEXT.md，在第一个术语确定时创建它。如果还没有 docs/adr/ 目录，在需要第一个 ADR 时创建它。
When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
当用户使用的术语与 CONTEXT.md 中已有的语言冲突时，立即指出来。"你的词汇表把 'cancellation' 定义为 X，但你似乎指的是 Y —— 到底是哪个？"
When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
当用户使用模糊或过载的术语时，提出一个精确的规范术语。"你说的 'account' —— 是指 Customer 还是 User？这是两个不同的东西。"
When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
在讨论领域关系时，用具体场景进行压力测试。编造能够探索边缘情况的场景，迫使用户精确说明概念之间的边界。
When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
当用户说明某个东西如何工作时，检查代码是否一致。如果发现矛盾，提出来："你的代码取消了整个订单，但你刚才说可以部分取消 —— 哪个是对的？"
When a term is resolved, update CONTEXT.md right there. Don't batch these up — capture them as they happen. Use the format in CONTEXT-FORMAT.md.
术语一旦确定，立即更新 CONTEXT.md。不要等到最后批量处理——随发生随记录。使用 CONTEXT-FORMAT.md 中的格式。
CONTEXT.md should be totally devoid of implementation details. Do not treat CONTEXT.md as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
CONTEXT.md 必须完全不含实现细节。不要将 CONTEXT.md 当作规格说明、草稿纸或实现决策的仓库。它只是一个词汇表，仅此而已。
Only offer to create an ADR when all three are true:
仅当以下三个条件全部满足时才提议创建 ADR：
If any of the three is missing, skip the ADR. Use the format in ADR-FORMAT.md.
三个条件中缺少任意一条，就跳过 ADR。使用 ADR-FORMAT.md 中的格式。