yodogawa 2.1.1 → 2.2.0

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

@@ -5,27 +5,30 @@ SKILL.md 手順6〜7 で使う構造確認コマンドとレビュー観点。
 ## セクション存在確認
 
 ```bash
-# シナリオ一覧テーブルの確認
-grep "| シナリオID | 機能 |" docs/project/02-behavior/01-scenarios.md && echo "OK" || echo "MISSING: Table Header"
-# Feature 定義の確認
-grep "Feature:" docs/project/02-behavior/01-scenarios.md && echo "OK" || echo "MISSING: Feature definition"
-# Scenario 定義の確認
-grep "Scenario:" docs/project/02-behavior/01-scenarios.md && echo "OK" || echo "MISSING: Scenario definition"
+# Core Flow 一覧の確認
+grep "## Core Flow 一覧" docs/project/02-behavior/01-core-scenarios.md && echo "OK" || echo "MISSING: Core Flow"
+# Day 1 Happy Path の確認
+grep "## Day 1 Happy Path" docs/project/02-behavior/01-core-scenarios.md && echo "OK" || echo "MISSING: Happy Path"
+# Critical Failure の確認
+grep "## Critical Failure" docs/project/02-behavior/01-core-scenarios.md && echo "OK" || echo "MISSING: Critical Failure"
+# Not Covered in MVP の確認
+grep "## Not Covered in MVP" docs/project/02-behavior/01-core-scenarios.md && echo "OK" || echo "MISSING: Not Covered"
 ```
 
 ## チェックリスト
 
-- [ ] `docs/project/02-behavior/01-scenarios.md` が作成されている
-- [ ] シナリオ一覧テーブルが更新されている
-- [ ] 各 Feature が Gherkin 形式で記述されている
-- [ ] 正常系と異常系のシナリオが網羅されている
-- [ ] Empty State や境界値も考慮されている
-- [ ] タグ（@SC-XXX, @smoke 等）が付与されている
+- [ ] `docs/project/02-behavior/01-core-scenarios.md` が作成されている
+- [ ] 対象が MVP Scope の Must 機能に絞られている（Not Now / Won't を扱っていない）
+- [ ] Day 1 Happy Path が 1〜3 本に固定されている
+- [ ] Critical Failure が「価値を壊す重大失敗」に限定されている（網羅していない）
+- [ ] Not Covered in MVP が明示され、`02-mvp-scope.md` の Not Now / Won't と整合している
+- [ ] User Story（要約 AC）と Core Scenario（実行時主要行動）が二重化していない
 
 ## レビュー確認質問
 
-- 「シナリオは実際の動作を正しく表現していますか？」
-- 「漏れているケース（エラー、境界値）はありませんか？」
+- 「Day 1 の成功体験を正しく表現していますか？」
+- 「価値を壊す Critical Failure に漏れはありませんか？（法務・課金・権限・データ消失）」
+- 「Not Covered in MVP は MVP Scope の Not Now / Won't と矛盾していませんか？」
 - 「非技術者でも理解できる表現になっていますか？」
 - 「UI 操作に依存せず、ユーザーの意図を表現できていますか？」
 
@@ -39,8 +42,8 @@ git status
 推奨コミットメッセージ:
 
 ```text
-docs: 振る舞い仕様（シナリオ）の作成
+docs: Core Scenarios（MVP 主要行動）の作成
 
-- ユーザーストーリーに基づく Gherkin シナリオを追加
-- 正常系・異常系・境界値ケースを定義
+- Must 機能の Day 1 Happy Path と Critical Failure を定義
+- Not Covered in MVP を明示
 ```

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

@@ -1,6 +1,6 @@
 ---
 name: a-004-define-domain-model
-description: Event Storming 形式でドメインモデル（イベント・コマンド・集約）を定義し、ユビキタス言語を整備する。シナリオ作成後、ドメイン設計を開始する際に使用。
+description: Core Scenarios と MVP Scope から軽量な Domain Sketch（主要用語・境界・中核エンティティ・重要ルール）を定義し、ユビキタス言語を整備する。完全な Event Storming は任意（a-005）。シナリオ作成後、ドメイン理解を素早く固定する際に使用。
 disable-model-invocation: true
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ---
@@ -9,69 +9,76 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ## 目的
 
-- Event Storming 形式でドメインモデルを体系的に定義する。
-- ドメインモデルを作成しながら、ユビキタス言語（共通用語）を並行して洗練させる。
-- Bounded Context を特定し、Actors / Commands / Events / Policies / Aggregates を明確化する。
+- Core Scenarios と MVP Scope から、AI が責務混在を起こさない程度の軽量な Domain Sketch を定義する。
+- 主要な業務概念・システム境界・中核エンティティ・重要なビジネスルール・MVP で作らない範囲を素早く固定する。
+- 並行してユビキタス言語（共通用語）を洗練させる。
+- 完全な Event Storming（Bounded Context / Aggregate / Context Map）は標準では作らない。複雑ドメインで必要なら任意スキル `/a-005-create-domain-diagram`（advanced）に委ねる。
 
 ## 前提
 
