ubiquitous-language
Ubiquitous Language
Extract and formalize domain terminology from the current conversation into a consistent glossary, saved to a local file.
Healthcare domain awareness
This skill is particularly valuable in healthcare contexts where precise domain language prevents costly misunderstandings. Healthcare systems deal with overlapping standards (HL7v2, FHIR, HPK, IHE profiles) that each introduce their own terminology for similar concepts — a "patient encounter" in FHIR, an "ADT event" in HL7v2, a "venue" in HPK can all refer to overlapping but distinct ideas. Formalizing a ubiquitous language early avoids bugs, specification drift, and integration errors that are expensive and dangerous in clinical environments.
Bilingual support (French / English)
Our teams work primarily in French, but healthcare domain standards (HL7, FHIR, IHE) and DDD literature use English terminology. The glossary should capture both:
- The canonical term is chosen based on whichever language the team uses most naturally for that concept
- A French term column is included alongside each definition so that team members can map between languages
- When a standard imposes an English term (e.g. "Encounter", "Observation", "MessageHeader"), prefer the standard's English term as canonical and provide the French equivalent
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
- Terms that conflict with established healthcare standards
- Propose a canonical glossary with opinionated term choices
- Write to
UBIQUITOUS_LANGUAGE.mdin the working directory using the format below - Output a summary inline in the conversation
Output Format
Write a UBIQUITOUS_LANGUAGE.md file with this structure:
# Ubiquitous Language
## Patient lifecycle
| Term | Terme français | Definition | Aliases to avoid |
|------|---------------|-----------|-----------------|
| **Encounter** | Rencontre / Venue | A single interaction between a patient and a healthcare provider, bounded by admission and discharge | Visit, stay, séjour, passage |
| **Admission** | Admission | The act of formally registering a patient for an encounter | Check-in, entrée |
## Clinical concepts
| Term | Terme français | Definition | Aliases to avoid |
|------|---------------|-----------|-----------------|
| **Observation** | Observation | A single clinical measurement or finding recorded during an encounter | Result, measure, mesure, donnée |
| **Prescription** | Prescription | A clinician's order for medication, treatment, or diagnostic test | Order, ordonnance (when referring to the act, not the document) |
## Relationships
- An **Encounter** belongs to exactly one **Patient**
- A **Prescription** is issued during one **Encounter** but may be fulfilled across multiple **Encounters**
- An **Observation** is always recorded within one **Encounter**
## Example dialogue
> **Dev:** "When a **Patient** arrives, do we create an **Encounter** immediately?"
> **Domain expert:** "Yes — the **Admission** triggers the creation of an **Encounter**. But note that pre-admission paperwork does not constitute an **Encounter**; it is handled separately."
> **Dev:** "And if the **Patient** is transferred to another unit?"
> **Domain expert:** "That is still the same **Encounter**. A transfer changes the location, not the **Encounter** itself. A new **Encounter** only begins if the **Patient** is discharged and readmitted."
> **Dev:** "So the HL7 ADT^A02 transfer message updates the **Encounter**, it doesn't create a new one?"
> **Domain expert:** "Exactly."
## Flagged ambiguities
- "séjour" was used to mean both **Encounter** (a clinical interaction) and a hospital stay (a period of time) — prefer **Encounter** for the clinical concept and **Hospitalization** for the administrative period.
- "venue" in HPK context refers to the location-bound encounter, while "venue" in everyday French means something different entirely — always use **Encounter** in code and documentation.
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.
- 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.
- Include French terms. Every table row must have a "Terme français" column. When the canonical term is already French, the column may repeat it or note "identique".
- Respect healthcare standards. When a term is defined by HL7, FHIR, IHE, or HPK, prefer the standard's canonical spelling and casing. Note the source standard in the definition if helpful.
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
- Mark changed entries with "(updated)" and new entries with "(new)"
- Re-flag any new ambiguities
- Rewrite the example dialogue to incorporate new terms
Post-output instruction
After writing the file, state:
I've written/updated
UBIQUITOUS_LANGUAGE.md. From this point forward I will use these terms consistently. If I drift from this language or you notice a term that should be added, let me know.
More from dedalus-erp-pas/hexagone-foundation-skills
vue-best-practices
Guide des bonnes pratiques Vue.js 3 couvrant la Composition API, la conception de composants, les patrons de réactivité, le styling utility-first avec Tailwind CSS, l'intégration native de la bibliothèque de composants PrimeVue et l'organisation du code. À utiliser lors de l'écriture, la revue ou le refactoring de code Vue.js pour garantir des patrons idiomatiques et un code maintenable.
23grill-me
Interroge l'utilisateur sans relâche sur un plan ou un design jusqu'à atteindre une compréhension partagée, en résolvant chaque branche de l'arbre de décision. À utiliser quand l'utilisateur veut stress-tester un plan, se faire challenger sur son design, ou mentionne « grill me » / « interroge-moi » / « challenge-moi » / « questionne-moi ».
22meeting
Lance une réunion simulée avec plusieurs personas experts pour analyser un sujet sous des perspectives diverses, prendre une décision et proposer une solution avant implémentation. Peut optionnellement publier l'analyse de la réunion sur une issue GitLab ou GitHub liée.
22changelog-generator
Crée automatiquement des changelogs orientés utilisateur à partir des commits git en analysant l'historique, catégorisant les changements et transformant les commits techniques en notes de version claires et compréhensibles. Transforme des heures de rédaction manuelle en minutes de génération automatisée.
22github-issues
Crée, récupère, met à jour et gère les issues GitHub avec collecte complète du contexte. À utiliser quand l'utilisateur veut créer une nouvelle issue, voir les détails d'une issue, mettre à jour des issues existantes, lister les issues du projet, ajouter des commentaires ou gérer les workflows d'issues dans GitHub.
22hpk-parser
Parseur et explicateur complet du format HPK (format de message propriétaire santé). Supporte plus de 100 types de messages couvrant l'administration des patients (ID, MV, CV), la chaîne logistique (PR, FO, MA, CO, LI, RO, FA), les stocks (SO, IM), la structure organisationnelle (ST, UT) et les opérations financières (RD, DD). Utilise @erp-pas/hpk-dictionary comme source de vérité. Valide la structure, extrait les champs, explique le contexte métier, mappe vers HL7 v2.5/IHE PAM et aide au dépannage des problèmes d'intégration.
21