ubiquitous-language

Harvest domain terms from conversations into a project glossary with ambiguity resolution.

Updated Apr 6, 2026
One-click install
npx skills add https://github.com/toderian/project_template --skill ubiquitous-language-toderian
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ubiquitous-language
Source: https://github.com/toderian/project_template/tree/main/plugins/agents-tasks/skills/ubiquitous-language
Command: npx skills add https://github.com/toderian/project_template --skill ubiquitous-language-toderian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a long design discussion, domain terminology drifts: one word ends up meaning two things, or two words mean the same thing, and the project glossary falls behind. This Skill retrospectively scans the current conversation, detects ambiguities and synonyms, and consolidates canonical domain terms into the project's CONTEXT.md glossary. ## Core Features & Use Cases - Conversation Term Harvesting: Scans the current conversation for domain-relevant nouns, verbs, and concepts, skipping generic programming terms. - Ambiguity Detection: Flags cases where one word covers multiple concepts or multiple words cover one concept, and proposes an opinionated canonical term with aliases to avoid. - Glossary Consolidation: Writes agreed terms into docs/resources/CONTEXT.md following the domain-modeling format, extending existing definitions rather than duplicating them. - Use Case: After a two-hour design session about billing, run this Skill to catch that "account" and "customer" were used interchangeably, propose "customer" as canonical, and update the glossary's Relationships and Flagged ambiguities sections. ## Quick Start Review this conversation and update the project glossary in docs/resources/CONTEXT.md with the domain terms we used, flagging any ambiguities.

Frequently Asked Questions about ubiquitous-language

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I build a domain glossary from a design discussion?

Run this Skill after the discussion: it scans the conversation for domain-relevant terms, detects ambiguities and synonyms, proposes canonical definitions for your approval, and writes the agreed terms into docs/resources/CONTEXT.md.

What is the difference between ubiquitous-language and domain-modeling skills?

Ubiquitous-language is the batch move: it harvests terms retrospectively after a conversation has happened. The domain-modeling skill is the inline one, sharpening and recording each term as a design session crystallizes it.

Where does the glossary get written?

Terms are written to docs/resources/CONTEXT.md, following CONTEXT-MAP.md to the right context in multi-context repos. If CONTEXT_DOCS_DIR is set in project.env, that location is used instead, and the glossary is created lazily on the first resolved term.

Does it overwrite existing glossary definitions?

No. Existing glossary terms are treated as canon: the Skill extends or sharpens them rather than proposing rival definitions, and it explicitly reports when the conversation contradicts what the glossary already says.

When should a decision go in an ADR instead of the glossary?

A decision that is hard to reverse, surprising without context, and the result of a real trade-off belongs in an Architecture Decision Record, not the glossary. The Skill defers those cases to the knowledge-base skill's ADR convention.