-- `docs/project/02-behavior/01-scenarios.md` が作成されている（`/a-003-create-scenarios` 実行済み）
-- `docs/project/03-domain/` ディレクトリが存在（なければ `/a-001-setup-doc-structure`）
-- ドメインエキスパートと協力できる
+- `docs/project/02-behavior/01-core-scenarios.md` が作成されている（`/a-003-create-scenarios` 実行済み）
+- `docs/project/01-requirements/02-mvp-scope.md` が作成されている（Must 機能・Not Now / Won't）
+- `docs/project/03-domain/` ディレクトリが存在（なければ本スキルが作成する）
 
 ## 手順
 
-### 1. ディレクトリと前提条件の確認
+### 1. 前提ドキュメントの確認
 
 ```bash
 ls -la docs/project/03-domain/ 2>/dev/null || echo "ディレクトリが存在しません"
 ```
 
-存在しなければ `/a-001-setup-doc-structure` を促す。`docs/project/02-behavior/01-scenarios.md` を読み込み内容確認。
+`02-behavior/01-core-scenarios.md`（Core Flow / Critical Failure）と `02-mvp-scope.md`（Must / Not Now / Won't）を読み込み、ドメインの主要概念と境界を把握する。
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/03-domain/01-domain-model.md" "docs/project/03-domain/01-domain-model.md"
-cp "$SCRIPT_DIR/templates/project/03-domain/02-ubiquitous-language.md" "docs/project/03-domain/02-ubiquitous-language.md"
-```
+このスキルの配置ディレクトリ（`skills/a-004-define-domain-model/`）を起点に、`docs/project/03-domain/` へ次の 2 ファイルを Read→Write する（FOR EACH）。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/03-domain/`）が無ければ作成する。
 
-### 3. Bounded Context の特定
+- `../../templates/project/03-domain/01-domain-sketch.md` → `docs/project/03-domain/01-domain-sketch.md`
+- `../../templates/project/03-domain/02-ubiquitous-language.md` → `docs/project/03-domain/02-ubiquitous-language.md`
 
-シナリオとユーザーストーリーから Bounded Context を提案し、戦略的分類（Core / Supporting / Generic）を確認。詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#bounded-context-の特定) を参照。
+### 3. 主要概念と境界の抽出
 
-### 4. 各 Bounded Context のドメインモデル定義
+Core Scenarios と MVP Scope から以下を提案し、`01-domain-sketch.md` を更新する。観点は [reference/event-storming-guide.md](reference/event-storming-guide.md) を参照。
 
-各 Context について以下を定義し、`01-domain-model.md` を更新。新しい用語が登場するたびに `02-ubiquitous-language.md` にも追記。
+- **主要用語（10〜20 個）**: 頻出する業務用語。曖昧語（Data / Process / Manager）は避ける。
+- **アクター / 外部システム / システム境界**: 誰が使い、何と連携し、MVP で作る範囲はどこか。
+- **中核エンティティと責務**: MVP の中核エンティティと 1 行責務（属性網羅は不要）。
 
-- 概要とアクター
-- コマンド / イベント / ポリシー（Event Storming）
-- 集約 / Read Models / External Systems
+### 4. ルール・状態・作らない範囲の記入
 
-各要素の詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#各-context-の定義項目) を参照。
+- **重要なビジネスルール**: 守らないと価値・正しさが崩れるルールだけ。Core Scenarios の Critical Failure と整合させる。
+- **状態遷移（任意）**: 明確なライフサイクルがあるエンティティのみ。
+- **MVP では作らないドメイン範囲**: `02-mvp-scope.md` の Not Now / Won't と整合させる。
+- 新しい用語が登場したら `02-ubiquitous-language.md` にも追記する。
 
-### 5. ユビキタス言語の洗練
+### 5. 簡易ドメイン図の作成（任意）
 
