领域建模
在设计过程中主动构建并校准项目的领域模型：质疑术语、构造边界场景，并在词汇和决策明确时立即记录下来。仅仅读取 CONTEXT.md 以沿用词汇不属于此 skill；只有需要改变模型时才使用它。
文件结构
大多数仓库只有一个上下文：
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
如果根目录存在 CONTEXT-MAP.md，说明仓库包含多个上下文。该文件应指向每个上下文的位置：
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← 系统级决策
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← 上下文级决策
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
按需创建文件：确认第一个术语时才创建 CONTEXT.md，需要记录第一条 ADR 时才创建 docs/adr/。
会话期间
对照词汇表检查
用户使用的术语与 CONTEXT.md 冲突时，立即指出。例如：“词汇表将‘取消’定义为 X，但你现在似乎是指 Y——以哪个为准？”
收紧模糊语言
用户使用含糊或含义过载的词时，提出精确的规范术语。例如：“这里的‘账号’是指 Customer 还是 User？它们是两个不同概念。”
讨论具体场景
讨论领域关系时，用具体场景进行压力测试。主动构造边界案例，迫使概念之间的边界变得精确。
与代码交叉验证
用户描述系统行为时，检查代码是否一致。发现矛盾便直接指出，例如：“代码会取消整个 Order，但你刚才说可以部分取消——以哪个为准？”
即时更新 CONTEXT.md
术语一旦确认，立即更新 CONTEXT.md，不要集中到最后处理。格式遵循 CONTEXT-FORMAT.md。
CONTEXT.md 只能包含词汇定义，不能包含实现细节；不要把它当作规格、草稿或实现决策仓库。
谨慎提出 ADR
只有同时满足以下三个条件时，才建议创建 ADR：
- 难以逆转：日后改变决定的成本显著。
- 缺少背景便难以理解：未来读者会疑惑为什么这样设计。
- 源于真实取舍：确实比较过替代方案，并基于明确理由做出选择。
缺少任一条件就跳过 ADR。格式遵循 ADR-FORMAT.md。