pedro-oscar/shorts-ai

ドメインモデリング

設計中にプロジェクトのドメインモデルを積極的に構築・洗練します。これは能動的な規律です。用語に挑戦し、エッジケースシナリオを考案し、用語と決定が固まった瞬間に用語集と決定を書き留めます。（単に語彙のためにGLOSSARY.mdを読むことはこのスキルではありません。それはどのスキルでもできる一行の習慣です。このスキルは、モデルを消費するだけでなく、変更しているときに使います。）

ファイル構造

ほとんどのリポジトリには単一のコンテキストがあります：

/
├── GLOSSARY.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

ルートにGLOSSARY-MAP.mdが存在する場合、リポジトリには複数のコンテキストがあります。マップは各コンテキストがどこにあるかを示します：

/
├── GLOSSARY-MAP.md
├── docs/
│   └── adr/                          ← システム全体の決定
├── src/
│   ├── ordering/
│   │   ├── GLOSSARY.md
│   │   └── docs/adr/                 ← コンテキスト固有の決定
│   └── billing/
│       ├── GLOSSARY.md
│       └── docs/adr/

ファイルは必要なときにだけ遅延作成します。GLOSSARY.mdが存在しない場合、最初の用語が確定したときに作成します。docs/adr/が存在しない場合、最初のADRが必要になったときに作成します。

セッション中

用語集に対する挑戦

ユーザーがGLOSSARY.mdの既存の言語と矛盾する用語を使用した場合、すぐにそれを指摘します。「用語集では'キャンセル'をXと定義していますが、あなたはYを意味しているようです。どちらでしょうか？」

曖昧な言語の明確化

ユーザーが曖昧または過負荷な用語を使用した場合、正確な標準用語を提案します。「'アカウント'と言っていますが、Customerを意味していますか、それともUserですか？それらは異なるものです。」

具体的なシナリオの議論

ドメイン関係について議論しているときは、具体的なシナリオでストレステストを実施します。エッジケースを探り、概念間の境界を正確に定義するようユーザーに促すシナリオを考案します。

コードとの相互参照

ユーザーが何かの動作を説明したとき、コードがそれに一致するか確認します。矛盾を見つけた場合は、それを表面化します：「コードは注文全体をキャンセルしていますが、部分キャンセルが可能とおっしゃいました。どちらが正しいですか？」

GLOSSARY.mdのインライン更新

用語が確定したら、その場でGLOSSARY.mdを更新します。まとめて行わず、発生したときに捕捉します。GLOSSARY-FORMAT.mdのフォーマットを使用してください。

GLOSSARY.mdは実装の詳細を一切含まないようにしてください。GLOSSARY.mdを仕様、スクラッチパッド、実装決定のリポジトリとして扱わないでください。これは用語集であり、それ以外のものではありません。

ADRは控えめに提案

以下の3つすべてが真の場合にのみ、ADRの作成を提案します：

1. 元に戻すのが難しい: 後で考えを変えるコストが大きい
2. 文脈なしでは驚かされる: 将来の読者が「なぜこうしたのか？」と疑問に思うだろう
3. 真のトレードオフの結果: 真の代替案があり、特定の理由で1つを選んだ

いずれか1つでも欠けている場合は、ADRをスキップします。ADR-FORMAT.mdのフォーマットを使用してください。