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

ルール

• 明確な判断を下してください。 同じ概念に複数の用語がある場合は、最適な用語を選び、避けるべき別名を列挙してください。
• 競合を明示してください。 会話内で用語が曖昧に使われている場合は、「Flagged ambiguities」セクションで指摘し、明確な推奨案を示してください。
• ドメインの専門家に関係する用語だけを含めてください。 ドメイン言語として意味を持たない限り、モジュール名やクラス名は省いてください。
• 定義は簡潔にしてください。 1文以内にし、何であるかを定義してください。何をするかではありません。
• 関係性を示してください。 用語名は太字にし、明らかな場合は多重度を示してください。
• ドメイン用語だけを含めてください。 ドメイン固有の意味を持たない限り、一般的なプログラミング概念（配列、関数、エンドポイントなど）は省いてください。
• 自然なまとまりがあれば、サブ見出しの下に用語をグループ化してください（例：サブドメイン、ライフサイクル、アクター別）。すべての用語が単一のまとまったドメインに属する場合は、## Language の下にフラットなリストを作成してもかまいません。無理にグループ化しないでください。
• CONTEXT.md は用語集だけにしてください。 実装の詳細、仕様、メモは含めないでください。
• 対話例を記述してください。 開発者とドメイン専門家の短い会話（3～5往復）を作成し、用語が自然に使われる様子を示してください。関連する用語の境界を明確にし、用語が正確に使われるようにしてください。

対話例

開発者：「Docker を使わずに sync service をテストするにはどうすればよいですか？」

ドメイン専門家：「Docker layer の代わりに filesystem layer を指定してください。同じ Sandbox service インターフェースを実装していますが、ローカルディレクトリを sandbox として使用します。」

開発者：「つまり、sync-in は引き続き bundle を作成して展開するのですね？」

ドメイン専門家：「そのとおりです。sync service は、どの layer とやり取りしているかを認識しません。exec と copyIn を呼び出し、filesystem layer はそれらをローカルのシェルコマンドとして実行するだけです。」

再実行

CONTEXT.md は、以前の実行時や grill-me による質問セッション中にすでに作成されている可能性があります。既存の内容を上書きせず、そのまま拡張してください。

同じ会話で再度実行する場合：

1. 既存の CONTEXT.md を読みます
2. 以降の会話で出てきた新しい用語を取り込みます
3. 理解が深まっている場合は、定義を更新します
4. 新たな曖昧さがあれば、改めて指摘します
5. 新しい用語を取り込んだ対話例に書き換えます