yodogawa 2.0.0 → 2.1.0

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

@@ -1,142 +1,99 @@
----
-name: a-003-create-scenarios
-description: ユーザーストーリーから具体的なGherkinシナリオを作成し、BDD形式で振る舞いを定義するワークフロー
----
-
-# CreateScenarios (a-003)
-
-## 目的
-
-- ユーザーストーリーから具体的なシナリオ（振る舞い）を抽出し、Gherkin形式で記述する。
-- Given-When-Then構造で、開発者・QA・ステークホルダーが共通理解できる実行可能なドキュメントを作成する。
-- ハッピーパス（正常系）からエラーケース、境界値テストまでを網羅的に定義する。
-
-## 前提
-
-- `docs/project/requirements/05-user-stories.md` が作成されていること（先に `InitializeProject` (a-002) を実行）。
-- `docs/project/behavior/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) を実行）。
-- ユーザーが各機能の具体的な動作例を説明できること。
-
-## 手順
-
-### 1. ディレクトリと前提条件の確認
-
-- `docs/project/behavior/` ディレクトリの存在を確認：
-
-  ```bash
-  ls -la docs/project/behavior/ 2>/dev/null || echo "ディレクトリが存在しません"
-  ```
-
-- ディレクトリが存在しない場合：
-  - ユーザーに通知：「`docs/project/behavior/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してください。」
-
-- ユーザーストーリーの確認：
-  - `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. 分析と提案
-
-- `docs/project/requirements/05-user-stories.md` を分析し、シナリオ作成対象の機能（Feature）をリストアップする。
-- 各機能について、考えられるシナリオ案（ハッピーパスと代表的なエラーケース）をユーザーに提案する：
-  - 「以下のユーザーストーリーに基づいて、シナリオを作成します：」
-  - 「機能: [機能名] (US-XXX)」
-    - 「シナリオ案1: [ハッピーパス]」
-    - 「シナリオ案2: [エラーケース]」
-
-### 4. ヒアリングと記入
-
-各機能について、以下の順序でヒアリングを行い、`docs/project/behavior/01-scenarios.md` を更新する。
-
-#### 4.1 Feature情報の定義
-
-- 機能名、説明、対応するユーザーストーリー（As a/I want/So that）を記入する。
-- **Background**（共通前提条件）がある場合は定義する。
-
-#### 4.2 シナリオの作成（ハッピーパス）
-
-- 「最も基本的な成功シナリオを教えてください。」
-- **Given**（前提）、**When**（アクション）、**Then**（結果）を確認し、Gherkin形式で記述する。
-- UI操作の詳細ではなく、ユーザーの意図を記述するよう注意する。
-
-#### 4.3 エラーケース・境界値の作成
-
-- 「エラーケースや境界値（エッジケース）はありますか？」
-- 必要に応じて **Scenario Outline**（パラメータ化）の使用を提案し、Examplesテーブルを作成する。
-
-#### 4.4 タグ付け
-
-- シナリオID（`@SC-XXX`）を採番する。
-- 適切なタグ（`@smoke`, `@happy-path`, `@error-handling` など）を付与する。
-
-### 5. シナリオ一覧テーブルの更新
-
-- ドキュメント冒頭の「シナリオ一覧」テーブルを更新し、作成した全シナリオのID、機能、シナリオ名、優先度を記載する。
-
-### 6. レビューと確認
-
-- 作成したシナリオをユーザーに提示し、以下を確認：
-  - 「シナリオは実際の動作を正しく表現していますか？」
-  - 「漏れているケースはありませんか？」
-  - 「非技術者でも理解できる表現になっていますか？」
-
-### 7. 完了条件と構造の確認
-
-- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
-
-  1. **構造確認**:
-
-     ```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"
-     ```
-
-  2. **チェックリスト**:
-     - [ ] `docs/project/behavior/01-scenarios.md` が作成されている
-     - [ ] シナリオ一覧テーブルが更新されている
-     - [ ] 各FeatureがGherkin形式で記述されている
-     - [ ] 正常系と異常系のシナリオが網羅されている
-
-### 8. Git への追加（オプション）
-
-- ユーザーに確認：「作成したシナリオドキュメントを Git に追加しますか？」
-- 「はい」の場合、以下を実行：
-
-  ```bash
-  git add docs/project/behavior/
-  git status
-  ```
-
-- 推奨コミットメッセージ：
-
-  ```
-  docs: 振る舞い仕様（シナリオ）の作成
-
-  - ユーザーストーリーに基づくGherkinシナリオを追加
-  - 正常系・異常系・境界値ケースを定義
-  ```
-
-## 完了条件
-
-- `docs/project/behavior/01-scenarios.md` が作成されている。
-- ユーザーストーリーに対応する具体的なシナリオ（Given-When-Then）が記述されている。
-- シナリオ一覧テーブルがメンテナンスされている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- ユーザーストーリーが不明確でシナリオ化できない場合：
-  - 「ユーザーストーリーの詳細化が必要です。`InitializeProject` ワークフローに戻って要件を明確にしましょう。」と提案する。
-- 実装詳細への依存が強すぎる場合：
-  - 「UI操作（ボタンクリック等）ではなく、ユーザーの意図（登録する等）に焦点を当てた記述に変更しましょう。」とリファクタリングを提案する。
+---
+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

@@ -1,144 +1,99 @@
----
-name: a-004-define-domain-model
-description: Event Storming形式でドメインモデルを定義し、ユビキタス言語を反復的に洗練させるワークフロー
----
-
-# DefineDomainModel (a-004)
-
-## 目的
-
-- Event Storming形式でドメインモデルを体系的に定義する。
-- ドメインモデルを作成しながら、ユビキタス言語（共通用語）を並行して洗練させる。
-- Bounded Context（境界づけられたコンテキスト）を特定し、各コンテキスト内のActors、Commands、Events、Policies、Aggregatesを明確化する。
-
-## 前提
-
-- `docs/project/behavior/01-scenarios.md` が作成されていること（先に `CreateScenarios` (a-003) を実行）。
-- `docs/project/domain/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) を実行）。
-- ドメインエキスパート（ビジネス側の専門家）と協力できること。
-
-## 手順
-
-### 1. ディレクトリと前提条件の確認
-
-- `docs/project/domain/` ディレクトリの存在を確認：
-
-  ```bash
-  ls -la docs/project/domain/ 2>/dev/null || echo "ディレクトリが存在しません"
-  ```
-
-- ディレクトリが存在しない場合：
-  - ユーザーに通知：「`docs/project/domain/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してください。」
-
-- シナリオの確認：
-  - `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（ビジネス領域）を提案する。
-  - 「シナリオから、以下のBounded Contextが考えられます：[コンテキスト一覧]」
-- 各Contextの戦略的分類（Core/Supporting/Generic）を確認する。
-
-### 4. 各Bounded Context のドメインモデル定義
-
-各Bounded Contextについて、以下の要素をヒアリング・定義し、`01-domain-model.md` を更新する。
-**同時に、新しい用語が登場するたびに `02-ubiquitous-language.md` にも追記する。**
-
-#### 4.1 概要とアクター
-
-- Contextの責務と主要な責任
-- 登場するアクター（Actors）とその役割
-
-#### 4.2 コマンドとイベント (Event Storming)
-
-- アクターが実行するアクション（**Commands**、命令形）
-- その結果発生するビジネス上の出来事（**Domain Events**、過去形）
-- 自動化ルール（**Policies**、"Whenever ..., then ..."）
-
-#### 4.3 集約とモデル
-
-- 一貫性を保つエンティティの塊（**Aggregates**）
-- 画面表示用の参照モデル（**Read Models**）
-- 連携する外部システム（**External Systems**）
-
-### 5. ユビキタス言語の洗練
-
-- `02-ubiquitous-language.md` を見直し、以下の点を確認・修正する：
-  - 用語の重複や曖昧さがないか
-  - 禁止用語（Data, Processなど曖昧な語）が含まれていないか
-  - 定義が具体的で、Context内での意味に限定されているか
-
-### 6. Context Map の定義
-
-- 各Context間の関係性（Customer-Supplier, Shared Kernelなど）を定義し、`01-domain-model.md` のContext Mapセクション（Mermaid図）を更新する。
-
-### 7. レビューと確認
-
-- 作成したドキュメントを提示し、以下を確認する：
-  - 「ビジネス用語は正確に表現されていますか？」
-  - 「Aggregateの境界は適切ですか？」
-  - 「ユビキタス言語の定義は明確ですか？」
-
-### 8. 完了条件と構造の確認
-
-- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
-
-  1. **構造確認**:
-
-     ```bash
-     # Bounded Context定義の確認
-     grep "Bounded Context:" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Bounded Context definition"
-     # Aggregate定義の確認
-     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"
-     ```
-
-  2. **チェックリスト**:
-     - [ ] `docs/project/domain/01-domain-model.md` が作成され、主要なEvent Storming要素が含まれている
-     - [ ] `docs/project/domain/02-ubiquitous-language.md` が作成され、用語が定義されている
-     - [ ] ドメインモデルとユビキタス言語の整合性が取れている
-
-### 9. Git への追加（オプション）
-
-- ユーザーに確認：「作成したドメインモデルドキュメントを Git に追加しますか？」
-- 「はい」の場合、以下を実行：
-
-  ```bash
-  git add docs/project/domain/
-  git status
-  ```
-
-- 推奨コミットメッセージ：
-
-  ```
-  docs: ドメインモデルとユビキタス言語の定義
-
-  - Event Stormingによるドメインモデルの作成
-  - Bounded Contextごとのユビキタス言語の整備
-  ```
-
-## 完了条件
-
-- `docs/project/domain/01-domain-model.md` が作成されている。
-- `docs/project/domain/02-ubiquitous-language.md` が作成されている。
-- 各Bounded Contextについて、主要なドメイン要素（Aggregates, Commands, Events）が定義されている。
-- ドメインモデルで使用される用語がユビキタス言語として定義されている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- シナリオが不足していてドメインモデルを作成できない場合：
-  - 「シナリオ不足のためモデル化が困難です。`CreateScenarios` (a-003) に戻ってシナリオを充実させましょう。」と提案する。
-- Bounded Contextの境界が不明確な場合：
-  - 「境界が曖昧です。暫定的な境界を設定し、実装を進めながら見直す方針で進めませんか？」と提案する。
+---
+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 パターン、構造確認コマンド