kenoxa/with-terminology

Enforce consistent domain language across code, documentation, and communication.

Glossary Binding

If a project glossary exists (e.g. UBIQUITOUS_LANGUAGE.md), read it before writing any code or documentation. Use canonical terms; avoid listed aliases or discouraged synonyms.

If no glossary exists, use the ubiquitous-language skill to create one.

When the glossary includes richer sections, apply them as follows.

Relationships — when present, consult when naming multi-entity flows.

Example dialogue — when present, use as a reference for domain phrasing.

Flagged ambiguities — when present, check before introducing any new domain noun or verb. DO NOT reintroduce a listed term. This is a hard blocklist: if the candidate term appears (or is a close variant), stop, pick an unambiguous alternative, and note the conflict in review.

Term Consistency

Derive identifiers (variables, functions, types, modules) from glossary terms. Use glossary terms in doc comments, READMEs, error messages, and UI labels — no ad-hoc synonyms for domain concepts.

Before introducing a domain noun or verb, check the glossary for overlaps or aliases. If genuinely new, note it for glossary addition.

Prefer glossary terms over weak sibling-file precedent, but do not do drive-by mass renames. Apply canonical terms to changed surfaces; call out mismatches separately.

Anti-Patterns

• Inventing domain synonyms when a glossary term covers the concept
• Forcing glossary terms onto purely technical helpers that are not domain concepts
• Renaming broad legacy surfaces to match the glossary without explicit scope approval