-`02-ubiquitous-language.md` を見直し、重複・曖昧さ・禁止用語を排除。観点は [reference/event-storming-guide.md](reference/event-storming-guide.md#ユビキタス言語の洗練観点) を参照。
+必要に応じて、アクター・システム境界・外部システムを示す簡易 Mermaid 図を 1 枚だけ `01-domain-sketch.md` の「簡易ドメイン図」へ追加する。複雑な Context Map / Aggregate 図が必要なら `/a-005-create-domain-diagram`（advanced）に委ねる。
 
-### 6. Context Map の定義
+### 6. ユビキタス言語の洗練
 
-Context 間の関係性（Customer-Supplier, Shared Kernel 等）を Mermaid 図で定義。関係パターン: [reference/event-storming-guide.md](reference/event-storming-guide.md#context-map-の関係性)
+`02-ubiquitous-language.md` を見直し、重複・曖昧さ・禁止用語を排除。観点は [reference/event-storming-guide.md](reference/event-storming-guide.md#ユビキタス言語の洗練観点) を参照。
 
 ### 7. レビューと確認
 
-作成したドキュメントを提示し、ビジネス用語の正確性 / Aggregate 境界 / ユビキタス言語定義を確認。
+作成したドキュメントを提示し、(1) 主要概念・境界が Core Scenarios と一致するか、(2) 重要ルールが Critical Failure を防げるか、(3) 作らない範囲が MVP Scope と矛盾しないかを確認する。
 
 ### 8. 完了条件と構造の確認
 
-構造確認コマンドは [reference/event-storming-guide.md](reference/event-storming-guide.md#構造確認コマンド) を参照。
+```bash
+grep "## 中核エンティティと責務" docs/project/03-domain/01-domain-sketch.md \
+  && grep "## 重要なビジネスルール" docs/project/03-domain/01-domain-sketch.md \
+  && grep "| 用語 | 定義 |" docs/project/03-domain/02-ubiquitous-language.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
 
 チェックリスト:
 
-- [ ] `01-domain-model.md` に主要な Event Storming 要素が含まれている
+- [ ] `01-domain-sketch.md` に主要用語・境界・中核エンティティ・重要ルールが含まれている
+- [ ] MVP で作らないドメイン範囲が明示されている
 - [ ] `02-ubiquitous-language.md` の用語が定義されている
-- [ ] ドメインモデルとユビキタス言語の整合性が取れている
+- [ ] Domain Sketch とユビキタス言語の整合性が取れている
 
 ### 9. Git への追加（オプション）
 
@@ -84,16 +91,17 @@ git status
 
 ## 完了条件
 
-- `docs/project/03-domain/01-domain-model.md` と `02-ubiquitous-language.md` が作成されている
-- 各 Bounded Context の主要ドメイン要素（Aggregates, Commands, Events）が定義されている
-- ドメインモデルで使用される用語がユビキタス言語として定義されている
+- `docs/project/03-domain/01-domain-sketch.md` と `02-ubiquitous-language.md` が作成されている
+- 主要用語・システム境界・中核エンティティ・重要なビジネスルール・MVP で作らない範囲が定義されている
+- ドメインで使用される用語がユビキタス言語として定義されている
 - ユーザーが内容を承認している
 
 ## エスカレーション
 
-- **シナリオが不足**: 「`/a-003-create-scenarios` に戻ってシナリオを充実させましょう。」
-- **Bounded Context の境界が不明確**: 「暫定的な境界を設定し、実装を進めながら見直す方針で進めませんか？」
+- **Core Scenarios が不足**: 「`/a-003-create-scenarios` に戻って Core Scenarios を充実させましょう。」
+- **ドメインが複雑で軽量スケッチに収まらない**: 「複雑な Bounded Context / Aggregate / Context Map が必要なら、任意スキル `/a-005-create-domain-diagram`（advanced）で Full DDD を作成しましょう。」
 
 ## 参考
 
-- [reference/event-storming-guide.md](reference/event-storming-guide.md) — Event Storming の観点、Context Map パターン、構造確認コマンド
+- [reference/event-storming-guide.md](reference/event-storming-guide.md) — ドメイン概念抽出の観点、（advanced）Event Storming / Context Map パターン、構造確認コマンド
+- [reference/ubiquitous-language-guide.md](reference/ubiquitous-language-guide.md) — ユビキタス言語の記載ポイント・禁止用語の選び方・Living Document 運用（手順6）

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

@@ -1,10 +1,12 @@
 # Event Storming ガイド
 
-SKILL.md 手順3〜6で使うドメインモデル定義の観点集。
+ドメイン概念抽出の観点集。a-004（Domain Sketch）の手順3・4 では主要概念・境界・中核エンティティ・重要ルールの抽出に使う。
+
+> 以下の **Bounded Context / コマンドとイベント / 集約とモデル / Context Map の関係性** は完全な Event Storming の観点であり、標準フローでは必須ではない。複雑ドメインで Full DDD が必要なときに、任意スキル `/a-005-create-domain-diagram`（advanced）と `01-domain-model.md` で用いる。a-004 の Domain Sketch では、これらを軽量に（中核エンティティ・境界の把握に必要な範囲で）参照する。
 
 ## Bounded Context の特定
 
-シナリオとユーザーストーリーを分析し、ビジネス領域を特定。
+Core Scenarios と MVP Scope を分析し、ビジネス領域を特定。
 
 - **戦略的分類**:
   - **Core**: ビジネスの中核的な競争優位を生む領域
@@ -43,6 +45,19 @@ SKILL.md 手順3〜6で使うドメインモデル定義の観点集。
 - **Anticorruption Layer**: 外部モデルの変換層
 - **Conformist**: 上流に従う
 - **Partnership**: 相互協調
+- **Open Host Service**: API 経由で公開
+- **Published Language**: 共通のデータフォーマットで連携
+- **Separate Ways**: 連携しない（独立）
+
+## Full DDD テンプレート（01-domain-model.md）の補足
+
+任意スキル `/a-005-create-domain-diagram` で `01-domain-model.md` を埋めるときの追加メモ。
+
+- **付箋の色（Event Storming 表記）**: Actors=小さな黄 / Commands=青 / Domain Events=オレンジ / Policies=紫(ライラック) / Aggregates=大きな黄 / Read Models=緑 / External Systems=ピンク。
+- **Commands / Events**: Command は動詞・命令形（`RegisterUser`）で必ず Domain Event をトリガーする。Event は過去形（`UserRegistered`）でビジネス上意味のある出来事を表し、技術イベント（「DB 保存」）は書かない。
+- **Aggregates**: トランザクション境界＝一貫性の保証範囲。1 Aggregate は 1 ルートエンティティを持ち、コマンドを受けてルールを適用しイベントを発行する。他 Aggregate とは疎結合でイベント経由で連携する。
+- **Read Models（CQRS）**: Command（書き込み）と Query（読み込み）を分離し、UI のニーズに合わせた読み取り専用モデルをイベントから構築する。複数 Aggregate を集約する場合もある。
+- **External Systems**: 外部システムとの境界には Anticorruption Layer（腐敗防止層）の要否を検討し、外部障害がこの Context に与える影響を考慮する。
 
 ## レビュー観点
 
@@ -52,20 +67,31 @@ SKILL.md 手順3〜6で使うドメインモデル定義の観点集。
 
 ## 構造確認コマンド
 
+標準フロー（Domain Sketch）:
+
+```bash
+grep "## 中核エンティティと責務" docs/project/03-domain/01-domain-sketch.md \
+  && echo "OK" || echo "MISSING: 中核エンティティ"
+grep "## 重要なビジネスルール" docs/project/03-domain/01-domain-sketch.md \
+  && echo "OK" || echo "MISSING: 重要なビジネスルール"
+grep "| 用語 | 定義 |" docs/project/03-domain/02-ubiquitous-language.md \
+  && echo "OK" || echo "MISSING: Terminology table"
+```
+
+advanced（Full Event Storming / a-005 実行時の `01-domain-model.md`）:
+
 ```bash
 grep "Bounded Context:" docs/project/03-domain/01-domain-model.md \
   && echo "OK" || echo "MISSING: Bounded Context definition"
 grep "### Aggregates" docs/project/03-domain/01-domain-model.md \
   && echo "OK" || echo "MISSING: Aggregates section"
-grep "| 用語 | 定義 |" docs/project/03-domain/02-ubiquitous-language.md \
-  && echo "OK" || echo "MISSING: Terminology table"
 ```
 
 ## Git コミットメッセージ
 
 ```
-docs: ドメインモデルとユビキタス言語の定義
+docs: Domain Sketch とユビキタス言語の定義
 
-- Event Stormingによるドメインモデルの作成
-- Bounded Contextごとのユビキタス言語の整備
+- Core Scenarios からの主要概念・境界・中核エンティティの整理
+- ユビキタス言語の整備
 ```

package/skills/a-004-define-domain-model/reference/ubiquitous-language-guide.md

@@ -0,0 +1,49 @@
+# ユビキタス言語 整備ガイド
+
+`02-ubiquitous-language.md` を書くときの原則・記載のポイント・運用方法。テンプレートは用語表を中心に保ち、
+詳しい考え方が必要なときに本ガイドを参照する。Event Storming 全体の観点は
+[event-storming-guide.md](event-storming-guide.md) を参照。
+
+## ユビキタス言語とは
+
+プロジェクト全体で共有される共通言語の定義集。Domain-Driven Design の中核概念で、ビジネス用語と技術用語の橋渡しをする。
+
+- **目的**: 開発者とドメインエキスパートの共通理解構築 / 用語の曖昧さ排除 / コード・ドキュメント・会話で一貫した用語使用 / 新メンバーのオンボーディング支援。
+- すべてのコミュニケーション（コード・会話・ドキュメント）で同じ言葉を使う。
+- **Bounded Context ごとに定義される**（同じ用語でも Context が異なれば意味が異なる場合がある）。`[Bounded Context 共通]` セクションを設けて全体共通の用語を記すのも有効。
+
+## 用語の記載ポイント
+
+| 列 | 書き方 |
+|---|---|
+| 用語 | ドメインエキスパートが使う正式な用語。単複を明確に（Order / Orders）。日本語は表記ゆれ注意（「ユーザ」か「ユーザー」か統一）。略語は避けフルスペル。 |
+| 定義 | 1〜3 文で明確に。その Context 内での意味を正確に。実装詳細ではなくビジネス的意味を、エキスパートと合意した形で書く。 |
+| 使用例 | コード例（クラス名・メソッド名・変数名）/ ドキュメント例 / 会話例。複数あれば箇条書き。 |
+
+- ドメインエキスパートが使う言葉を優先し、技術用語ではなくビジネス用語で記述する。
+- クラス名・メソッド名・変数名にも反映する。
+- 動詞（Order = 注文する, Ship = 出荷する）や状態遷移に関わる語（Pending, Confirmed, Shipped）も含める。
+- 類似用語の違いを明確にする（例: Customer vs User）。
+
+## 禁止用語
+
+使用を避けるべき曖昧・誤解を招く用語を記録する。目的は用語の混乱防止、新メンバーへの注意喚起、コードレビューのチェックリスト。
+
+記載すべき用語: 複数の意味を持つ曖昧な語 / 技術用語とビジネス用語が混在する語 / 過去に混乱を招いた語 / Context により意味が変わる語 / 意味が不明瞭な略語。
+
+各エントリには **なぜ禁止か** と **代替となる明確な用語** を必ず添える。
+
+## Living Document として運用する
+
+ドメイン理解が深まるにつれ継続的に更新する。
+
+- ドメインモデリング時に初版作成。Event Storming やレビュー時に追加・修正。混乱や不一致が見つかったら即更新。
+- Git で変更履歴を追跡し、チーム全員がアクセスできる場所（Wiki / Confluence 等）に置く。
+- 用語変更はコード全体への影響が大きいため慎重に。変更時はリファクタリングタスクを作成する。
+- 用語の進化を歓迎する（ドメイン理解が深まった証）。図やダイアグラムを併用すると理解が深まる。
+
+## コード・コミュニケーションとの整合
+
+- コードレビュー時に本ドキュメントを参照する。可能なら CI/CD で用語の lint チェックを自動化する。
+- ドメインエキスパートとの会話・仕様書でも必ずこの用語を使う。
+- 命名規則（クラス/メソッド/変数）・表記規則（単複・大文字小文字）・言語選択（英/日）のルールを「メモ」に明記する。

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

@@ -1,40 +1,38 @@
 ---
 name: a-005-create-domain-diagram
-description: ドメインモデルを Mermaid 図（Context Map・Aggregate 構造）として可視化する。ドメインモデル定義後、関係性を図で確認する際に使用。
+description: （任意 / advanced）Domain Sketch を完全な Event Storming（Bounded Context・Aggregate・Context Map）へ拡張し、Mermaid 図で可視化する。複雑なドメインで Full DDD が必要なときに使用。標準の MVP フローには含まれない。
 disable-model-invocation: true
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ---
 
 # CreateDomainDiagram (a-005)
 
+> ⚠️ これは**任意 / advanced スキル**。標準の MVP フローには含まれない。a-004 の軽量な Domain Sketch（`01-domain-sketch.md`）で十分なドメインでは実行不要。Bounded Context が複数に分かれる、集約境界の検討が必要、Context 間連携が複雑、といった場合にのみ使う。
+
 ## 目的
 
-- ドメインモデルドキュメント（`01-domain-model.md`）を基に、視覚的なダイアグラムを作成する。
-- Context Map（Bounded Context 間の関係図）を Mermaid 形式で図示する。
-- 各 Bounded Context 内の Aggregate 構造や関係性を図示する（オプション）。
+- 軽量な Domain Sketch（`01-domain-sketch.md`）を入力に、完全な Event Storming 形式のドメインモデル（`01-domain-model.md`）へ拡張する。
+- Bounded Context・Commands・Events・Policies・Aggregates・Read Models・External Systems を体系的に整理する。
+- Context Map（Bounded Context 間の関係図）と Aggregate 構造を Mermaid 形式で図示する。
 
 ## 前提
 
-- `docs/project/03-domain/01-domain-model.md` が作成されていること（`/a-004-define-domain-model` 実行済み）。
-- ドメインモデルドキュメントに Bounded Context の一覧と関係性が記述されていること。
+- `docs/project/03-domain/01-domain-sketch.md` が作成されていること（`/a-004-define-domain-model` 実行済み）。
+- ドメインが複雑で、軽量な Domain Sketch だけでは設計判断が難しいこと（そうでなければ本スキルは不要）。
 
 ## 手順
 
 ### 1. ドキュメントの確認
 
 ```bash
-ls -la docs/project/03-domain/01-domain-model.md 2>/dev/null || echo "ファイルが存在しません"
+ls -la docs/project/03-domain/01-domain-sketch.md 2>/dev/null || echo "Domain Sketch が存在しません"
 ```
 
-未作成の場合、`/a-004-define-domain-model` の実行を促す。
-
-### 2. Context Map の情報収集と提案
+未作成の場合、`/a-004-define-domain-model` の実行を促す。`01-domain-sketch.md` を読み込み、主要概念・境界・中核エンティティを把握する。
 
-`docs/project/03-domain/01-domain-model.md` から以下を抽出し、構成案を提示する:
+### 2. Full DDD テンプレートの準備
 
-- Bounded Context のリスト
-- 戦略的分類（Core / Supporting / Generic）
-- Context 間の関係性と通信方法
+このスキルの配置ディレクトリ（`skills/a-005-create-domain-diagram/`）を起点に、相対パス `../../templates/project/03-domain/01-domain-model.md` を Read で読み込み、その内容を `docs/project/03-domain/01-domain-model.md` へ Write する（冪等。既存ならスキップして報告する）。Domain Sketch の内容を起点に、Bounded Context・Commands・Events・Policies・Aggregates・Read Models・External Systems を埋める。
 
 ### 3. Context Map 図の作成
 
@@ -70,14 +68,14 @@ grep "\`\`\`mermaid" docs/project/03-domain/01-domain-model.md \
 
 ```bash
 git add docs/project/03-domain/01-domain-model.md
-git commit -m "docs: ドメインモデル図（Context Map）の追加"
+git commit -m "docs: Full DDD ドメインモデル・Context Map 図の作成"
 ```
 
 詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
 
 ## 完了条件
 
-- `docs/project/03-domain/01-domain-model.md` に Context Map 図が追加されている。
+- `docs/project/03-domain/01-domain-model.md` が Full Event Storming 形式で作成され、Context Map 図が追加されている。
 - Bounded Context 間の関係性が正しく表現されている。
 - 戦略的分類が視覚的に区別されている。
 - オプションの詳細図（Aggregate 図、シーケンス図）が必要に応じて追加されている。
@@ -85,10 +83,13 @@ git commit -m "docs: ドメインモデル図（Context Map）の追加"
 
 ## エスカレーション
 
-- **ドメインモデルが不完全で図を作成できない**: 「`/a-004-define-domain-model` に戻って定義を補完しましょう。」
+- **Domain Sketch が不完全で拡張できない**: 「`/a-004-define-domain-model` に戻って Domain Sketch を補完しましょう。」
+- **そもそも Full DDD が過剰**: 「MVP 段階では Domain Sketch で十分なことが多いです。本スキルは複雑ドメインに限って使いましょう。」
 - **図が複雑すぎて読みにくい**: 「主要な関係のみに絞るか、図を分割することを検討しましょう。」
 
 ## 参考
 
 - [examples/mermaid-templates.md](examples/mermaid-templates.md) — Context Map / Aggregate / シーケンス図の Mermaid テンプレート、スタイル定義、エッジラベル例
 - [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例
+- [../a-004-define-domain-model/reference/event-storming-guide.md](../a-004-define-domain-model/reference/event-storming-guide.md) — Actors / Commands / Events / Policies / Aggregates / Context Map パターンなど各要素の意味・付箋の色・CQRS / ACL の解説
+- [../../templates/project/03-domain/01-domain-model.md](../../templates/project/03-domain/01-domain-model.md) — Full Event Storming（advanced）テンプレート

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

@@ -1,6 +1,6 @@
 ---
 name: a-006-review-requirements-domain
-description: 要件定義・シナリオ・ドメインモデル間の一貫性を検証し、不整合や抜け漏れを検出する。ドメイン設計完了後、技術選定フェーズへ移る前の検査として使用。
+description: 要件定義・シナリオ・ドメインモデル間の一貫性を検証し、さらに MVP 正当化（過剰作り込み検査）と Go / Go with caveats / No-Go の PM Gate 判定を行う。ステークホルダー向け要約（STAKEHOLDER-SUMMARY.md）と AI 実装用コンテキスト（AI_CONTEXT.md）を生成する。ドメイン設計完了後、技術選定・実装フェーズへ移る前の関門として使用。
 disable-model-invocation: true
 context: fork
 allowed-tools: Read, Grep, Glob, Write, Bash
@@ -13,15 +13,18 @@ allowed-tools: Read, Grep, Glob, Write, Bash
 - ここまでに作成されたすべてのドキュメント間の一貫性を体系的にチェックする。
 - ドキュメント間の不整合、漏れ、矛盾を検出し、修正提案を提供する。
 - ユビキタス言語の遵守状況を確認し、用語の一貫性を保証する。
+- MVP として過剰でないか（YAGNI / 過剰作り込み）を検査し、各 Must 機能の正当性を確認する。
+- **PM Gate** として実装着手の Go / Go with caveats / No-Go を判定する。
+- ステークホルダー合意用の要約（`STAKEHOLDER-SUMMARY.md`）と AI 実装用の圧縮コンテキスト（`AI_CONTEXT.md`）を生成する。
 - レビュー結果レポートを作成し、修正すべき項目を優先度付きでリストアップする。
 
 ## 前提
 
 以下のドキュメントが作成されていること:
 
-- `docs/project/01-requirements/01-system-overview.md` 〜 `05-user-stories.md`
-- `docs/project/02-behavior/01-scenarios.md`
-- `docs/project/03-domain/01-domain-model.md`, `02-ubiquitous-language.md`
+- `docs/project/01-requirements/` の各ドキュメント（`01-product-brief.md`, `02-mvp-scope.md`, `03-parking-lot.md`, `05-user-stories.md`、existing モードは加えて `06-features-implemented.md`）
+- `docs/project/02-behavior/01-core-scenarios.md`
+- `docs/project/03-domain/01-domain-sketch.md`, `02-ubiquitous-language.md`（Full DDD を採用した場合は加えて `01-domain-model.md`）
 
 ## 手順
 
@@ -31,46 +34,78 @@ allowed-tools: Read, Grep, Glob, Write, Bash
 ls -l docs/project/01-requirements/*.md docs/project/02-behavior/*.md docs/project/03-domain/*.md
 ```
 
-不足があれば、対応する `/a-002`, `/a-003`, `/a-004` スキルの実行を促す。
+不足があれば、対応する `/a-002`, `/a-002a`, `/a-002b`, `/a-003`, `/a-004` スキルの実行を促す。
 
 ### 2. 一貫性チェックの実行
 
-以下の 6 観点を自動検索（grep 等）と手動確認で検証する。詳細な観点・コマンドは [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
+以下の 7 観点を自動検索（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.2 MVP スコープ/実装済み機能 ↔ シナリオ**: Must 機能/リグレッション用のカバレッジ
+- **2.3 クリティカル制約 ↔ スコープ/ドメイン**: Product Brief のクリティカル制約（法務・セキュリティ・期限・予算等）が MVP スコープ判断・ドメインモデルに反映されているか（初期フェーズでは定量 NFR ではなく制約を確認。詳細 NFR は a-014 の責務）
+- **2.4 Core Scenario ↔ Domain Sketch**: アクター・中核エンティティ・重要ビジネスルールの対応（Full DDD 採用時は Command / Event / Actor の対応も）
 - **2.5 ユビキタス言語**: 主要要素の登録、禁止用語の検出
-- **2.6 目的との整合性**: システム目的と Core Domain の一致
+- **2.6 目的との整合性**: Product Brief の価値提案と Domain Sketch の中核エンティティ（Full DDD 採用時は Core Domain）の一致、および**目的 ↔ 成功指標**の整合・成功指標の計測可能性
+- **2.7 MVP 正当化 / 過剰作り込み（YAGNI）**: 各 Must が課題/ペルソナ/指標/仮説に trace するか、Out of Scope と矛盾しないか、安い代替手段で済むものが Must になっていないか
 
-### 3. レビュー結果レポートの作成
+### 3. PM Gate 判定（Go / Go with caveats / No-Go）
 
-検出された問題（Error / Warning / OK）をまとめ、`docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
+一貫性チェック（特に 2.7 の MVP 正当化）の結果をもとに、実装着手の可否を判定する。次のチェックリストで評価する:
+
+- [ ] 検証する仮説が 1〜3 個に絞れている
+- [ ] すべての Must 機能が 課題 / ペルソナ / 成功指標 / 検証仮説 のいずれかに紐づいている
+- [ ] Not Now / Won't が明示され、理由が書かれている
+- [ ] 手作業・既存ツール・外部サービスで代替できるものを Must にしていない
+- [ ] ステークホルダー・決裁者・関心事が明確である
+- [ ] クリティカル制約が MVP 判断に反映されている
+- [ ] 未決事項が実装開始を妨げないレベルまで減っている
+
+判定:
+
+- **Go**: 上記をおおむね満たし、重大な Error が無い。
+- **Go with caveats**: 着手可だが条件あり（caveat を明記する）。
+- **No-Go**: 重大な Error / 過剰作り込み / 未決があり、実装前に解消が必要。
+
+### 4. レビュー結果レポートの作成
+
+検出された問題（Error / Warning / OK）と PM Gate 判定をまとめ、`docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
 
 必須セクション:
 
 - サマリー（OK / Warning / Error の件数）
-- 詳細（上記 6 観点ごとの結果）
+- 詳細（上記 7 観点ごとの結果。2.7 では**過剰作り込み候補**を明示）
+- PM Gate 判定（Go / Go with caveats / No-Go と根拠）
 - 推奨アクション（修正すべきタスクとスキル参照）
 
-### 4. 結果の報告と修正提案
+### 5. ステークホルダー要約 / AI コンテキストの生成
+
+このスキルの配置ディレクトリ（`skills/a-006-review-requirements-domain/`）を起点に、次の 2 テンプレートを Read→Write で生成する。出力先が既に存在する場合は確認の上、最新内容で更新する。
+
+- `../../templates/project/STAKEHOLDER-SUMMARY.md` → `docs/project/STAKEHOLDER-SUMMARY.md`
+- `../../templates/project/AI_CONTEXT.md` → `docs/project/AI_CONTEXT.md`
+
+上流ドキュメント（`01-product-brief.md` / `02-mvp-scope.md` / `02-behavior/01-core-scenarios.md` / `03-domain/`）を**要約・参照**して各テンプレートを埋める（single source of truth を複製しない）。`AI_CONTEXT.md` には **MVP must NOT build**（Won't / Out of Scope）を必ず明記する。`STAKEHOLDER-SUMMARY.md` には手順3の PM Gate 判定を転記する。
+
+### 6. 結果の報告と修正提案
 
-- レポート内容を要約してユーザーに伝える。
-- 重大なエラー（Error）がある場合は優先修正を提案。
+- レポートと PM Gate 判定を要約してユーザーに伝える。
+- 重大なエラー（Error）や No-Go がある場合は優先修正を提案。
+- Go / Go with caveats の場合は「`docs/project/AI_CONTEXT.md` を実装エージェント（Vibe coding / AI 実装）へ渡してください」と案内する。
 - 「修正作業を開始しますか？それともレポートを Git に保存して終了しますか？」
 
-### 5. Git への追加（任意）
+### 7. Git への追加（任意）
 
 ```bash
-git add docs/project/REVIEW-REPORT-*.md
-git commit -m "docs: 要件・ドメイン整合性レビューレポートの作成"
+git add docs/project/REVIEW-REPORT-*.md docs/project/STAKEHOLDER-SUMMARY.md docs/project/AI_CONTEXT.md
+git commit -m "docs: PM Gate レビュー（要約・AI コンテキスト含む）の作成"
 ```
 
 ## 完了条件
 
-- `docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` が作成されている。
+- `docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` が作成され、7 観点の結果と PM Gate 判定（Go / Go with caveats / No-Go）が記録されている。
 - 全ドキュメント間の整合性がチェックされ、結果（OK/Warning/Error）が記録されている。
+- 各 Must 機能の MVP 正当化が検査され、trace しない機能が**過剰作り込み候補**としてフラグされている。
+- `docs/project/STAKEHOLDER-SUMMARY.md` と `docs/project/AI_CONTEXT.md` が生成され、`AI_CONTEXT.md` に「作らないもの（must NOT build）」が明記されている。
 - 具体的な修正アクションが提案されている。
 
 ## エスカレーション
@@ -81,5 +116,7 @@ git commit -m "docs: 要件・ドメイン整合性レビューレポートの
 
 ## 参考
 
-- [examples/review-report-template.md](examples/review-report-template.md) — レビュー結果レポートのフォーマット例と重大度記号
-- [reference/consistency-checks.md](reference/consistency-checks.md) — 6 観点の詳細なチェック項目、grep コマンド例、エスカレーション基準
+- [examples/review-report-template.md](examples/review-report-template.md) — レビュー結果レポートのフォーマット例、重大度記号、PM Gate 判定の使い方
+- [reference/consistency-checks.md](reference/consistency-checks.md) — 7 観点（MVP 正当化/YAGNI 含む）の詳細なチェック項目、grep コマンド例、エスカレーション基準
+- [../../templates/project/STAKEHOLDER-SUMMARY.md](../../templates/project/STAKEHOLDER-SUMMARY.md) — ステークホルダー向け統合1枚もののテンプレート
+- [../../templates/project/AI_CONTEXT.md](../../templates/project/AI_CONTEXT.md) — AI 実装用の圧縮コンテキストのテンプレート

package/skills/a-006-review-requirements-domain/examples/review-report-template.md

@@ -1,6 +1,6 @@
 # レビュー結果レポートテンプレート
 
-SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォーマット例。
+SKILL.md 手順4 で作成する `docs/project/REVIEW-REPORT-*.md` のフォーマット例。
 
 ## レポートフォーマット
 
@@ -22,10 +22,10 @@ SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォー
 - **Error**: US-005 に対応するシナリオが見つかりません。
 - OK: 優先度 High のストーリーはすべてカバーされています。
 
-### 2. 機能要件・非機能要件
+### 2. MVP スコープ・クリティカル制約
 
 - **Warning**: 実装済み機能「決済」のシナリオが不足しています。
-- OK: パフォーマンス要件に対応する Read Model が定義されています。
+- OK: Product Brief のクリティカル制約「社内 SSO 必須」が MVP スコープ・ドメインに反映されています。
 
 ### 3. シナリオ ↔ ドメインモデル
 
@@ -34,13 +34,25 @@ SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォー
 ### 4. ユビキタス言語
 
 - **Error**: 用語「ShippingAddress」がユビキタス言語一覧にありません。
-- **Warning**: 禁止用語「User Data」が `01-domain-model.md` で使用されています。
+- **Warning**: 禁止用語「User Data」が `01-domain-sketch.md` で使用されています。
+
+### 5. MVP 正当化 / 過剰作り込み（YAGNI）
+
+- **過剰作り込み候補**: Must 機能「実績バッジ」が課題・ペルソナ・成功指標のいずれにも trace しません。Not Now / Won't への変更を検討してください。
+- OK: その他の Must はすべて検証仮説・成功指標に紐づいています。
+- OK: Out of Scope（Won't）と矛盾する実装記述はありません。
+
+## PM Gate 判定
+
+**判定**: Go with caveats
+
+**根拠**: 整合性は良好。ただし Must「実績バッジ」が正当化されていないため、スコープから外すことを条件に実装着手可。
 
 ## 推奨アクション
 
-1. `/a-003-create-scenarios` で US-005 のシナリオを追加する。
-2. `/a-004-define-domain-model` で「在庫を引き当てる」コマンドを定義する。
-3. `01-domain-model.md` の「User Data」を「User Profile」に修正する。
+1. `02-mvp-scope.md` の「実績バッジ」を Won't に変更する（過剰作り込み）。
+2. `/a-003-create-scenarios` で US-005 のシナリオを追加する。
+3. `01-domain-sketch.md` の「User Data」を「User Profile」に修正する。
 ```
 
 ## 重大度記号の使い方
@@ -51,6 +63,14 @@ SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォー
 | Warning | 軽微な不整合 | 計画的に修正 |
 | Error | 重大な不整合 | 実装前に必ず修正 |
 
+## PM Gate 判定の使い方
+
+| 判定 | 意味 | 次のアクション |
+|:--|:--|:--|
+| Go | 実装着手してよい | `AI_CONTEXT.md` を実装エージェントへ渡す |
+| Go with caveats | 条件付きで着手可 | caveat を明記し、合意の上で着手 |
+| No-Go | 重大課題あり | 実装前に該当ドキュメントを修正し再レビュー |
+
 ## コミットメッセージ例
 
 ```text