domain-modeling

ドメインモデリング

設計しながら、プロジェクトの用語集を積極的に作り、磨き上げます。語彙を知るために CONTEXT.md をただ 読む ことは、どのスキルでも行う習慣です。このスキルはモデルを 変更する ためのものです。用語に疑問を投げかけ、境界を探り、合意に至った時点ですぐに記録します。

会話中

別のスキルがヒアリングを担当している場合（たとえば brainstorm 内の grilling）、このスキルは2人目の聞き手にはならず、受動的に動作します。静かな作業は直接行います。合意した用語を CONTEXT.md に記録し、コードとの相互参照を行います。ただし、ユーザーへの確認が必要なこと（異議の提示、意味の明確化、境界ケースの確認）は、独自のターンを設けません。ヒアリングで使われている唯一の質問チャネルに引き継ぎ、依存関係の順に一度に1つずつ質問します。このスキルが単独で呼び出された場合に限り、自ら質問を進めます。

用語を用語集と照合して検証します。 ユーザーの用法が CONTEXT.md と食い違う場合、その場で指摘します。「用語集では 取消 は注文全体を無効にすることと定義されていますが、ここでは1つの商品項目を削除する意味のようです。どちらでしょうか？」

曖昧な表現を明確にします。 用語が曖昧だったり、複数の意味に使われたりしている場合は、正確で標準となる用語を提案します。「何度も アカウント とおっしゃっていますが、Customer と User のどちらでしょうか？ここでは異なるものです。」

境界ケースのシナリオで負荷をかけます。 概念同士の関係が話題になったら、境界を試す具体的なシナリオを考えます。「請求期間の途中で、未払いの Invoice がある Member が退会したら、その Workspace はどうなりますか？」境界を暗黙のままにせず、明示させます。

コードとの相互参照を行います。 ユーザーが何かの動作を説明したら、コードと一致しているか確認します。矛盾があれば明確に示します。「用語集でもあなたも部分返金があるとしていますが、コードでは全額返金しかできません。どちらが正しいでしょうか？」用語集とコードの食い違いを、黙って放置してはいけません。

CONTEXT.md の更新

用語が合意されたら、その場ですぐ CONTEXT.md を更新します。用語集の編集を後回しにしてまとめて行ってはいけません。まとめて記録しようとした用語は忘れられます。CONTEXT.md がまだ存在しない場合は、最初の用語が合意された時点で必要に応じて作成します（プラグインとしてインストールされている場合はスキルセットの templates/CONTEXT.md を ${CLAUDE_PLUGIN_ROOT}/templates から、そうでない場合はこの SKILL.md からの相対パス ../../../templates からコピーします）。

CONTEXT.md に記録するのは、用語の定義だけです。決定事項は ADR に、実装の詳細や仕様の断片は仕様書に記録します。用語の形式は次のとおりです。

**Workspace**:
The top-level container a team collaborates in; owns all Notes and Folders.
_Avoid_: project, space, tenant

明確な方針を持ち、標準用語を1つだけ定め、競合する用語は _Avoid_ リストに入れます。定義は1〜3行の簡潔なものにとどめます。対象が何であるかを記し、どのように実装されるかは記しません。プロジェクト固有の概念だけを含め、一般的なプログラミング用語は含めません。

ADR — 3つの条件をすべて満たす場合に限り作成

ADR を提案するのは、次の 3つすべて を満たす場合に限ります。

1. 覆すのが難しい — 後から方針を変えるには、実質的なコストがかかります。
2. 背景を知らないと意外に思える — 将来の読者が「なぜわざわざこの方法にしたのか」と疑問に思うでしょう。
3. 実際のトレードオフがある — 現実的な選択肢が複数あり、特定の理由からそのうちの1つを選びました。

1つでも満たさない場合は、ADR を作成しません。対比例として、意外で実際のトレードオフがある決定でも、簡単に覆せる なら ADR は不要です。検索ボックスのデバウンスを200 msにする決定は、応答性とリクエスト量のトレードオフがありますが、後から変えるのは1行の変更なので、「覆すのが難しい」という条件を満たしません。ADR ではなくコードに記録します。形式は docs/adr/NNNN-slug.md とします（ディレクトリは必要になった時点で作成します）。番号は連番とし、既存の番号をスキャンして最も大きい番号の次を使います。本文は短いタイトルと 1〜3文 で、背景、決定、理由を記します。それだけで十分です。価値があるのは、セクションを埋めることではなく、決定とその理由を記録することです。

新しい決定が既存の ADR と矛盾する場合は、その矛盾をユーザーに伝え、明示的に解決します（古い ADR を番号で指定して置き換えます）。