domain-modelinglisted

# Domain Modeling Build and sharpen the project's domain model as you design: challenge terms against the glossary, pick canonical names, and write glossary entries and decisions down the moment they crystallise. Merely *reading* `CONTEXT.md` for vocabulary is a one-line habit any skill has; this skill is for changing the model. ## File structure Most repos have a single context: `CONTEXT.md` at the root and `docs/adr/NNNN-slug.md`. A `CONTEXT-MAP.md` at the root means several contexts, each with its own `CONTEXT.md` and `docs/adr/`; infer the context from the code you are touching. Formats: [CONTEXT-FORMAT.md](CONTEXT-FORMAT.md), [ADR-FORMAT.md](ADR-FORMAT.md). Create files lazily — only when you have something to write. A repo without `CONTEXT.md` gets one when the first term is resolved; `docs/adr/` when the first ADR is needed. ## Terms - **Challenge against the glossary.** A term in the ticket, spec, or code that conflicts with `CONTEXT.md` is resolved in the glossary's favour; where the glossary is the one that is wrong (the code and the ticket agree against it), sharpen the entry and record why under Assumptions or Decisions. - **Sharpen fuzzy language.** A vague or overloaded term ("account", "item", "session") gets one canonical name, chosen to match what the code already calls it most; the others go under `_Avoid_`. - **Cross-reference with code.** Before defining a term, check what the code does with it. A definition that the code contradicts is not written;