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. (Merely *reading* the glossary 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.) ## Where the domain model lives The project map in `AGENTS.md` says where each of these lives. Most repos keep some subset: | Source | What it covers | | :-- | :-- | | A glossary | The domain language: one canonical name per concept, in one table | | Naming or code conventions | Role taxonomy, naming stems, module/class suffixes | | An architecture reference | System shape: components, flows, layout | | Narrative docs per subsystem | The rationale behind how one area works | | An ADR log | Dated record of why a hard-to-reverse choice was made | If the project keeps none of these, that is itself the first finding: propose the smallest one that would have prevented the ambiguity you just hit (usually a glossary at `docs/glossary.md`), record its location in the project map, and never create a parallel `CONTEXT.md` beside docs that already exist. Before a session, skim the glossary and any ADRs already filed for the area. ## During the session ### Challenge against the glossary When the user uses a term that conflicts with the existing language in the gl