mcpField
U
ubiquitous-language

ubiquitous-language

github.com/niekcandaele开发648 次安装5 天前更新
代码仓库

关于 ubiquitous-language

ubiquitous-language 是一项从当前对话中提取领域术语并整理成词汇表的技能,适合需要统一业务表达的开发团队。它将术语、别名和歧义写入 CONTEXT.md,并通过示例对话展示术语之间的界限。

主要功能

  1. 01提取领域相关术语
  2. 02识别歧义、同义词和模糊表达
  3. 03提出规范术语及别名
  4. 04将词汇表写入 CONTEXT.md
  5. 05补充术语示例对话并可扩展已有内容

适用场景

  1. 01为领域讨论建立统一词汇表
  2. 02澄清团队对同一概念的不同称呼
  3. 03扩展已有 CONTEXT.md 中的术语

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/niekcandaele/skills --skill ubiquitous-language

安装后在 Claude Code 中输入/ubiquitous-language确认已加载。

详细介绍

通用语言

从当前对话中提取并规范化领域术语,整理成一致的词汇表并保存到本地文件。

流程

  1. 扫描对话,找出与领域相关的名词、动词和概念
  2. 识别问题:
    • 同一个词用于表示不同概念(歧义)
    • 不同的词用于表示同一概念(同义词)
    • 含义模糊或被过度使用的术语
  3. 提出规范词汇表,明确选择术语
  4. 按照下方格式将内容写入工作目录中的 CONTEXT.md
  5. 在对话中输出摘要

输出格式

CONTEXT.md 与 grill-me 技能共用,因此采用该技能的结构。请按以下格式编写:

# {Context Name}

{One or two sentence description of what this context is and why it exists.}

## Language

**Order**:
A customer's request to purchase one or more items.
_Avoid_: Purchase, transaction

**Invoice**:
A request for payment sent to a customer after delivery.
_Avoid_: Bill, payment request

**Customer**:
A person or organization that places orders.
_Avoid_: Client, buyer, account

**User**:
An authentication identity in the system.
_Avoid_: Login, account

## Relationships

- An **Invoice** belongs to exactly one **Customer**
- An **Order** produces one or more **Invoices**

## Example dialogue

> **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**."

## Flagged ambiguities

- "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**.

规则

  • 明确选择。 多个词表示同一概念时,选出最佳用词,并将其他词列为应避免的别名。
  • 明确标出冲突。 如果对话中的某个术语存在歧义,请在“已标记的歧义”部分指出,并给出明确建议。
  • 仅纳入领域专家相关的术语。 除非模块或类的名称具有领域含义,否则请跳过。
  • 定义简洁。 每条定义最多一句话。定义它是什么,而不是它做什么。
  • 展示关系。 使用粗体标注术语名称,并在明显时注明基数。
  • 仅纳入领域术语。 跳过通用编程概念(数组、函数、端点),除非它们具有特定领域含义。
  • 在自然形成的子标题下对术语分组(例如按子领域、生命周期或参与者分组)。如果所有术语都属于同一个连贯领域,可以在 ## Language 下平铺列出,无需强行分组。
  • 让 CONTEXT.md 只包含词汇表。 不要包含实现细节、规范或草稿笔记。
  • 编写示例对话。 由开发者和领域专家进行简短对话(3-5 轮),展示术语如何自然地相互关联。对话应厘清相关术语之间的边界,并准确展示术语的用法。

示例对话

开发者:“不使用 Docker,如何测试 sync service?”

领域专家:“提供 filesystem layer,而不是 Docker layer。它实现了相同的 Sandbox service 接口,但使用本地目录作为 sandbox。”

开发者:“所以 sync-in 仍会创建一个 bundle 并将其解包?”

领域专家:“没错。sync service 不知道自己正在与哪种层交互。它会调用 exec 和 copyIn,而 filesystem layer 只需将这些操作作为本地 shell 命令运行。”

再次运行

CONTEXT.md 可能已经存在——可能由之前的运行创建,也可能由 grill-me 在提问会话中创建。请在现有文件基础上扩展,绝不要覆盖已有内容。

在同一对话中再次调用时:

  1. 读取现有的 CONTEXT.md
  2. 纳入后续讨论中的新术语
  3. 根据理解的变化更新定义
  4. 重新标记新发现的歧义
  5. 重写示例对话,将新术语纳入其中

评论

支持 Markdown