Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →mkurman/ubiquitous-language
Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md.
Passed 21 of 22 test cases with the skill, and 7 of 22 without it.
and 17 more in the full report
14 fixed7 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
Our engineering team and product owners are building a patient scheduling service, but everyone uses terms like 'appointment', 'visit', 'booking', and 'slot' interchangeably. Please build a ubiquitous language document in Markdown based on Domain-Driven Design practices. Organize the domain terms into logical category tables showing clear definitions alongside discouraged synonyms, map out entity relationships, highlight terminology conflicts we should resolve, and include a short mock transcript between a developer and domain expert.
| Checked | Without skill | With skill |
|---|---|---|
| Entity relationships are formatted as bullet points incorporating bold concept names and cardinality. | Missed | Passed |
| The dialogue transcript is formatted using blockquotes with bold speaker labels. | Missed | Passed |
| Table column headers include term name, definition, and aliases to avoid. | Passed | Passed |
The instructions your model reads when the skill loads.
----- | ------------------------------------------------------- | --------------------- | | 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 |
| 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 |
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."
## 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>
test cases passed, vs 7 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.