yodogawa 2.0.0 → 2.1.0

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

@@ -1,120 +1,94 @@
----
-name: a-005-create-domain-diagram
-description: ドメインモデルをMermaid図で視覚化し、Context MapやAggregate構造を図示するワークフロー
----
-
-# CreateDomainDiagram (a-005)
-
-## 目的
-
-- ドメインモデルドキュメント（`01-domain-model.md`）を基に、視覚的なダイアグラムを作成する。
-- Context Map（Bounded Context間の関係図）をMermaid形式で図示する。
-- 各Bounded Context内のAggregate構造や関係性を図示する（オプション）。
-
-## 前提
-
-- `docs/project/domain/01-domain-model.md` が作成されていること（先に `DefineDomainModel` (a-004) を実行）。
-- ドメインモデルドキュメントにBounded Contextの一覧と関係性が記述されていること。
-
-## 手順
-
-### 1. ドキュメントの確認
-
-- `docs/project/domain/01-domain-model.md` を読み込み、内容を確認する。
-
-  ```bash
-  ls -la docs/project/domain/01-domain-model.md 2>/dev/null || echo "ファイルが存在しません"
-  ```
-
-- ファイルが存在しない場合：
-  - ユーザーに通知：「ドメインモデルが見つかりません。先に `DefineDomainModel` (a-004) を実行してください。」
-
-### 2. Context Map の情報収集と提案
-
-- `docs/project/domain/01-domain-model.md` から以下の情報を抽出する：
-  - Bounded Contextのリスト
-  - 戦略的分類（Core / Supporting / Generic）
-  - Context間の関係性
-
-- 抽出した情報に基づき、Mermaid図の構成案を提示する：
-  - 「以下の関係を図示します：」
-  - 「Context A --> Context B (関係パターン)」
-
-### 3. Context Map 図の作成
-
-- `docs/project/domain/01-domain-model.md` の `## Context Map` セクションに Mermaid図を追加（または更新）する。
-- **スタイル定義**:
-  - Core Domain: 金色 (`fill:#FFD700`)
-  - Supporting Domain: 水色 (`fill:#87CEEB`)
-  - Generic Domain: グレー (`fill:#D3D3D3`)
-- **エッジ定義**:
-  - 関係パターンと通信方法をラベルに記載する。
-
-### 4. 詳細図の作成（オプション）
-
-- ユーザーに確認：「以下の詳細図も作成しますか？」
-  - **Aggregate構造図**: クラス図形式でAggregateの内部構造と関係性を表現。
-  - **イベントフロー図**: シーケンス図形式で主要なビジネスフロー（Command -> Event -> Policy）を表現。
-
-- 「はい」の場合、対象のBounded Contextやシナリオを確認し、図を作成してドキュメント内の適切な箇所に追加する。
-
-### 5. レビューと確認
-
-- 作成した図をユーザーに提示し、以下を確認：
-  - 「関係性は正しく表現されていますか？」
-  - 「分類の色分けは適切ですか？」
-  - 「複雑すぎて読みにくい箇所はありませんか？」
-
-- フィードバックに基づき、レイアウト（TD/LR）や配置を調整する。
-
-### 6. 完了条件と構造の確認
-
-- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
-
-  1. **構造確認**:
-
-     ```bash
-     # Mermaidブロックの存在確認
-     grep "\`\`\`mermaid" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Mermaid diagram"
-     # Context Mapセクションの確認
-     grep "## Context Map" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Context Map section"
-     ```
-
-  2. **チェックリスト**:
-     - [ ] `docs/project/domain/01-domain-model.md` にContext Map図が含まれている
-     - [ ] Mermaid図が正しくレンダリングされる（構文エラーがない）
-     - [ ] 戦略的分類に応じて色分けされている
-
-### 7. Git への追加（オプション）
-
-- ユーザーに確認：「更新したドメインモデルドキュメントを Git に追加しますか？」
-- 「はい」の場合、以下を実行：
-
-  ```bash
-  git add docs/project/domain/01-domain-model.md
-  git status
-  ```
-
-- 推奨コミットメッセージ：
-
-  ```
-  docs: ドメインモデル図（Context Map）の追加
-
-  - Bounded Context間の関係をMermaid図で視覚化
-  - 戦略的分類に基づく色分けを追加
-  ```
-
-## 完了条件
-
-- `docs/project/domain/01-domain-model.md` にContext Map図が追加されている。
-- Bounded Context間の関係性が正しく表現されている。
-- 戦略的分類が視覚的に区別されている。
-- オプションの詳細図（Aggregate図、シーケンス図）が必要に応じて追加されている。
-- ユーザーが図の内容を承認している。
-
-## エスカレーション
-
-- ドメインモデルが不完全で図を作成できない場合：
-  - 「必要な情報（関係性など）が不足しています。`DefineDomainModel` (a-004) に戻って定義を補完しましょう。」と提案する。
-- 図が複雑すぎて読みにくい場合：
-  - 「関係が複雑すぎます。主要な関係のみに絞るか、図を分割することを検討しましょう。」と提案する。
+---
+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 追加例

