yodogawa 1.0.7 → 2.1.0

package/skills/a-002-initialize-project/reference/hearing-questions.md

@@ -0,0 +1,92 @@
+# ヒアリング質問集
+
+SKILL.md 手順3〜7で各テンプレートに記入する際のヒアリング質問一覧。
+
+## 手順3: システム概要
+
+### 背景
+
+- 「このシステムで解決しようとしている**具体的な問題や課題**は何ですか？」
+- 「その問題はなぜ重要ですか？放置した場合のリスクは？」
+- 「問題の影響を受けるステークホルダー（ユーザー、組織、チームなど）は誰ですか？」
+- 「具体的な数値やデータ（作業時間、コスト、離脱率など）があれば教えてください。」
+
+### 目的
+
+- 「このシステムが提供する**具体的な価値や解決策**は何ですか？」
+- 「期待される成果や変化を、測定可能な形で表現できますか？（例: 作業時間 50%削減）」
+- 「どのように問題を解決するか、具体的なメカニズムや仕組みを教えてください。」
+
+## 手順4: 実装済み機能一覧
+
+### コード調査のヒントと提案
+
+```bash
+find src app lib -maxdepth 2 -type d 2>/dev/null
+find . -type f -name "*Controller*" -o -name "*Service*" -o -name "*Component*" | head -n 20
+```
+
+提案例:
+
+- 「`src/auth` ディレクトリが見つかりました。認証機能（ログイン、登録など）は実装済みですか？」
+- 「`PaymentController` があります。決済機能は稼働していますか？」
+
+### ヒアリング項目
+
+- 「既に実装済みの機能はありますか？（提案した機能含む）」
+  - **Category 1**（大分類: ユーザー管理、コンテンツなど）
+  - **Category 2**（中分類: 認証、プロフィールなど）
+  - **機能名**（ユーザー視点の名称）
+  - **説明**（何ができるか）
+  - **機能 ID**（FN-XXX 形式、連番）
+
+## 手順5: 予定機能一覧
+
+### 差分分析からの提案例
+
+- 「システム概要で『〇〇機能』への言及がありましたが、まだ実装されていないようです。予定機能に追加しますか？」
+- 「現在の実装に『××』が含まれていますが、関連する『△△機能』は将来的に必要ですか？」
+
+### ヒアリング項目
+
+- **Category 1** / **Category 2**
+- **機能名**（アイデア段階でも可）
+- **説明**（目的や価値を中心に）
+
+※ 機能 ID・優先度はこの段階では確定させず、柔軟性を重視して記載しない。
+
+## 手順6: 非機能要件
+
+### パフォーマンス
+
+- 「ページ読み込み時間の目標は？」
+- 「API レスポンス時間の目標は？」
+- 「想定される同時接続ユーザー数、データ量は？」
+
+### セキュリティ
+
+- 「認証方式、機密データの扱い、コンプライアンス要件は？」
+
+### 可用性・信頼性
+
+- 「稼働率目標、許容ダウンタイム、バックアップ要件は？」
+
+### スケーラビリティ
+
+- 「ユーザー数の成長予測、ピーク時のトラフィック想定は？」
+
+### ユーザビリティ・保守性
+
+- 「アクセシビリティ、対応言語、デバイス、ブラウザは？」
+- 「ログ・監視要件、デプロイ頻度は？」
+
+## 手順7: ユーザーストーリー
+
+### 提案テンプレート
+
+「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
+
+### ヒアリング項目
+
+- 「他に主要なユーザージャーニーがあれば教えてください（[役割]として、[目的]がしたい、なぜなら[理由]）」
+- 各ストーリーの優先度、受け入れ基準

package/skills/a-002-initialize-project/reference/structure-check.md

