ubiquitous-language

Name: ubiquitous-language
Author: stevesolun

560stars68forks

How to install ubiquitous-language?

stevesolun/ctx/ubiquitous-language

$npx -y skills add stevesolun/ctx --skill ubiquitous-language

Installs into the current project.

Summary

Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or

Files · 1

View on GitHub

SKILL.md

1	# Ubiquitous Language
2
3	Extract and formalize domain terminology from the current conversation into a consistent glossary, saved to a local file.
4
5	## Process
6
7	1. Scan the conversation for domain-relevant nouns, verbs, and concepts
8	2. Identify problems:
9	- Same word used for different concepts (ambiguity)
10	- Different words used for the same concept (synonyms)
11	- Vague or overloaded terms
12	3. Propose a canonical glossary with opinionated term choices
13	4. Write to `UBIQUITOUS_LANGUAGE.md` in the working directory using the format below
14	5. Output a summary inline in the conversation
15
16	## Output Format
17
18	Write a `UBIQUITOUS_LANGUAGE.md` file with this structure:
19
20	```md
21	# Ubiquitous Language
22
23	## Order lifecycle
24
25	\| Term \| Definition \| Aliases to avoid \|
26	\| ----------- \| ------------------------------------------------------- \| --------------------- \|
27	\| Order \| A customer's request to purchase one or more items \| Purchase, transaction \|
28	\| Invoice \| A request for payment sent to a customer after delivery \| Bill, payment request \|
29
30	## People
31
32	\| Term \| Definition \| Aliases to avoid \|
33	\| ------------ \| ------------------------------------------- \| ---------------------- \|
34	\| Customer \| A person or organization that places orders \| Client, buyer, account \|
35	\| User \| An authentication identity in the system \| Login, account \|
36
37	## Relationships
38
39	- An Invoice belongs to exactly one Customer
40	- An Order produces one or more Invoices
41
42	## Example dialogue
43
44	> Dev: "When a Customer places an Order, do we create the Invoice immediately?"
45	> 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."
46	> Dev: "So if a Shipment is cancelled before dispatch, no Invoice exists for it?"
47	> Domain expert: "Exactly. The Invoice lifecycle is tied to the Fulfillment, not the Order."
48
49	## Flagged ambiguities
50
51	- "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.
52	```
53
54	## Rules
55
56	- Be opinionated. When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
57	- Flag conflicts explicitly. If a term is used ambiguously in the conversation, call it out in the "Flagged ambiguities" section with a clear recommendation.
58	- Only include terms relevant for domain experts. Skip the names of modules or classes unless they have meaning in the domain language.
59	- Keep definitions tight. One sentence max. Define what it IS, not what it does.
60	- Show relationships. Use bold term names and express cardinality where obvious.
61	- Only include domain terms. Skip generic programming concepts (array, function, endpoint) unless they have domain-specific meaning.
62	- 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.
63	- 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.
64
65	<example>
66
67	## Example dialogue
68
69	> Dev: "How do I test the sync service without Docker?"
70
71	> 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."
72
73	> Dev: "So sync-in still creates a bundle and unpacks it?"
74
75	> Domain expert: "Exactly. The sync service doesn't know which layer it's talking to. It calls `exec` and `copyIn` — the filesystem layer just runs those as local shell commands."
76
77	</example>
78
79	## Re-running
80
81	When invoked again in the same conversation:
82
83	1. Read the existing `UBIQUITOUS_LANGUAGE.md`
84	2. Incorporate any new terms from subsequent discussion
85	3. Update definitions if understanding has evolved
86	4. Re-flag any new ambiguities
87	5. Rewrite the example dialogue to incorporate new terms

People who liked this also viewed

6 picks

Type

ubiquitous-language

560stars68forks

View on GitHub

How to install ubiquitous-language?

stevesolun/ctx/ubiquitous-language

$npx -y skills add stevesolun/ctx --skill ubiquitous-language

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Ubiquitous Language
2
3	Extract and formalize domain terminology from the current conversation into a consistent glossary, saved to a local file.
4
5	## Process
6
7	1. Scan the conversation for domain-relevant nouns, verbs, and concepts
8	2. Identify problems:
9	- Same word used for different concepts (ambiguity)
10	- Different words used for the same concept (synonyms)
11	- Vague or overloaded terms
12	3. Propose a canonical glossary with opinionated term choices
13	4. Write to `UBIQUITOUS_LANGUAGE.md` in the working directory using the format below
14	5. Output a summary inline in the conversation
15
16	## Output Format
17
18	Write a `UBIQUITOUS_LANGUAGE.md` file with this structure:
19
20	```md
21	# Ubiquitous Language
22
23	## Order lifecycle
24
25	\| Term \| Definition \| Aliases to avoid \|
26	\| ----------- \| ------------------------------------------------------- \| --------------------- \|
27	\| Order \| A customer's request to purchase one or more items \| Purchase, transaction \|
28	\| Invoice \| A request for payment sent to a customer after delivery \| Bill, payment request \|
29
30	## People
31
32	\| Term \| Definition \| Aliases to avoid \|
33	\| ------------ \| ------------------------------------------- \| ---------------------- \|
34	\| Customer \| A person or organization that places orders \| Client, buyer, account \|
35	\| User \| An authentication identity in the system \| Login, account \|
36
37	## Relationships
38
39	- An Invoice belongs to exactly one Customer
40	- An Order produces one or more Invoices
41
42	## Example dialogue
43
44	> Dev: "When a Customer places an Order, do we create the Invoice immediately?"
45	> 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."
46	> Dev: "So if a Shipment is cancelled before dispatch, no Invoice exists for it?"
47	> Domain expert: "Exactly. The Invoice lifecycle is tied to the Fulfillment, not the Order."
48
49	## Flagged ambiguities
50
51	- "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.
52	```
53
54	## Rules
55
56	- Be opinionated. When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
57	- Flag conflicts explicitly. If a term is used ambiguously in the conversation, call it out in the "Flagged ambiguities" section with a clear recommendation.
58	- Only include terms relevant for domain experts. Skip the names of modules or classes unless they have meaning in the domain language.
59	- Keep definitions tight. One sentence max. Define what it IS, not what it does.
60	- Show relationships. Use bold term names and express cardinality where obvious.
61	- Only include domain terms. Skip generic programming concepts (array, function, endpoint) unless they have domain-specific meaning.
62	- 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.
63	- 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.
64
65	<example>
66
67	## Example dialogue
68
69	> Dev: "How do I test the sync service without Docker?"
70
71	> 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."
72
73	> Dev: "So sync-in still creates a bundle and unpacks it?"
74
75	> Domain expert: "Exactly. The sync service doesn't know which layer it's talking to. It calls `exec` and `copyIn` — the filesystem layer just runs those as local shell commands."
76
77	</example>
78
79	## Re-running
80
81	When invoked again in the same conversation:
82
83	1. Read the existing `UBIQUITOUS_LANGUAGE.md`
84	2. Incorporate any new terms from subsequent discussion
85	3. Update definitions if understanding has evolved
86	4. Re-flag any new ambiguities
87	5. Rewrite the example dialogue to incorporate new terms

People who liked this also viewed

6 picks

Type