Domain modeling

Name each concept once, the way the business names it, and keep that name identical in conversation, code, tests, and docs. The model is the shared language, not the database schema.

OpenSpec first

If the project already has an openspec/ directory, its specs/<capability>/spec.md (Requirement/Scenario blocks) and changes/<name>/design.md are the living-document mechanism this skill is after — check there before starting a separate glossary or ADR trail. Fold terms and boundary decisions into those files and keep them current; only reach for a standalone glossary/ADR when no openspec/ exists.

Ubiquitous language

• One term, one meaning. If the business says "booking", the domain type is Booking — not Reservation, Order, or Trip.
• If you keep a glossary — GLOSSARY.md, docs/domain/glossary.md, or an OpenSpec specs/*/spec.md — update it: term → definition, optionally an avoid list of near-synonyms that must not be used for this concept.
• When domain and code names diverge, fix the code name — the business vocabulary wins.
• A Leading Word is cheap leverage: reuse the exact domain term everywhere so one token carries the whole concept.

Bounded contexts