domain-modelinglisted

# Domain Modeling 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. This skill is for when you're **changing** the model. ## When to use - Pinning down domain terminology or establishing a ubiquitous language - A term the user uses conflicts with the existing `CONTEXT.md` glossary - Stress-testing domain relationships against concrete edge-case scenarios - Recording an architectural decision that is hard to reverse, surprising, or a real trade-off - Another skill needs to maintain or update the domain model - Triggers on "domain model", "ubiquitous language", "CONTEXT.md", "ADR", "领域模型", "统一语言", "领域建模" **Not for:** merely *reading* `CONTEXT.md` for vocabulary — that's a habit any skill can do; this skill is for when you're **changing** the model. NOT for greenfield system architecture (use `architecture`). ## Steps ### 1. Locate the context Most repos have a single `CONTEXT.md` at the root. If a `CONTEXT-MAP.md` exists, the repo has multiple contexts — read it to find which context the current topic relates to. If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved. Create `docs/design/adr/` lazily when the first ADR is needed. ### 2. Challenge terms against the glossary When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it ou