agentleFS
Sign inStart free
DROOdotFOODROOdotFOO/agent-skills/skills/ubiquitous-language/SKILL.md

ubiquitous-language

Skill1 starsChanged 2 months agoMITView on GitHub

Extract and maintain a DDD ubiquitous language glossary from conversations. TRIGGER when: user asks to define domain terms, extract a glossary, build a ubiquitous language, or says "ubiquitous language". Also when domain ambiguity, synonym conflicts, or overloaded terms appear in conversation. DO NOT TRIGGER when: user wants code review, API docs, or module naming conventions (those are implementation, not domain).

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 60 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If two terms compete, choose the more precise one and list the loser as an alias to avoid

    line 28

“Common” is measured: kept by at least 6 in 10 of the 60 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

ubiquitous-language

Extract canonical domain terminology from conversations. Be opinionated. Flag ambiguity. Pick winners. Write UBIQUITOUS_LANGUAGE.md.

Process

  1. Scan -- Read the conversation (or codebase) for domain-specific terms
  2. Identify problems -- Flag: ambiguous terms, synonyms used interchangeably, overloaded terms (same word, different meanings in different contexts), terms with no clear definition
  3. Propose canonical glossary -- Pick one term per concept. Be opinionated. If two terms compete, choose the more precise one and list the loser as an alias to avoid
  4. Write file -- Output UBIQUITOUS_LANGUAGE.md in the project root
  5. Merge on re-run -- If the file exists, merge new terms into existing tables. Flag conflicts between old and new definitions

Output Format

Group terms into multiple tables by domain area (not one giant table).

## [Domain Area Name]

| Term   | Definition                                | Aliases to avoid      |
| ------ | ----------------------------------------- | --------------------- |
| Ledger | Append-only record of all balance changes | log, journal, history |

### Relationships

- A Ledger contains many Entries (1:N)
- Each Entry references exactly one Account (N:1)

### Example dialogue

> "When a user transfers funds, a new Entry is appended to the Ledger."
> NOT: "When a user moves money, a new log item is added to the history."

### Flagged ambiguities

- "Account" -- used to mean both user identity and financial account.
  DECISION: use "Account" for financial, "User" for identity.

What You Get

  • A UBIQUITOUS_LANGUAGE.md file in the project root with canonical terms grouped by domain area
  • Tables listing each term's definition, aliases to avoid, relationships with cardinality, and example dialogue
  • Flagged ambiguities where the same word means different things in different contexts, each with a documented decision

Rules

  1. Be opinionated -- Pick one canonical term per concept, always
  2. Flag conflicts -- If the conversation uses two terms for one concept, call it out explicitly and choose a winner
  3. Domain terms only -- Exclude module names, class names, function names, and implementation details. Capture the business/problem-space language
  4. Tight definitions -- One sentence max. If you need two, split the concept
  5. Show relationships -- Include cardinality (1:1, 1:N, N:N)
  6. Group into tables -- One table per domain area, not one flat list
  7. Include example dialogue -- Show how the term should be used in conversation
  8. Merge, don't replace -- Re-running adds new terms and flags conflicts with existing definitions

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free