domain について
Domain は、用語やルールの境界を明確にする、または変更に関係する標準を調べるスキルです。既存のドメイン文書、コード、受け入れ例を基に定義を整理し、全体計画の役割は担いません。
主な機能
- 01境界づけられたコンテキストで用語を明確化
- 02コードと意図した意味の照合
- 03改名に伴う互換性コストの特定
- 04関連する技術標準の調査
活用シーン
- 01受け入れ例に使うドメイン用語の定義
- 02コンテキスト間で異なる意味の整理
- 03言語やデータ形式の指針の調査
- 04改名による互換性への影響評価
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ boshu2/ agentops --skill domainインストール後、Claude Code で/domainを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/caller-vocabulary.mdreferences/standards/common-standards.mdgo.mdjavascript.mdjson.mdllm-trust-boundary-checklist.mdmarkdown.mdpython.mdrace-condition-checklist.mdrust.mdshell.mdskill-structure.mdsql-safety-checklist.mdtest-pyramid.mdtypescript.mdyaml.mdscripts/validate.shscripts/standards/validate.sh詳細
翻訳後に原文が更新されています。最新の内容は原文をご確認ください。
ドメイン
独立した用途が2つあります。用語作業では、受け入れ例、コード、会話で使う用語、名称、ルールの境界を明確にします。標準の参照では、変更に必要な言語、データ形式、リスク、テスト設計の標準を調べます。どちらも、もう一方を必要としません。Planが発見と再開を一元的に担い、Domainは必要な用語またはルールの境界だけを解決して、既存の意図に返します。
用語作業
- 既存の所有者を明記します。 呼び出し元の指示、ドメイン文書、契約から用語の所有者を見つけ、関連する用語だけを読みます。参照は読み取り専用です。所有者がいない場合は、各定義をコードで確認したもの、または提案として明示します。
- 境界づけられたコンテキストごとに意味を1つにします。 境界づけられたコンテキストとは、用語に合意済みの意味があり、そのルールの所有者がいる領域です。ある単語が複数のコンテキストにまたがる場合、全体に共通する定義を押し付けるのではなく、それぞれの意味と境界での翻訳を明示します。
- 意図と食い違うコードを報告します。 用語が示すアクター、状態、操作、観測可能な結果を特定し、意図された意味を呼び出し元、型、テストと照らし合わせます。不一致は解決すべき問題です。コードの名前を変えても不足している動作は追加されず、コードに合わせて用語を再定義すると欠陥が隠れます。
- 共有名の変更コストを見積もります。 エクスポートされた名前、シリアライズされたフィールド、保存値、API ペイロードの変更には、見た目だけの置き換えではなく、互換性対応(移行、バージョニング、クライアントの更新)が必要です。命名変更は承認された範囲内にとどめます。
- 例で意味を区別します。 具体的なケースで競合する意味を切り分けます。分岐する境界は Given/When/Then で表現し、実装と検証で再利用します。確定した用語をシナリオ名、操作、型、ドキュメントで使います。未解決の違いが動作や所有権を変える場合に限り、質問します。参照に聞き取りは必要ありません。
- 所有者を更新し、原則として用語集は追加しません。 詳細化が承認されている場合は、意味、コンテキスト、例を既存の所有者に反映し、有用な別名は明示的な翻訳として残します。所有者がいない場合は、新しい用語集ファイルを作成せず、呼び出し元の意図または会話に提案を返します。
用語作業の結果は次の形式で返し、次の変更に一貫した名前を付け、一貫して評価できる状態になった時点で終了します。
| 用語 | コンテキスト | 意味 | 出典 | 意味を区別する例 | 未解決の質問 |
|---|---|---|---|---|---|
| <path:line, observed in code, or proposed> | <Given/When/Then or concrete case> | <caller decision, or none> |
表の後に、コンテキスト間の翻訳、コードと意図の不一致が確認された各箇所、提案した名称変更に伴う互換性コスト、更新した所有者またはその所有者向けに提案した文章を列挙します。呼び出し元の用語例を参照してください。
同義語のすり替えとは、用語の権限を変える言葉に置き換えることです。判定をクローズと呼ぶと、トラッカーの状態遷移が暗黙のうちに判断へ割り当てられます。置き換えによって責任の所在が移る場合は、元の用語を維持します。
AgentOps の用語
AgentOps が主題の場合、その所有者は引き続きdocs/contracts/ubiquitous-language.mdであり、責任とポートについてはdocs/contracts/bounded-contexts.yamlです。正確な定義と出典パスを返します。AgentOps の用語を、無関係な呼び出し元のドメインに適用してはいけません。オペレーション層、フェデレーション統合グラフ、意味的な作業と証明のプロトコル、RPI のトラバーサルは、実際の契約においてそれぞれ異なる意味を保ちます。キュー、クレーム、リース、クローズ、ランド、リリース、デリバリーは、引き続き呼び出し元システムの責任です。用語の編集は、これらの状態遷移を許可するものではありません。
標準の参照
現在の変更に必要な言語またはリスクに関するガイダンスのみを、共通標準から参照してください。 リポジトリの契約と実際のツールチェーンが優先されます。これらのリファレンスによって、別の承認や検証のプロセスが新たに設けられることはありません。
- 言語:Go、Python、Rust、JavaScript、TypeScript、シェル。
- データと文章:JSON、YAML、Markdown。
- 関連するリスク:並行処理、SQL、LLM の信頼境界。
- テスト設計:テストピラミッド、パッケージ形式:スキルの構成。
アイデアの出典:Matt Pocock's engineering skills(ドメインモデリング)、AgentOps 向けに適応。