@@ -0,0 +1,48 @@
+# 構造チェックコマンド集
+
+SKILL.md 手順9で使う、生成済みドキュメントの構造確認用コマンド。
+
+## 5ドキュメントの必須セクション/テーブル検証
+
+```bash
+# 01-system-overview.md: 主要セクションの確認
+grep "## 背景" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 背景"
+grep "## 目的" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 目的"
+
+# 02-features-implemented.md: テーブルヘッダー
+grep "| 機能ID | Category 1 |" docs/project/requirements/02-features-implemented.md \
+  && echo "OK" || echo "MISSING: Table Header"
+
+# 03-features-planned.md: テーブルヘッダー
+grep "| Category 1 | Category 2 |" docs/project/requirements/03-features-planned.md \
+  && echo "OK" || echo "MISSING: Table Header"
+
+# 04-non-functional-requirements.md: テーブルヘッダー
+grep "| カテゴリ | 要件 |" docs/project/requirements/04-non-functional-requirements.md \
+  && echo "OK" || echo "MISSING: Table Header"
+
+# 05-user-stories.md: テーブルヘッダー
+grep "| ストーリーID | ストーリー |" docs/project/requirements/05-user-stories.md \
+  && echo "OK" || echo "MISSING: Table Header"
+```
+
+## チェックリスト
+
+- [ ] すべてのファイルが存在する
+- [ ] 各ファイルがテンプレートの基本構造を維持している（主要セクション・テーブル）
+- [ ] プレースホルダーが適切な内容に置き換わっている
+
+## Git への追加（オプション）
+
+```bash
+git add docs/project/requirements/
+git status
+```
+
+推奨コミットメッセージ:
+
+```
+docs: 要件定義ドキュメントの作成
+
+- システム概要、機能要件、非機能要件、ユーザーストーリーを追加
+```

