dx-domain

The active glossary discipline: challenge a term, sharpen it, and write it to foundation/glossary.md the moment it resolves. Merely reading the glossary for naming is a one-line habit any skill does — this skill is for changing the model, not consuming it. It fires on three triggers during any work:

• Clash — a term contradicts an existing glossary definition. Call it out at once: "The glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
• Fuzzy — a vague or overloaded term is in play. Propose one precise canonical term: "You said 'account' — is that the Customer or the User? Those are different things."
• Resolved — a term gets nailed down during framing/design/implementation. Capture it immediately, before the moment passes.

Guard. Write only foundation/glossary.md. If context/foundation/ doesn't exist, the project isn't scaffolded — say so and suggest /dx-init. Create glossary.md lazily on the first resolved term.

Sharpen before you write (invoke dx-references with knowledge-layer)

Load knowledge-layer for the glossary entry shape and the standards/lessons/glossary distinctions. Then force precision:

• Invent a concrete edge-case scenario that probes the boundary between two concepts and makes the user commit. Vague terms survive in the abstract and break on specifics.
• Cross-check the code. If what the user says contradicts what the code does, surface it: "Your code cancels whole Orders, but you just said partial cancellation exists — which is right?"
• Be opinionated. When several words mean one thing, pick the best and list the rest under _Avoid_.

Write inline, glossary-only