Use in projects that keep domain vocabulary in `DOMAIN.md` to apply the approved ubiquitous language during naming, refactoring, review, documentation, API or schema design, and terminology audits. Trigger when work introduces or changes domain terms, when active code or docs may drift from `DOMAIN.md`, or when the user wants to review, update, normalize, or bootstrap the glossary.
Keep project language aligned with DOMAIN.md. Stay quiet during ordinary work, then switch into an explicit audit only when drift, gaps, or a direct terminology request make the language decision important.
DOMAIN.md from the current workdir.DOMAIN.md.DOMAIN.md exists anywhere, do nothing unless the user explicitly asks to bootstrap or document the ubiquitous language. For bootstrap work, read references/domain-template.md.DOMAIN.mdDOMAIN.md as canonical.references/domain-template.md instead of inventing policy.DOMAIN.md, avoid presenting a guessed term as settled. Surface the ambiguity and propose a pending entry.drift, gap, or exception.drift: a non-canonical or discouraged term conflicts with an approved term in DOMAIN.md.gap: a real concept is missing from DOMAIN.md.exception: local usage is acceptable because it falls into an allowed exception bucket; mention it only when the distinction matters.DOMAIN.md is absent, stay silent unless the user explicitly asks to create or maintain it.DOMAIN.md before endorsing it.type: drift | gap | exceptioncanonical: approved term, if one existsobserved: conflicting or new termwhy: one short rationale tied to DOMAIN.mdaction: exact replacement or DOMAIN.md update to makegap, include a pending glossary entry with canonical term, definition, aliases, discouraged terms, and open questions.references/domain-template.md when bootstrapping a missing DOMAIN.md, normalizing an existing one, or drafting a pending glossary entry.references/findings.md when you need concrete examples of drift, gap, or exception outputs.