package/skills/a-005-create-domain-diagram/examples/mermaid-templates.md

@@ -0,0 +1,73 @@
+# Mermaid 図のテンプレート集
+
+SKILL.md 手順3〜4 で使用する Mermaid 記述例。
+
+## Context Map（Bounded Context 間の関係）
+
+```mermaid
+flowchart LR
+  Order[Order Context]:::core
+  Customer[Customer Context]:::supporting
+  Payment[Payment Context]:::generic
+
+  Order -->|Customer/Supplier| Customer
+  Order -->|Published Language| Payment
+
+  classDef core fill:#FFD700,stroke:#333,stroke-width:2px;
+  classDef supporting fill:#87CEEB,stroke:#333,stroke-width:1px;
+  classDef generic fill:#D3D3D3,stroke:#333,stroke-width:1px;
+```
+
+### スタイル定義
+
+- Core Domain: 金色 `fill:#FFD700`
+- Supporting Domain: 水色 `fill:#87CEEB`
+- Generic Domain: グレー `fill:#D3D3D3`
+
+### エッジ（関係）のラベル例
+
+- `-->|Customer/Supplier|`
+- `-->|Conformist|`
+- `-->|Published Language|`
+- `-->|Anti-Corruption Layer|`
+- `-->|Shared Kernel|`
+
+## Aggregate 構造図（クラス図形式）
+
+```mermaid
+classDiagram
+  class Order {
+    +OrderId id
+    +CustomerId customerId
+    +OrderStatus status
+    +place()
+    +cancel()
+  }
+  class OrderItem {
+    +ProductId productId
+    +int quantity
+  }
+  Order "1" *-- "N" OrderItem : contains
+```
+
+## イベントフロー図（シーケンス図形式）
+
+```mermaid
+sequenceDiagram
+  participant U as User
+  participant O as OrderAggregate
+  participant P as PaymentPolicy
+
+  U->>O: PlaceOrder (Command)
+  O-->>P: OrderPlaced (Event)
+  P->>P: trigger ProcessPayment
+```
+
+## コミットメッセージ例
+
+```text
+docs: ドメインモデル図（Context Map）の追加
+
+- Bounded Context 間の関係を Mermaid 図で視覚化
+- 戦略的分類に基づく色分けを追加
+```

package/skills/a-005-create-domain-diagram/reference/structure-check.md

