| 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. |
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 来获取词汇并不是这项技能——那是一行代码即可完成的习惯。此技能用于当你在改变模型时，而不是仅仅消费模型。）
Most repos have a single context:大多数仓库只有单一上下文：
/
├── 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/
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?"当用户说明某事如何工作时，检查代码是否一致。如果发现矛盾，提出并说明：“你的代码会取消整个 Order，但你刚才说部分取消是可能的——到底哪个说法正确？”
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：
- Hard to reverse — the cost of changing your mind later is meaningful难以逆转——以后改变主意的成本相当高
- Surprising without context — a future reader will wonder "why did they do it this way?"缺乏上下文会令人惊讶——未来的阅读者会想‘他们为什么这么做？’
- The result of a real trade-off — there were genuine alternatives and you picked one for specific reasons真实的权衡结果——确实存在多种备选方案，你基于特定原因选择了其中一种
If any of the three is missing, skip the ADR. Use the format in ADR-FORMAT.md.如果上述三点中有任何一点缺失，则跳过 ADR。使用 ADR-FORMAT.md 中的格式。