ubiquitous-language
Extract canonical domain terminology from conversations. Be opinionated.
Flag ambiguity. Pick winners. Write UBIQUITOUS_LANGUAGE.md.
Process
- Scan -- Read the conversation (or codebase) for domain-specific terms
- Identify problems -- Flag: ambiguous terms, synonyms used interchangeably,
overloaded terms (same word, different meanings in different contexts),
terms with no clear definition
- Propose canonical glossary -- Pick one term per concept. Be opinionated.
If two terms compete, choose the more precise one and list the loser as
an alias to avoid
- Write file -- Output
UBIQUITOUS_LANGUAGE.md in the project root
- Merge on re-run -- If the file exists, merge new terms into existing
tables. Flag conflicts between old and new definitions
Output Format
Group terms into multiple tables by domain area (not one giant table).
## [Domain Area Name]
| Term | Definition | Aliases to avoid |
| ------ | ----------------------------------------- | --------------------- |
| Ledger | Append-only record of all balance changes | log, journal, history |
### Relationships
- A Ledger contains many Entries (1:N)
- Each Entry references exactly one Account (N:1)
### Example dialogue
> "When a user transfers funds, a new Entry is appended to the Ledger."
> NOT: "When a user moves money, a new log item is added to the history."
### Flagged ambiguities
- "Account" -- used to mean both user identity and financial account.
DECISION: use "Account" for financial, "User" for identity.
What You Get
- A
UBIQUITOUS_LANGUAGE.md file in the project root with canonical terms grouped by domain area
- Tables listing each term's definition, aliases to avoid, relationships with cardinality, and example dialogue
- Flagged ambiguities where the same word means different things in different contexts, each with a documented decision
Rules
- Be opinionated -- Pick one canonical term per concept, always
- Flag conflicts -- If the conversation uses two terms for one concept,
call it out explicitly and choose a winner
- Domain terms only -- Exclude module names, class names, function names,
and implementation details. Capture the business/problem-space language
- Tight definitions -- One sentence max. If you need two, split the concept
- Show relationships -- Include cardinality (1:1, 1:N, N:N)
- Group into tables -- One table per domain area, not one flat list
- Include example dialogue -- Show how the term should be used in conversation
- Merge, don't replace -- Re-running adds new terms and flags conflicts
with existing definitions
1---2name: ubiquitous-language3description: Extract and maintain a DDD ubiquitous language glossary from conversations. TRIGGER when: user asks to define domain terms, extract a glossary, build a ubiquitous language, or says "ubiquitous language". Also when domain ambiguity, synonym conflicts, or overloaded terms appear in conversation. DO NOT TRIGGER when: user wants code review, API docs, or module naming conventions (those are implementation, not domain).4---56# ubiquitous-language78Extract canonical domain terminology from conversations. Be opinionated.9Flag ambiguity. Pick winners. Write `UBIQUITOUS_LANGUAGE.md`.1011## Process12131. **Scan** -- Read the conversation (or codebase) for domain-specific terms142. **Identify problems** -- Flag: ambiguous terms, synonyms used interchangeably,15 overloaded terms (same word, different meanings in different contexts),16 terms with no clear definition173. **Propose canonical glossary** -- Pick one term per concept. Be opinionated.18 If two terms compete, choose the more precise one and list the loser as19 an alias to avoid204. **Write file** -- Output `UBIQUITOUS_LANGUAGE.md` in the project root215. **Merge on re-run** -- If the file exists, merge new terms into existing22 tables. Flag conflicts between old and new definitions2324## Output Format2526Group terms into multiple tables by domain area (not one giant table).2728```markdown29## [Domain Area Name]3031| Term | Definition | Aliases to avoid |32| ------ | ----------------------------------------- | --------------------- |33| Ledger | Append-only record of all balance changes | log, journal, history |3435### Relationships3637- A Ledger contains many Entries (1:N)38- Each Entry references exactly one Account (N:1)3940### Example dialogue4142> "When a user transfers funds, a new Entry is appended to the Ledger."43> NOT: "When a user moves money, a new log item is added to the history."4445### Flagged ambiguities4647- "Account" -- used to mean both user identity and financial account.48 DECISION: use "Account" for financial, "User" for identity.49```5051## What You Get5253- A `UBIQUITOUS_LANGUAGE.md` file in the project root with canonical terms grouped by domain area54- Tables listing each term's definition, aliases to avoid, relationships with cardinality, and example dialogue55- Flagged ambiguities where the same word means different things in different contexts, each with a documented decision5657## Rules58591. **Be opinionated** -- Pick one canonical term per concept, always602. **Flag conflicts** -- If the conversation uses two terms for one concept,61 call it out explicitly and choose a winner623. **Domain terms only** -- Exclude module names, class names, function names,63 and implementation details. Capture the business/problem-space language644. **Tight definitions** -- One sentence max. If you need two, split the concept655. **Show relationships** -- Include cardinality (1:1, 1:N, N:N)666. **Group into tables** -- One table per domain area, not one flat list677. **Include example dialogue** -- Show how the term should be used in conversation688. **Merge, don't replace** -- Re-running adds new terms and flags conflicts69 with existing definitions
DROOdotFOO