package/skills/a-003-create-scenarios/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: a-003-create-scenarios
+description: ユーザーストーリーから Gherkin 形式のシナリオを生成し、BDD で振る舞いを定義する。要件定義後、ドメインモデル設計前の振る舞い明確化に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# CreateScenarios (a-003)
+
+## 目的
+
+- ユーザーストーリーから具体的なシナリオ（振る舞い）を抽出し、Gherkin 形式で記述する。
+- Given-When-Then 構造で、開発者・QA・ステークホルダーが共通理解できる実行可能なドキュメントを作成する。
+- ハッピーパス（正常系）からエラーケース、境界値テストまでを網羅的に定義する。
+
+## 前提
+
+- `docs/project/requirements/05-user-stories.md` が作成されていること（`/a-002-initialize-project` 実行済み）。
+- `docs/project/behavior/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
+- ユーザーが各機能の具体的な動作例を説明できること。
+
+## 手順
+
+### 1. ディレクトリと前提条件の確認
+
+```bash
+ls -la docs/project/behavior/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+`docs/project/requirements/05-user-stories.md` を読み込み、シナリオ化対象を把握する。
+
+### 2. テンプレートの準備
+
+```bash
+SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
+cp "$SCRIPT_DIR/templates/project/02-behavior/01-scenarios.md" "docs/project/behavior/01-scenarios.md"
+```
+
+### 3. 分析と提案
+
+ユーザーストーリーを機能（Feature）単位にグルーピングし、ハッピーパスと代表的なエラーケースの案を提示。
+
+- 「機能: [機能名] (US-XXX)」
+- 「シナリオ案1: [ハッピーパス] / シナリオ案2: [エラーケース]」
+
+### 4. ヒアリングと記入
+
+機能ごとに以下を詰めて `docs/project/behavior/01-scenarios.md` を更新する。Gherkin 記述例は [examples/gherkin-templates.md](examples/gherkin-templates.md) を参照。
+
+- **Feature 情報**: 機能名、As a/I want/So that、Background（共通前提）
+- **ハッピーパス**: Given-When-Then で最も基本的な成功シナリオ
+- **エラーケース・境界値**: 必要に応じて Scenario Outline（Examples テーブル）を使用
+- **タグ付け**: `@SC-XXX` ID 採番、`@smoke` `@happy-path` `@error-handling` 等
+
+UI 操作の詳細ではなく、ユーザーの意図を記述するよう注意する。
+
+### 5. シナリオ一覧テーブルの更新
+
+ドキュメント冒頭の一覧テーブルに、全シナリオの ID・機能・シナリオ名・優先度を記載する。テーブル例は [examples/gherkin-templates.md](examples/gherkin-templates.md#シナリオ一覧テーブル例) を参照。
+
+### 6. レビューと確認
+
+ユーザーに提示し、実際の動作の正確性、抜け漏れ、非技術者への理解可能性を確認する。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。
+
+### 7. 構造チェック
+
+```bash
+grep "Feature:" docs/project/behavior/01-scenarios.md \
+  && grep "Scenario:" docs/project/behavior/01-scenarios.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細なチェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 8. Git への追加（任意）
+
+```bash
+git add docs/project/behavior/
+git commit -m "docs: 振る舞い仕様（シナリオ）の作成"
+```
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
+
+## 完了条件
+
+- `docs/project/behavior/01-scenarios.md` が作成されている。
+- ユーザーストーリーに対応する具体的なシナリオ（Given-When-Then）が記述されている。
+- シナリオ一覧テーブルがメンテナンスされている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **ユーザーストーリーが不明確でシナリオ化できない**: 「`/a-002-initialize-project` に戻って要件を明確にしましょう。」
+- **実装詳細への依存が強すぎる**: 「UI 操作（ボタンクリック等）ではなく、ユーザーの意図（登録する等）に焦点を当てた記述に変更しましょう。」
+
+## 参考
+
+- [examples/gherkin-templates.md](examples/gherkin-templates.md) — Feature / Scenario / Scenario Outline の記述例、タグ付けガイド、一覧テーブル例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点、Git 追加例

package/skills/a-003-create-scenarios/examples/gherkin-templates.md

@@ -0,0 +1,71 @@
+# Gherkin シナリオ記述例とタグ
+
+SKILL.md 手順3〜5 で使用する Gherkin 形式のテンプレートとタグ付けのサンプル。
+
+## Feature 定義の形式
+
+```gherkin
+Feature: [機能名]
+  As a [役割]
+  I want [やりたいこと]
+  So that [得られる価値]
+
+  Background:
+    Given [共通の前提条件]
+```
+
+## ハッピーパスのシナリオ例
+
+```gherkin
+@SC-001 @smoke @happy-path
+Scenario: 正常にログインできる
+  Given ユーザーは登録済みである
+  When 正しいメールアドレスとパスワードを入力する
+  And ログインボタンを押下する
+  Then ダッシュボード画面が表示される
+```
+
+- UI 操作（「ボタンをクリック」）ではなく、ユーザーの意図（「ログインする」）を優先する。
+- 複数ステップは `And` / `But` で繋ぐ。
+
+## エラーケース・境界値（Scenario Outline）
+
+```gherkin
+@SC-002 @error-handling
+Scenario Outline: 不正な入力でログインに失敗する
+  Given ユーザーは登録済みである
+  When <email> と <password> を入力する
+  Then <message> が表示される
+
+  Examples:
+    | email             | password   | message              |
+    | invalid@mail      | correctPw1 | メール形式が不正です  |
+    | test@example.com  |            | パスワードが必要です  |
+    | test@example.com  | wrong      | 認証に失敗しました    |
+```
+
+## タグ付けガイド
+
+- `@SC-XXX`: シナリオ ID（必須）
+- `@smoke`: リリース前の最小確認対象
+- `@happy-path`: 正常系
+- `@error-handling`: エラーケース
+- `@regression`: 実装済み機能のリグレッション
+- 優先度別: `@high`, `@medium`, `@low`
+
+## シナリオ一覧テーブル例
+
+| シナリオID | 機能 | シナリオ名 | 優先度 |
+|:--|:--|:--|:--|
+| SC-001 | 認証 | 正常ログイン | High |
+| SC-002 | 認証 | 入力エラー | High |
+| SC-003 | 登録 | メール認証完了 | Medium |
+
+## コミットメッセージ例
+
+```text
+docs: 振る舞い仕様（シナリオ）の作成
+
+- ユーザーストーリーに基づく Gherkin シナリオを追加
+- 正常系・異常系・境界値ケースを定義
+```

package/skills/a-003-create-scenarios/reference/structure-check.md

@@ -0,0 +1,46 @@
+# 構造チェックとレビュー観点
+
+SKILL.md 手順6〜7 で使う構造確認コマンドとレビュー観点。
+
+## セクション存在確認
+
+```bash
+# シナリオ一覧テーブルの確認
+grep "| シナリオID | 機能 |" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Table Header"
+# Feature 定義の確認
+grep "Feature:" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Feature definition"
+# Scenario 定義の確認
+grep "Scenario:" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Scenario definition"
+```
+
+## チェックリスト
+
+- [ ] `docs/project/behavior/01-scenarios.md` が作成されている
+- [ ] シナリオ一覧テーブルが更新されている
+- [ ] 各 Feature が Gherkin 形式で記述されている
+- [ ] 正常系と異常系のシナリオが網羅されている
+- [ ] Empty State や境界値も考慮されている
+- [ ] タグ（@SC-XXX, @smoke 等）が付与されている
+
+## レビュー確認質問
+
+- 「シナリオは実際の動作を正しく表現していますか？」
+- 「漏れているケース（エラー、境界値）はありませんか？」
+- 「非技術者でも理解できる表現になっていますか？」
+- 「UI 操作に依存せず、ユーザーの意図を表現できていますか？」
+
+## Git への追加（任意）
+
+```bash
+git add docs/project/behavior/
+git status
+```
+
+推奨コミットメッセージ:
+
+```text
+docs: 振る舞い仕様（シナリオ）の作成
+
+- ユーザーストーリーに基づく Gherkin シナリオを追加
+- 正常系・異常系・境界値ケースを定義
+```

package/skills/a-004-define-domain-model/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: a-004-define-domain-model
+description: Event Storming 形式でドメインモデル（イベント・コマンド・集約）を定義し、ユビキタス言語を整備する。シナリオ作成後、ドメイン設計を開始する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineDomainModel (a-004)
+
+## 目的
+
+- Event Storming 形式でドメインモデルを体系的に定義する。
+- ドメインモデルを作成しながら、ユビキタス言語（共通用語）を並行して洗練させる。
+- Bounded Context を特定し、Actors / Commands / Events / Policies / Aggregates を明確化する。
+
+## 前提
+
+- `docs/project/behavior/01-scenarios.md` が作成されている（`/a-003-create-scenarios` 実行済み）
+- `docs/project/domain/` ディレクトリが存在（なければ `/a-001-setup-doc-structure`）
+- ドメインエキスパートと協力できる
+
+## 手順
+
+### 1. ディレクトリと前提条件の確認
+
+```bash
+ls -la docs/project/domain/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+存在しなければ `/a-001-setup-doc-structure` を促す。`docs/project/behavior/01-scenarios.md` を読み込み内容確認。
+
+### 2. テンプレートの準備
+
+```bash
+SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
+cp "$SCRIPT_DIR/templates/project/03-domain/01-domain-model.md" "docs/project/domain/01-domain-model.md"
+cp "$SCRIPT_DIR/templates/project/03-domain/02-ubiquitous-language.md" "docs/project/domain/02-ubiquitous-language.md"
+```
+
+### 3. Bounded Context の特定
+
+シナリオとユーザーストーリーから Bounded Context を提案し、戦略的分類（Core / Supporting / Generic）を確認。詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#bounded-context-の特定) を参照。
+
+### 4. 各 Bounded Context のドメインモデル定義
+
+各 Context について以下を定義し、`01-domain-model.md` を更新。新しい用語が登場するたびに `02-ubiquitous-language.md` にも追記。
+
+- 概要とアクター
+- コマンド / イベント / ポリシー（Event Storming）
+- 集約 / Read Models / External Systems
+
+各要素の詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#各-context-の定義項目) を参照。
+
+### 5. ユビキタス言語の洗練
+
+`02-ubiquitous-language.md` を見直し、重複・曖昧さ・禁止用語を排除。観点は [reference/event-storming-guide.md](reference/event-storming-guide.md#ユビキタス言語の洗練観点) を参照。
+
+### 6. Context Map の定義
+
+Context 間の関係性（Customer-Supplier, Shared Kernel 等）を Mermaid 図で定義。関係パターン: [reference/event-storming-guide.md](reference/event-storming-guide.md#context-map-の関係性)
+
+### 7. レビューと確認
+
+作成したドキュメントを提示し、ビジネス用語の正確性 / Aggregate 境界 / ユビキタス言語定義を確認。
+
+### 8. 完了条件と構造の確認
+
+構造確認コマンドは [reference/event-storming-guide.md](reference/event-storming-guide.md#構造確認コマンド) を参照。
+
+チェックリスト:
+
+- [ ] `01-domain-model.md` に主要な Event Storming 要素が含まれている
+- [ ] `02-ubiquitous-language.md` の用語が定義されている
+- [ ] ドメインモデルとユビキタス言語の整合性が取れている
+
+### 9. Git への追加（オプション）
+
+```bash
+git add docs/project/domain/
+git status
+```
+
+コミットメッセージ: [reference/event-storming-guide.md](reference/event-storming-guide.md#git-コミットメッセージ)
+
+## 完了条件
+
+- `docs/project/domain/01-domain-model.md` と `02-ubiquitous-language.md` が作成されている
+- 各 Bounded Context の主要ドメイン要素（Aggregates, Commands, Events）が定義されている
+- ドメインモデルで使用される用語がユビキタス言語として定義されている
+- ユーザーが内容を承認している
+
+## エスカレーション
+
+- **シナリオが不足**: 「`/a-003-create-scenarios` に戻ってシナリオを充実させましょう。」
+- **Bounded Context の境界が不明確**: 「暫定的な境界を設定し、実装を進めながら見直す方針で進めませんか？」
+
+## 参考
+
+- [reference/event-storming-guide.md](reference/event-storming-guide.md) — Event Storming の観点、Context Map パターン、構造確認コマンド

package/skills/a-004-define-domain-model/reference/event-storming-guide.md

@@ -0,0 +1,71 @@
+# Event Storming ガイド
+
+SKILL.md 手順3〜6で使うドメインモデル定義の観点集。
+
+## Bounded Context の特定
+
+シナリオとユーザーストーリーを分析し、ビジネス領域を特定。
+
+- **戦略的分類**:
+  - **Core**: ビジネスの中核的な競争優位を生む領域
+  - **Supporting**: Core を支援する領域
+  - **Generic**: 汎用的に解決できる領域（既製ソリューション候補）
+
+## 各 Context の定義項目
+
+### 概要とアクター
+
+- Context の責務と主要な責任
+- 登場するアクター（Actors）とその役割
+
+### コマンドとイベント（Event Storming）
+
+- **Commands**: アクターが実行するアクション（命令形、例: `RegisterUser`）
+- **Domain Events**: 結果として発生するビジネス上の出来事（過去形、例: `UserRegistered`）
+- **Policies**: 自動化ルール（`Whenever X, then Y` 形式）
+
+### 集約とモデル
+
+- **Aggregates**: 一貫性を保つエンティティの塊
+- **Read Models**: 画面表示用の参照モデル
+- **External Systems**: 連携する外部システム
+
+## ユビキタス言語の洗練観点
+
+- 用語の重複や曖昧さがないか
+- 禁止用語（`Data`, `Process` など曖昧な語）が含まれていないか
+- 定義が具体的で Context 内での意味に限定されているか
+
+## Context Map の関係性
+
+- **Customer-Supplier**: 上流/下流の依存関係
+- **Shared Kernel**: 共有される小さなモデル
+- **Anticorruption Layer**: 外部モデルの変換層
+- **Conformist**: 上流に従う
+- **Partnership**: 相互協調
+
+## レビュー観点
+
+- ビジネス用語は正確に表現されているか
+- Aggregate の境界は適切か
+- ユビキタス言語の定義は明確か
+
+## 構造確認コマンド
+
+```bash
+grep "Bounded Context:" docs/project/domain/01-domain-model.md \
+  && echo "OK" || echo "MISSING: Bounded Context definition"
+grep "### Aggregates" docs/project/domain/01-domain-model.md \
+  && echo "OK" || echo "MISSING: Aggregates section"
+grep "| 用語 | 定義 |" docs/project/domain/02-ubiquitous-language.md \
+  && echo "OK" || echo "MISSING: Terminology table"
+```
+
+## Git コミットメッセージ
+
+```
+docs: ドメインモデルとユビキタス言語の定義
+
+- Event Stormingによるドメインモデルの作成
+- Bounded Contextごとのユビキタス言語の整備
+```

package/skills/a-005-create-domain-diagram/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: a-005-create-domain-diagram
+description: ドメインモデルを Mermaid 図（Context Map・Aggregate 構造）として可視化する。ドメインモデル定義後、関係性を図で確認する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# CreateDomainDiagram (a-005)
+
+## 目的
+
+- ドメインモデルドキュメント（`01-domain-model.md`）を基に、視覚的なダイアグラムを作成する。
+- Context Map（Bounded Context 間の関係図）を Mermaid 形式で図示する。
+- 各 Bounded Context 内の Aggregate 構造や関係性を図示する（オプション）。
+
+## 前提
+
+- `docs/project/domain/01-domain-model.md` が作成されていること（`/a-004-define-domain-model` 実行済み）。
+- ドメインモデルドキュメントに Bounded Context の一覧と関係性が記述されていること。
+
+## 手順
+
+### 1. ドキュメントの確認
+
+```bash
+ls -la docs/project/domain/01-domain-model.md 2>/dev/null || echo "ファイルが存在しません"
+```
+
+未作成の場合、`/a-004-define-domain-model` の実行を促す。
+
+### 2. Context Map の情報収集と提案
+
+`docs/project/domain/01-domain-model.md` から以下を抽出し、構成案を提示する:
+
+- Bounded Context のリスト
+- 戦略的分類（Core / Supporting / Generic）
+- Context 間の関係性と通信方法
+
+### 3. Context Map 図の作成
+
+`## Context Map` セクションに Mermaid 図を追加する。スタイル定義と記述テンプレートは [examples/mermaid-templates.md](examples/mermaid-templates.md#context-mapbounded-context-間の関係) を参照。
+
+- Core Domain: 金色、Supporting: 水色、Generic: グレー
+- エッジラベルに関係パターン（Customer/Supplier、ACL 等）と通信方法を記載
+
+### 4. 詳細図の作成（オプション）
+
+ユーザー確認の上、以下を追加作成する:
+
+- **Aggregate 構造図**: クラス図形式。Aggregate 内部の Entity/Value Object と関係を表現。
+- **イベントフロー図**: シーケンス図形式。主要ビジネスフロー（Command → Event → Policy）を表現。
+
+テンプレートは [examples/mermaid-templates.md](examples/mermaid-templates.md#aggregate-構造図クラス図形式) を参照。
+
+### 5. レビューと確認
+
+作成した図を提示し、関係性の正確性、色分けの適切性、読みやすさを確認する。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。フィードバックに応じてレイアウト（TD/LR）や配置を調整する。
+
+### 6. 構造チェック
+
+```bash
+grep "\`\`\`mermaid" docs/project/domain/01-domain-model.md \
+  && grep "## Context Map" docs/project/domain/01-domain-model.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/project/domain/01-domain-model.md
+git commit -m "docs: ドメインモデル図（Context Map）の追加"
+```
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
+
+## 完了条件
+
+- `docs/project/domain/01-domain-model.md` に Context Map 図が追加されている。
+- Bounded Context 間の関係性が正しく表現されている。
+- 戦略的分類が視覚的に区別されている。
+- オプションの詳細図（Aggregate 図、シーケンス図）が必要に応じて追加されている。
+- ユーザーが図の内容を承認している。
+
+## エスカレーション
+
+- **ドメインモデルが不完全で図を作成できない**: 「`/a-004-define-domain-model` に戻って定義を補完しましょう。」
+- **図が複雑すぎて読みにくい**: 「主要な関係のみに絞るか、図を分割することを検討しましょう。」
+
+## 参考
+
+- [examples/mermaid-templates.md](examples/mermaid-templates.md) — Context Map / Aggregate / シーケンス図の Mermaid テンプレート、スタイル定義、エッジラベル例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例