Domain Modeling

Domain Modeling is an active discipline for building and sharpening a project's domain model as design conversations happen - challenging imprecise terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallize. It is explicitly distinct from merely reading CONTEXT.md for existing vocabulary (a passive habit any skill can do) - this skill is for when the domain model itself is being changed, not just consulted.

Use it when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to actively maintain the domain model. Within a session it does four things continuously: challenges term usage that conflicts with the existing CONTEXT.md glossary ("your glossary defines 'cancellation' as X, but you seem to mean Y"), proposes precise canonical terms for vague or overloaded language ("do you mean the Customer or the User?"), stress-tests domain relationships with invented edge-case scenarios, and cross-references stated behavior against the actual code to surface contradictions.

Single-context repos keep a CONTEXT.md glossary plus docs/adr/ architectural decision records at the root; multi-context repos instead have a root CONTEXT-MAP.md pointing to a CONTEXT.md and docs/adr/ per bounded context (e.g. src/ordering/, src/billing/), alongside system-wide decisions at the root. Files are created lazily - only when the first term or decision actually needs recording, not upfront. Resolved terms are written into CONTEXT.md immediately, never batched, following the format in CONTEXT-FORMAT.md; CONTEXT.md itself must stay a pure glossary, never a spec, scratchpad, or place for implementation decisions. New Architecture Decision Records are offered only when all three conditions hold: the decision is hard to reverse, it would be surprising without context to a future reader, and it resulted from a genuine trade-off between real alternatives - skipping the ADR if any one is missing, using the format in ADR-FORMAT.md.

/
├── CONTEXT-MAP.md
├── src/
│   ├── ordering/CONTEXT.md
│   └── billing/CONTEXT.md

Works directly against a repository's own CONTEXT.md/CONTEXT-MAP.md and docs/adr/ files rather than any external tool, and is designed so other skills can rely on it to keep the domain model current while they consume it.

Teams and engineers actively designing or refining a system's domain model - pinning down ubiquitous language, resolving ambiguous terminology, and deciding when a design choice is significant enough to warrant a recorded ADR - rather than teams that just need to read an existing glossary for reference.