domain-modelinglisted

# Domain Modeling Actively build and sharpen the project's domain model while designing. Challenge terms, invent edge-case scenarios, and write the glossary and decisions down the moment they crystallise. Reading `CONTEXT.md` for vocabulary is not this skill — that is a one-line habit any skill can do. This skill is for changing the model, not just consuming it. ## Contract Inputs: - A term, relationship, or decision under discussion - Existing `CONTEXT.md` / `CONTEXT-MAP.md` and `docs/adr/` when present - `docs/agents/domain.md` when `setup-agent-routing` has already configured layout Outputs: - Updated glossary entries in `CONTEXT.md` - Optional ADR when the three-gate filter passes Creates/Modifies: - `CONTEXT.md` (or a per-context `CONTEXT.md` listed in `CONTEXT-MAP.md`) - `docs/adr/NNNN-slug.md` when an ADR is warranted - Directories created lazily — only when there is something to write External Side Effects: - Local file writes only. No tracker writes. Confirmation Required: - Before creating the first `CONTEXT.md` in a repo that had none - Before writing an ADR Delegates To: - None. `grilling` and `interview` invoke this skill when a term crystallises. ## File structure Most repos have a single context: ```text / ├── 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