@@ -0,0 +1,43 @@
+# 構造チェックとレビュー観点
+
+SKILL.md 手順5〜7 で使用する確認コマンドとレビュー観点。
+
+## セクション存在確認
+
+```bash
+# Mermaid ブロックの存在確認
+grep "\`\`\`mermaid" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Mermaid diagram"
+# Context Map セクションの確認
+grep "## Context Map" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Context Map section"
+```
+
+## チェックリスト
+
+- [ ] `docs/project/domain/01-domain-model.md` に Context Map 図が含まれている
+- [ ] Mermaid 図が正しくレンダリングされる（構文エラーがない）
+- [ ] 戦略的分類に応じて色分けされている（Core / Supporting / Generic）
+- [ ] 関係パターン（Customer/Supplier など）と通信方法がエッジに記載されている
+- [ ] 必要に応じて Aggregate 図やシーケンス図が追加されている
+
+## レビュー確認質問
+
+- 「関係性は正しく表現されていますか？」
+- 「分類の色分けは適切ですか？」
+- 「複雑すぎて読みにくい箇所はありませんか？」
+- 「主要なユースケース（Command → Event）が追えますか？」
+
+## Git への追加（任意）
+
+```bash
+git add docs/project/domain/01-domain-model.md
+git status
+```
+
+推奨コミットメッセージ:
+
+```text
+docs: ドメインモデル図（Context Map）の追加
+
+- Bounded Context 間の関係を Mermaid 図で視覚化
+- 戦略的分類に基づく色分けを追加
+```

package/skills/a-006-review-requirements-domain/SKILL.md

