Ubiquitous language
Skill s-frantz/agent-memory-trellis/skills/ubiquitous-language
Builds a canonical domain glossary from the current conversation — resolving ambiguous terminology and pinning down shorthand for complex ideas. Flags conflicting or vague terms, proposes canonical ones, and saves to docs/UBIQUITOUS_LANGUAGE.md (repo root if no docs/ folder).From its SKILL.md
npx -y skills add s-frantz/agent-memory-trellis --skill ubiquitous-languageAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.9 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it
Ubiquitous Language
Extract and formalize domain terminology from the current conversation into a consistent glossary, saved to a local file.
Process
- Scan the conversation for domain-relevant nouns, verbs, and concepts
- Identify problems:
- Same word used for different concepts (ambiguity)
- Different words used for the same concept (synonyms)
- Vague or overloaded terms
- Propose a canonical glossary with opinionated term choices
- Write to
docs/UBIQUITOUS_LANGUAGE.mdif the repo keeps adocs/folder (the glossary is a library doc, not a root doc); fall back toUBIQUITOUS_LANGUAGE.mdat the working-directory root otherwise. If an INDEX of docs exists, add a line for it - Output a summary inline in the conversation
Output Format
Write a UBIQUITOUS_LANGUAGE.md file with this structure:
# Ubiquitous Language
## Order lifecycle
| Term | Definition | Aliases to avoid |
| ----------- | ------------------------------------------------------- | --------------------- |
| **Order** | A customer's request to purchase one or more items | Purchase, transaction |
| **Invoice** | A request for payment sent to a customer after delivery | Bill, payment request |
## People
| Term | Definition | Aliases to avoid |
| ------------ | ------------------------------------------- | ---------------------- |
| **Customer** | A person or organization that places orders | Client, buyer, account |
| **User** | An authentication identity in the system | Login, account |
## Relationships
- An **Invoice** belongs to exactly one **Customer**
- An **Order** produces one or more **Invoices**
## Example dialogue
> **Dev:** "When a **Customer** places an **Order**, do we create the **Invoice** immediately?"
> **Domain expert:** "No — an **Invoice** is only generated once a **Fulfillment** is confirmed. A single **Order** can produce multiple **Invoices** if items ship in separate **Shipments**."
> **Dev:** "So if a **Shipment** is cancelled before dispatch, no **Invoice** exists for it?"
> **Domain expert:** "Exactly. The **Invoice** lifecycle is tied to the **Fulfillment**, not the **Order**."
## Flagged ambiguities
- "account" was used to mean both **Customer** and **User** — these are distinct concepts: a **Customer** places orders, while a **User** is an authentication identity that may or may not represent a **Customer**.
Rules
- Be opinionated. When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
- Flag conflicts explicitly. If a term is used ambiguously in the conversation, call it out in the "Flagged ambiguities" section with a clear recommendation.
- Only include terms relevant for domain experts. Skip the names of modules or classes unless they have meaning in the domain language.
- Keep definitions tight. One sentence max. Define what it IS, not what it does.
- Show relationships. Use bold term names and express cardinality where obvious.
- Only include domain terms. Skip generic programming concepts (array, function, endpoint) unless they have domain-specific meaning.
- Group terms into multiple tables when natural clusters emerge (e.g. by subdomain, lifecycle, or actor). Each group gets its own heading and table. If all terms belong to a single cohesive domain, one table is fine — don't force groupings.
- Write an example dialogue. A short conversation (3-5 exchanges) between a dev and a domain expert that demonstrates how the terms interact naturally. The dialogue should clarify boundaries between related concepts and show terms being used precisely.
Example dialogue
Dev: "How do I test the sync service without Docker?"
Domain expert: "Provide the filesystem layer instead of the Docker layer. It implements the same Sandbox service interface but uses a local directory as the sandbox."
Dev: "So sync-in still creates a bundle and unpacks it?"
</example>Domain expert: "Exactly. The sync service doesn't know which layer it's talking to. It calls
execandcopyIn— the filesystem layer just runs those as local shell commands."
Re-running
When invoked again in the same conversation:
- Read the existing
UBIQUITOUS_LANGUAGE.md - Incorporate any new terms from subsequent discussion
- Update definitions if understanding has evolved
- Re-flag any new ambiguities
- Rewrite the example dialogue to incorporate new terms
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.