Maintain a project thesaurus (domain glossary) following DDD ubiquitous language principles. Use PROACTIVELY when naming anything: variables, functions, classes, modules, database fields, API endpoints, events, files, or directories. Also use when the user asks to "create thesaurus", "update glossary", "add term", "rename to match domain", "check naming consistency", "what should I call this", "domain language", "ubiquitous language", or "naming conventions". Ensures all names in the codebase are consistent, descriptive, and aligned with the shared domain vocabulary. Not for general code style or linting — only for domain term consistency.
You enforce naming consistency across the codebase by maintaining a living thesaurus of domain terms and consulting it every time something needs a name.
Three modes:
This skill combines two bodies of knowledge:
"A project should use a single, shared vocabulary. Every name in code, docs, APIs, and conversations must map to a term in the thesaurus. If a concept isn't in the thesaurus — add it before naming anything."
— Domain-Driven Design, Eric Evans
The codebase is primary evidence, not automatic authority. Use code to discover which terms are currently in circulation. Use the thesaurus and user input to decide which terms SHOULD be canonical.
## Legacy Terms and use the user's terms as canonicalTacit knowledge: For areas not yet implemented, the most important domain knowledge exists only in experts' heads, not in any artifact.
Locating the thesaurus:
THESAURUS.md already exists somewhere in the repo — use that locationdocs/THESAURUS.mdSingle source of truth for domain vocabulary.
### [Term]
- **Definition**: What this concept means in the business domain
- **NOT**: What this term does NOT mean (prevents confusion with similar concepts)
- **Synonyms to AVOID**: Terms that mean the same thing but must NOT be used
- **Related terms**: Other thesaurus terms this concept connects to
### [Term]
- **Definition**: [one sentence]
- **Synonyms to AVOID**: [list]
Why no "Use in code" field: The thesaurus defines concepts and canonical names, not how they appear in code. Code casing follows project conventions automatically.
The thesaurus captures concepts, not behavior. It's strong at nouns (entity names, roles, process names) but won't replace behavioral specs for business rules. Don't try to turn the thesaurus into a specification — keep entries short. If a concept has a critical invariant, note it briefly in the definition, not as a separate section.
Non-English domains: If the business domain operates in a non-English language, use the original language for the canonical term. The thesaurus should reflect how domain experts actually speak. Add an English translation only if the codebase uses English