@@ -1,144 +1,85 @@
----
-name: a-006-review-requirements-domain
-description: 要件定義からドメインモデルまでのドキュメント間の一貫性をチェックし、不整合や漏れを検出するレビューワークフロー
-auto_execution_mode: 1
----
-
-# ReviewRequirementsDomain (a-006)
-
-## 目的
-
-- ここまでに作成されたすべてのドキュメント間の一貫性を体系的にチェックする。
-- ドキュメント間の不整合、漏れ、矛盾を検出し、修正提案を提供する。
-- ユビキタス言語の遵守状況を確認し、用語の一貫性を保証する。
-- レビュー結果レポートを作成し、修正すべき項目を優先度付きでリストアップする。
-
-## 前提
-
-- 以下のドキュメントが作成されていること：
-  - `docs/project/requirements/01-system-overview.md`
-  - `docs/project/requirements/02-features-implemented.md`
-  - `docs/project/requirements/03-features-planned.md`
-  - `docs/project/requirements/04-non-functional-requirements.md`
-  - `docs/project/requirements/05-user-stories.md`
-  - `docs/project/behavior/01-scenarios.md`
-  - `docs/project/domain/01-domain-model.md`
-  - `docs/project/domain/02-ubiquitous-language.md`
-
-## 手順
-
-### 1. ドキュメント存在確認
-
-- 必要なすべてのドキュメントが存在するか確認する：
-
-  ```bash
-  ls -l docs/project/requirements/*.md docs/project/behavior/*.md docs/project/domain/*.md
-  ```
-
-- 不足しているドキュメントがある場合、対応するワークフロー（a-002, a-003, a-004）の実行を促す。
-
-### 2. 一貫性チェックの実行
-
-以下の項目について、自動検索（grep等）と手動確認を組み合わせて検証する。
-
-#### 2.1 ユーザーストーリー ↔ シナリオ
-
-- **カバレッジ**: すべてのユーザーストーリー（US-XXX）に対応するシナリオ（SC-XXX）が存在するか。
-- **整合性**: ストーリーの「価値」とシナリオの「結果」が一致しているか。
-
-#### 2.2 実装済み機能・予定機能 ↔ シナリオ
-
-- **実装済み機能**: `02-features-implemented.md` に記載の機能に、リグレッションテスト用のシナリオが存在するか。
-- **予定機能**: `03-features-planned.md` の優先度High機能にシナリオが存在するか。
-
-#### 2.3 非機能要件 ↔ ドメインモデル
-
-- **パフォーマンス**: `04-non-functional-requirements.md` の要件（読み込み速度など）に対し、Read ModelやCQRSが検討されているか。
-- **セキュリティ**: 認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
-
-#### 2.4 シナリオ ↔ ドメインモデル
-
-- **Command**: シナリオのWhen（アクション）がドメインモデルのCommandとして定義されているか。
-- **Event**: シナリオのThen（結果）がドメインモデルのDomain Eventとして定義されているか。
-- **Actor**: シナリオのActorがドメインモデルに存在するか。
-
-#### 2.5 ユビキタス言語の遵守
-
-- **用語定義**: ドメインモデルの主要要素（Aggregate, Command, Event）がユビキタス言語一覧にあるか。
-- **禁止用語**: 各ドキュメントに禁止用語（Data, Process等）が使われていないか。
-
-  ```bash
-  # 禁止用語の簡易検索（例）
-  grep -r "Data" docs/project/domain/ || echo "No 'Data' found"
-  grep -r "Process" docs/project/domain/ || echo "No 'Process' found"
-  ```
-
-#### 2.6 目的との整合性
-
-- システム概要の「目的」と、ドメインモデルの「Core Domain」が一致しているか。
-
-### 3. レビュー結果レポートの作成
-
-- 検出された問題（Error/Warning）をまとめ、`docs/project/REVIEW-REPORT.md` を作成する。
-
-**レポートフォーマット例**:
-
-```markdown
-# ドキュメント一貫性レビュー結果
-**実施日**: YYYY-MM-DD
-
-## サマリー
-- ✅ OK: X項目
-- ⚠️ Warning: X項目
-- ❌ Error: X項目
-
-## 詳細
-
-### 1. ユーザーストーリー ↔ シナリオ
-- ❌ **Error**: US-005 に対応するシナリオが見つかりません。
-- ✅ OK: 優先度Highのストーリーはすべてカバーされています。
-
-### 2. 機能要件・非機能要件
-- ⚠️ **Warning**: 実装済み機能「決済」のシナリオが不足しています。
-- ✅ OK: パフォーマンス要件に対応するRead Modelが定義されています。
-
-### 3. シナリオ ↔ ドメインモデル
-- ⚠️ **Warning**: シナリオSC-003のCommand「在庫を引き当てる」がドメインモデルに未定義です。
-
-### 4. ユビキタス言語
-- ❌ **Error**: 用語「ShippingAddress」がユビキタス言語一覧にありません。
-- ⚠️ **Warning**: 禁止用語「User Data」が `01-domain-model.md` で使用されています。
-
-## 推奨アクション
-1. `CreateScenarios` (a-003) で US-005 のシナリオを追加する。
-2. `DefineDomainModel` (a-004) で「在庫を引き当てる」コマンドを定義する。
-3. `01-domain-model.md` の「User Data」を「User Profile」に修正する。
-```
-
-### 4. 結果の報告と修正提案
-
-- ユーザーにレポートの内容を要約して伝える。
-- 重大なエラー（❌）がある場合は、優先的に修正することを提案する。
-- 「修正作業を開始しますか？それともレポートをGitに保存して終了しますか？」
-
-### 5. Git への追加（オプション）
-
-- ユーザーが希望する場合、レポートをコミットする。
-
-  ```bash
-  git add docs/project/REVIEW-REPORT--YYYYMMDDHHMMSS.md
-  git commit -m "docs: 要件・ドメイン整合性レビューレポートの作成"
-  ```
-
-## 完了条件
-
-- `docs/project/REVIEW-REPORT.md` が作成されている。
-- 全ドキュメント間の整合性がチェックされ、結果（OK/Warning/Error）が記録されている。
-- 具体的な修正アクションが提案されている。
-
-## エスカレーション
-
-- 多数のエラーが検出された場合：
-  - 「不整合が多いため、ドキュメントの信頼性が低くなっています。関係者を集めて大規模なレビュー会議を行うことを推奨します。」
-- 重要機能（Core Domain）で不整合がある場合：
-  - 「Core Domainにおける不整合はリスクが高いです。実装前に必ず解消してください。」
+---
+name: a-006-review-requirements-domain
+description: 要件定義・シナリオ・ドメインモデル間の一貫性を検証し、不整合や抜け漏れを検出する。ドメイン設計完了後、技術選定フェーズへ移る前の検査として使用。
+disable-model-invocation: true
+context: fork
+allowed-tools: Read, Grep, Glob, Write, Bash
+---
+
+# ReviewRequirementsDomain (a-006)
+
+## 目的
+
+- ここまでに作成されたすべてのドキュメント間の一貫性を体系的にチェックする。
+- ドキュメント間の不整合、漏れ、矛盾を検出し、修正提案を提供する。
+- ユビキタス言語の遵守状況を確認し、用語の一貫性を保証する。
+- レビュー結果レポートを作成し、修正すべき項目を優先度付きでリストアップする。
+
+## 前提
+
+以下のドキュメントが作成されていること:
+
+- `docs/project/requirements/01-system-overview.md` 〜 `05-user-stories.md`
+- `docs/project/behavior/01-scenarios.md`
+- `docs/project/domain/01-domain-model.md`, `02-ubiquitous-language.md`
+
+## 手順
+
+### 1. ドキュメント存在確認
+
+```bash
+ls -l docs/project/requirements/*.md docs/project/behavior/*.md docs/project/domain/*.md
+```
+
+不足があれば、対応する `/a-002`, `/a-003`, `/a-004` スキルの実行を促す。
+
+### 2. 一貫性チェックの実行
+
+以下の 6 観点を自動検索（grep 等）と手動確認で検証する。詳細な観点・コマンドは [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
+
+- **2.1 ユーザーストーリー ↔ シナリオ**: US-XXX に対応する SC-XXX の存在、価値と結果の整合
+- **2.2 実装済み/予定機能 ↔ シナリオ**: リグレッション用/優先度 High のカバレッジ
+- **2.3 非機能要件 ↔ ドメインモデル**: 性能要件（Read Model）、セキュリティ（Policy/Guard）
+- **2.4 シナリオ ↔ ドメインモデル**: Command / Event / Actor の対応
+- **2.5 ユビキタス言語**: 主要要素の登録、禁止用語の検出
+- **2.6 目的との整合性**: システム目的と Core Domain の一致
+
+### 3. レビュー結果レポートの作成
+
+検出された問題（Error / Warning / OK）をまとめ、`docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
+
+必須セクション:
+
+- サマリー（OK / Warning / Error の件数）
+- 詳細（上記 6 観点ごとの結果）
+- 推奨アクション（修正すべきタスクとスキル参照）
+
+### 4. 結果の報告と修正提案
+
+- レポート内容を要約してユーザーに伝える。
+- 重大なエラー（Error）がある場合は優先修正を提案。
+- 「修正作業を開始しますか？それともレポートを Git に保存して終了しますか？」
+
+### 5. Git への追加（任意）
+
+```bash
+git add docs/project/REVIEW-REPORT-*.md
+git commit -m "docs: 要件・ドメイン整合性レビューレポートの作成"
+```
+
+## 完了条件
+
+- `docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` が作成されている。
+- 全ドキュメント間の整合性がチェックされ、結果（OK/Warning/Error）が記録されている。
+- 具体的な修正アクションが提案されている。
+
+## エスカレーション
+
+- **多数のエラーが検出された**: 「不整合が多くドキュメント信頼性が低下しています。関係者を集めた大規模レビュー会議を推奨します。」
+- **Core Domain で不整合**: 「Core Domain における不整合はリスクが高いです。実装前に必ず解消してください。」
+- 判断材料の詳細は [reference/consistency-checks.md](reference/consistency-checks.md#エスカレーションの判断材料) を参照。
+
+## 参考
+
+- [examples/review-report-template.md](examples/review-report-template.md) — レビュー結果レポートのフォーマット例と重大度記号
+- [reference/consistency-checks.md](reference/consistency-checks.md) — 6 観点の詳細なチェック項目、grep コマンド例、エスカレーション基準