skills.rest
riethmayer
riethmayerCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

ubiquitous-language

Extract domain terminology into per-context UBIQUITOUS_LANGUAGE.md glossary files.

2|1|Updated Oct 8, 2009
Search Tags:#architecture#glossary#domain-driven-design#bounded-context#ubiquitous-language#domain-terminology
One-click install
npx skills add https://github.com/riethmayer/dotfiles --skill ubiquitous-language-riethmayer
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ubiquitous-language
Source: https://github.com/riethmayer/dotfiles/tree/main/stow/agents/.agents/skills/ubiquitous-language
Command: npx skills add https://github.com/riethmayer/dotfiles --skill ubiquitous-language-riethmayer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Extract and formalize domain terminology from the current conversation, scoped to bounded contexts.

Core Features & Use Cases

  • Create a per-context glossary file named UBIQUITOUS_LANGUAGE.md in the root of each bounded context.
  • Identify bounded contexts from directory structure and conversations to produce consistent terminology.
  • Provide a canonical glossary with terms, definitions, aliases, and cross-context mappings to reduce ambiguity.

Quick Start

Identify the bounded context in your project and generate its UBIQUITOUS_LANGUAGE.md.

Frequently Asked Questions about ubiquitous-language

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a domain-driven design glossary for my project?▼

A domain glossary is created by extracting domain terminology from your conversation and scoping it to bounded contexts. Each context gets a UBIQUITOUS_LANGUAGE.md file containing terms, definitions, aliases, and cross-context mappings.

What is a bounded context glossary and when do I need one?▼

A bounded context glossary formalizes domain terminology within a specific architectural boundary like a package, service, or module. You need one to reduce ambiguity and ensure consistent terminology across different domain boundaries.

How do I extract domain terminology from a conversation and map it to packages?▼

Domain terminology is extracted from the current conversation and mapped by identifying bounded contexts from your directory structure. Each context root receives a UBIQUITOUS_LANGUAGE.md file with canonical terms, definitions, and aliases.

Can I generate a ubiquitous language file for each service or module?▼

Yes, you can generate a ubiquitous language file for each service or module. Each bounded context boundary, such as a packages subdirectory or service, gets its own UBIQUITOUS_LANGUAGE.md placed in the context root directory.

What's the best way to manage cross-context term mappings in domain-driven design?▼

Cross-context term mappings are managed within each bounded context's UBIQUITOUS_LANGUAGE.md file. The glossary provides canonical definitions and aliases to reduce ambiguity across different architectural boundaries.

Why does my project need separate ubiquitous language files per bounded context?▼

Separate ubiquitous language files are needed because each bounded context has distinct domain terminology. Scoping glossaries per context boundary prevents semantic conflicts and maintains consistent terminology within each package or service.

Related Skills

Explore More Software Engineering Skills→
scott-rcscott-rc

ubiquitous-language

Extract domain terminology from conversations into a structured glossary file.

Community
Intermediate
Varadraj13Varadraj13

ubiquitous-language

Extract and formalize domain terminology from conversations into a glossary file.

Community
Intermediate
lugassawanlugassawan
2

principle-ddd

Design domain models with bounded contexts and ubiquitous language.

Community
Advanced
ForgePlanForgePlan
3

ubiquitous-language

Extract business terminology from codebases into a domain glossary.

Official
Intermediate