mcpField
D
domain-modeling

domain-modeling

github.com/carlitose開発049 回インストール2 週間前に更新
リポジトリ

domain-modeling について

Domain Modelingは、プロジェクトのドメイン用語とモデルを整備・維持するエージェントスキルです。具体的なシナリオやコードを参照して用語を明確にし、合意済みの語を用語集に記録します。取り消しにくい決定については、必要に応じてADRを提案します。

主な機能

  1. 01曖昧または競合する用語の特定
  2. 02シナリオとコードを用いた検討
  3. 03簡潔なドメイン用語集の管理
  4. 04必要に応じたADRの作成

活用シーン

  1. 01コードとドキュメントの用語の明確化
  2. 02意味が重なるドメイン概念の整理
  3. 03合意済み用語の今後の作業への継承
  4. 04重要なアーキテクチャ決定の記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/carlitose/agent-skills --skill domain-modeling

インストール後、Claude Code で/domain-modelingを入力して読み込まれたか確認します。

詳細

ドメインモデリング

プロジェクトのドメインモデルを、継続的な取り組みとして構築し、問い直し、維持します。CONTEXT.md を読むだけにとどめず、意思決定を進める際に用語を明確にするために活用します。

ファイル

  • CONTEXT.md：確定したドメイン用語のみを記載する、ルートの用語集です。
  • CONTEXT-MAP.md：境界づけられたコンテキストの任意のマップです。存在する場合は、該当するコンテキストの用語集や用語を選ぶ際に使用します。
  • docs/adr/：長期的に記録するアーキテクチャ決定記録です。

ファイルは必要になったときだけ作成します。このスキルが有効だからといって、CONTEXT.md、CONTEXT-MAP.md、docs/adr/ を作成しないでください。保存する価値のある内容が確定した場合にのみ、作成または更新します。

基本ルール

  • 言葉も設計の一部として扱います。曖昧な言葉、複数の意味を持つ用語、既存の用法と矛盾する用語に疑問を呈します。
  • 抽象的な名前を付ける前に、具体的なシナリオについて話し合います。実際のワークフロー、ユーザー、データ、コードパスの例を優先します。
  • 可能であればコードベースを参照します。用語がすでにコードに登場している場合は、ユーザーに定義を求める前に関連ファイルを確認します。
  • CONTEXT.md は用語集としてのみ使用します。実装仕様、作業メモ、バックログ、決定記録、議事録として使用しないでください。
  • 用語が確定したら、CONTEXT.md をその場で更新します。エントリーは簡潔で安定した、将来のエージェントに役立つ内容にします。
  • プロダクトの意味を決めるのはユーザーです。より明確な表現を提案しますが、意見が分かれている用語を置き換える前に確認します。

モデリングの進め方

  1. 現在のコンテキストを特定します。CONTEXT-MAP.md が存在する場合は、該当する境界づけられたコンテキストを探すために使用します。存在しない場合は、ルートの CONTEXT.md とコードベースを基に進めます。
  2. 会話、ドキュメント、チケット、UI、API、スキーマ、コードで現在使われている用語を抽出します。
  3. 曖昧さ、類義語、矛盾、コンテキストによって意味が変わる用語を指摘します。
  4. 最も重要な曖昧さを解消する、焦点を絞った質問を1つします。
  5. 推奨する用語または定義と、それを裏付けるシナリオを提示します。
  6. ユーザーが用語を受け入れるか明確化したら、内容が長期的に有用な場合は用語集のエントリーを更新します。
  7. 現在の計画や実装の判断に十分なほどモデルが明確になるまで繰り返します。

用語集の形式

簡潔な Markdown エントリーを使用します。

# Context

## Glossary

### <Term>

Definition: <one or two sentences>

Use when: <short concrete usage rule>

Do not use for: <nearby concept or common confusion, if useful>

複数の境界づけられたコンテキストがある場合、見出しやコンテキスト別ファイルを使うのは、既存のプロジェクトですでにそのパターンが採用されている場合に限ります。それ以外の場合はルートの用語集をシンプルに保ち、複数のコンテキストが実際に存在し、役立つ場合にのみ CONTEXT-MAP.md を使用します。

ADR の運用

ADR の作成は控えめに提案します。次の3つすべてに該当する場合にのみ作成します。

  • 決定を覆すのが難しい。
  • 背景を知らなければ、その決定は意外に思われる。
  • 妥当な選択肢の間に、実質的なトレードオフがある。

通常の実装の詳細、一時的な計画、明白な局所的判断について ADR を作成しないでください。ADR が妥当な場合は、次の形式を使用して docs/adr/<yyyy-mm-dd>-<slug>.md に保存します。

# <Decision>

## Status

Proposed | Accepted | Superseded

## Context

What forced this decision, including relevant domain language.

## Decision

The chosen option.

## Consequences

What this enables, constrains, or makes harder.

## Options Considered

- <Option>: benefit and drawback.

ワークフローの一環としてドキュメント作成が明示的に依頼されている場合を除き、ADR を書く前に確認してください。

コメント

Markdown 対応