domain-modellisted

# 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 crystallize. (Merely *reading* `CONTEXT.md` for vocabulary is a one-line habit any skill does — that is not this skill. This skill is for when you are *changing* the model.) Why it matters: at the start of a project the developer and the domain experts speak different languages, and the agent is dropped in to guess the jargon — so it uses 20 words where 1 would do. A shared language fixes that. The same precise term flows into conversation, variable names, file names, and tests; the codebase gets easier to navigate; the agent spends fewer tokens thinking. --- ## Phase 0 — Load profile & locate the model 1. Read `.claude/PROJECT.md` → **Domain** (the seed vocabulary and roles) and **Architecture** (so terms map to real modules). If `PROJECT.md` is missing or still `TEMPLATE`, you can still run (lean on the root `CLAUDE.md` if it carries the facts) — but tell the user `/bootstrap` will wire the glossary location into the profile. 2. Locate the model files (lazily created — see below): - **`CONTEXT.md`** — the glossary, at the repo root (or the path named in `PROJECT.md` → Domain). If a **`CONTEXT-MAP.md`** exists at the root, the repo has multiple bounded contexts; the map points to where each `CONTEXT.md` lives. - **