yodogawa 2.1.3 → 2.3.0

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,64 +13,112 @@ 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`）
 
 ## 手順
 
-### 1. ドキュメント存在確認
+### 1. doctor によるドキュメント健全性検査
 
 ```bash
-ls -l docs/project/01-requirements/*.md docs/project/02-behavior/*.md docs/project/03-domain/*.md
+npx -y yodogawa doctor --json
 ```
 
-不足があれば、対応する `/a-002`, `/a-003`, `/a-004` スキルの実行を促す。
+出力される JSON（`{version, ok, summary, checks[], findings[]}`）をそのまま読み込む。**この段階で `ls` や `grep` を再実装しない。** exit code 1（Error あり）は正常系であり、JSON は必ず stdout に出力される。
 
-### 2. 一貫性チェックの実行
+- `findings` のうち `check: "structure"` かつ `file` が `01-requirements/`・`02-behavior/`・`03-domain/` 配下のものを確認する。必須ファイル・見出しの欠落があれば、対応する `/a-002`, `/a-002a`, `/a-002b`, `/a-003`, `/a-004` スキルの実行を促し、手順2には進まない。
+- `04-design/` 配下に関する `structure` の finding（未着手フェーズ）はこのスキルの対象外なので無視する。
+- `id-trace` / `placeholder` の findings は手順2で観点別に振り分ける（対応表は [reference/consistency-checks.md](reference/consistency-checks.md#doctor-findings-の観点マッピング)）。
+- doctor が実行できない場合（未導入・実行失敗）のみ、代替として `ls -l docs/project/01-requirements/*.md docs/project/02-behavior/*.md docs/project/03-domain/*.md` を実行する。
 
-以下の 6 観点を自動検索（grep 等）と手動確認で検証する。詳細な観点・コマンドは [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
+### 2. 一貫性チェックの実行（観点別 PASS/FAIL + 根拠引用）
 
-- **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 の一致
+以下の 7 観点を **PASS / FAIL** で判定する（判定ルール: 観点内に Error 相当の指摘が1件以上あれば FAIL、Warning 相当のみなら PASS+注記）。詳細な観点・doctor対応関係は [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
 
-### 3. レビュー結果レポートの作成
+> **エージェントの役割範囲**
+>
+> - **doctor 対応観点**: エージェントの役割は doctor の出力（JSON）の解釈と修正提案に限定する。`ls`/`grep`/`jq` 等で同じ検査を再実装しない。
+> - **doctor 非対応観点**: エージェントの役割は「読解判断＋証拠引用」である。Read/Grep/Glob を自由に使って該当ドキュメントを確認し、判定には必ず file:line の引用を伴わせる。
 
-検出された問題（Error / Warning / OK）をまとめ、`docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
+- **2.1 ユーザーストーリー ↔ シナリオ**（一部 doctor 対応）: US-XXX に対応する SC-XXX の存在、価値と結果の整合
+- **2.2 MVP スコープ/実装済み機能 ↔ シナリオ**（doctor 対応）: Must 機能/リグレッション用のカバレッジ
+- **2.3 クリティカル制約 ↔ スコープ/ドメイン**（doctor 非対応）: Product Brief のクリティカル制約（法務・セキュリティ・期限・予算等）が MVP スコープ判断・ドメインモデルに反映されているか（初期フェーズでは定量 NFR ではなく制約を確認。詳細 NFR は a-014 の責務）
+- **2.4 Core Scenario ↔ Domain Sketch**（doctor 非対応）: アクター・中核エンティティ・重要ビジネスルールの対応（Full DDD 採用時は Command / Event / Actor の対応も）
+- **2.5 ユビキタス言語**（doctor 非対応）: 主要要素の登録、禁止用語の検出
+- **2.6 目的との整合性**（doctor 非対応）: Product Brief の価値提案と Domain Sketch の中核エンティティ（Full DDD 採用時は Core Domain）の一致、および**目的 ↔ 成功指標**の整合・成功指標の計測可能性
+- **2.7 MVP 正当化 / 過剰作り込み（YAGNI）**（大半が doctor 非対応）: 各 Must が課題/ペルソナ/指標/仮説に trace するか、Out of Scope と矛盾しないか、安い代替手段で済むものが Must になっていないか
+
+`placeholder` の finding はどの観点にも一対一対応しないため、判断材料としてのみ使う（必要なら該当観点のコメント欄に file:line 付きで補足する）。
+
+### 3. PM Gate 判定（Go / Go with caveats / No-Go）
+
+観点別 PASS/FAIL 表から次の規則で機械的に導出する（恣意的な総合判断をしない）:
+
+- **クリティカル観点**: 2.3（クリティカル制約）/ 2.4（Core Scenario↔Domain Sketch）/ 2.7（MVP正当化）
+- **No-Go**: クリティカル観点のいずれかが FAIL、または FAIL の観点数が3以上
+- **Go with caveats**: FAIL が1〜2件あるが、すべて非クリティカル観点（2.1/2.2/2.5/2.6）
+- **Go**: 全観点 PASS（コメント欄の Warning 注記は着手を妨げない）
+
+補助チェックリスト（各項目は対応する観点番号の FAIL/PASS を根拠として引用する）:
+
+- [ ] 検証する仮説が 1〜3 個に絞れている（→ 2.7）
+- [ ] すべての Must 機能が 課題 / ペルソナ / 成功指標 / 検証仮説 のいずれかに紐づいている（→ 2.7）
+- [ ] Not Now / Won't が明示され、理由が書かれている（→ 2.7）
+- [ ] 手作業・既存ツール・外部サービスで代替できるものを Must にしていない（→ 2.7）
+- [ ] ステークホルダー・決裁者・関心事が明確である（→ 2.6）
+- [ ] クリティカル制約が MVP 判断に反映されている（→ 2.3）
+- [ ] 未決事項が実装開始を妨げないレベルまで減っている（→ 全観点）
+
+### 4. レビュー結果レポートの作成
+
+観点別 PASS/FAIL の結果と PM Gate 判定をまとめ、`docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
 
 必須セクション:
 
-- サマリー（OK / Warning / Error の件数）
-- 詳細（上記 6 観点ごとの結果）
+- サマリー（観点別 PASS/FAIL の件数。doctor summary の errors/warnings を参考値として併記）
+- 詳細（7 観点ごとの PASS/FAIL・根拠(file:line引用)・コメント。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` が作成されている。
-- 全ドキュメント間の整合性がチェックされ、結果（OK/Warning/Error）が記録されている。
+- `docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` が作成され、7 観点の結果と PM Gate 判定（Go / Go with caveats / No-Go）が記録されている。
+- 全ドキュメント間の整合性がチェックされ、観点ごとの判定（PASS/FAIL）と根拠（file:line引用）が記録されている。doctor対応観点はfindingsの転記、非対応観点は読解判断＋引用になっている。
+- 各 Must 機能の MVP 正当化が検査され、trace しない機能が**過剰作り込み候補**としてフラグされている。
+- `docs/project/STAKEHOLDER-SUMMARY.md` と `docs/project/AI_CONTEXT.md` が生成され、`AI_CONTEXT.md` に「作らないもの（must NOT build）」が明記されている。
 - 具体的な修正アクションが提案されている。
 
 ## エスカレーション
@@ -81,5 +129,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) — レビュー結果レポートのフォーマット例、PASS/FAIL判定ルール、PM Gate 判定の使い方
+- [reference/consistency-checks.md](reference/consistency-checks.md) — doctor findingsの観点マッピング、7 観点（MVP 正当化/YAGNI 含む）の詳細なチェック項目、doctor非対応観点の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` のフォーマット例。
 
 ## レポートフォーマット
 
@@ -8,48 +8,63 @@ SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォー
 # ドキュメント一貫性レビュー結果
 
 **実施日**: YYYY-MM-DD
+**doctor**: `yodogawa doctor --json` 実行結果 summary = errors: 2, warnings: 3
 
 ## サマリー
 
-- OK: X 項目
-- Warning: X 項目
-- Error: X 項目
+- 観点別判定: PASS 6 / FAIL 1（全7観点）
+- PM Gate 判定: Go with caveats
 
-## 詳細
+## 詳細（観点別 PASS/FAIL）
 
-### 1. ユーザーストーリー ↔ シナリオ
+| 観点 | 判定 | 根拠（file:line） | コメント |
+|:--|:--:|:--|:--|
+| 2.1 ユーザーストーリー ↔ シナリオ | FAIL | `docs/project/01-requirements/05-user-stories.md:18`: 「ペルソナ: P-999」 | US-005 が参照する P-999 が product-brief 未定義（doctor id-trace error）。逆方向coverage・「価値」↔「Then」整合は未確認（doctor非対応部分） |
+| 2.2 MVP スコープ ↔ シナリオ | PASS | `docs/project/02-behavior/01-core-scenarios.md:40`: 「## CS-003 決済」 | 全 Must がシナリオでカバー済み（doctor id-trace: FN未参照Warningなし） |
+| 2.3 クリティカル制約 ↔ スコープ/ドメイン | PASS | `docs/project/01-requirements/01-product-brief.md:23`: 「社内SSO必須」 | MVP Scope・ドメインに反映確認済み（Read手動確認、doctor非対応） |
+| 2.4 Core Scenario ↔ Domain Sketch | PASS | `docs/project/02-behavior/01-core-scenarios.md:52`: 「在庫を引き当てる」 | Domain Sketch の重要ビジネスルールに対応記述あり（Read手動確認、doctor非対応） |
+| 2.5 ユビキタス言語 | PASS | `docs/project/03-domain/02-ubiquitous-language.md:9`: 「ShippingAddress」 | 用語登録済み。禁止用語なし（Read手動確認、doctor非対応） |
+| 2.6 目的との整合性 | PASS | `docs/project/01-requirements/01-product-brief.md:30`: 「North Star: 週次アクティブ率」 | 価値提案と成功指標は整合（Read手動確認、doctor非対応） |
+| 2.7 MVP正当化/過剰作り込み | PASS | `docs/project/01-requirements/02-mvp-scope.md:15`: 「実績バッジ→Not Now」 | 全MustがProduct Briefの課題/指標/仮説にtrace済み（Read手動確認）。注記(Warning): 孤児ペルソナ `01-product-brief.md:8` P-004 が `05-user-stories.md` から未参照（doctor id-trace warning）。過剰ペルソナの可能性、次回改訂で確認 |
 
-- **Error**: US-005 に対応するシナリオが見つかりません。
-- OK: 優先度 High のストーリーはすべてカバーされています。
+## PM Gate 判定
 
-### 2. 機能要件・非機能要件
+観点別 PASS/FAIL 表から次の規則で導出する（恣意的な総合判断をしない）。
 
-- **Warning**: 実装済み機能「決済」のシナリオが不足しています。
-- OK: パフォーマンス要件に対応する Read Model が定義されています。
+- クリティカル観点（2.3/2.4/2.7）はすべて PASS
+- FAIL は 2.1（非クリティカル）の1件のみ → 「Go with caveats」の条件（FAIL1〜2件、すべて非クリティカル）に合致
 
-### 3. シナリオ ↔ ドメインモデル
+**判定**: Go with caveats
 
-- **Warning**: シナリオ SC-003 の Command「在庫を引き当てる」がドメインモデルに未定義です。
+**根拠**: FAIL = 2.1（1件、非クリティカル）。クリティカル観点（2.3/2.4/2.7）はすべて PASS。
 
-### 4. ユビキタス言語
-
-- **Error**: 用語「ShippingAddress」がユビキタス言語一覧にありません。
-- **Warning**: 禁止用語「User Data」が `01-domain-model.md` で使用されています。
+**caveat**:
+1. 2.1: US-005 のペルソナ参照修正を条件に着手可
 
 ## 推奨アクション
 
-1. `/a-003-create-scenarios` で US-005 のシナリオを追加する。
-2. `/a-004-define-domain-model` で「在庫を引き当てる」コマンドを定義する。
-3. `01-domain-model.md` の「User Data」を「User Profile」に修正する。
+1. `docs/project/01-requirements/05-user-stories.md` の US-005 ペルソナ参照を修正する。
+2. （Warning注記）孤児ペルソナ P-004 がスコープ漏れか過剰ペルソナか、次回改訂で確認する。
 ```
 
-## 重大度記号の使い方
+## 判定ルールの使い方
+
+| 判定 | 意味 | 根拠列の要件 |
+|:--|:--|:--|
+| PASS | 観点内に Error 相当の指摘が無い | Warning相当の注記があれば file:line 付きでコメント欄に残す（消さない） |
+| FAIL | 観点内に Error 相当の指摘が1件以上 | 根拠列に file:line と該当行の引用が1件以上必須 |
+
+doctor findingsを転記する場合も、`message`をそのままコピペせず、file:lineをReadで開いて実際の行を引用する（詳細は[reference/consistency-checks.md](../reference/consistency-checks.md#doctor-findings-の観点マッピング)）。
+
+## PM Gate 判定の使い方
+
+観点別 PASS/FAIL 表からの機械的導出規則（SKILL.md 手順3参照）:
 
-| 記号 | 意味 | 対応 |
+| 判定 | 導出条件 | 次のアクション |
 |:--|:--|:--|
-| OK | 問題なし | 記録のみ |
-| Warning | 軽微な不整合 | 計画的に修正 |
-| Error | 重大な不整合 | 実装前に必ず修正 |
+| Go | 全観点 PASS | `AI_CONTEXT.md` を実装エージェントへ渡す |
+| Go with caveats | FAILが1〜2件、すべて非クリティカル観点（2.1/2.2/2.5/2.6） | caveat を明記し、合意の上で着手 |
+| No-Go | クリティカル観点（2.3/2.4/2.7）がFAIL、またはFAIL総数3以上 | 実装前に該当ドキュメントを修正し再レビュー |
 
 ## コミットメッセージ例
 

package/skills/a-006-review-requirements-domain/reference/consistency-checks.md

@@ -1,39 +1,61 @@
 # 一貫性チェック項目詳細
 
-SKILL.md 手順2 で実施する各チェック項目の詳細。自動検索（grep 等）と手動確認を組み合わせる。
+SKILL.md 手順2 で実施する各チェック項目の詳細。doctor が機械的に検出する部分は findings の転記、doctor 非対応の意味内容の判断は Read/Grep による手動確認＋file:line 引用の組み合わせで検証する。
 
-## 2.1 ユーザーストーリー ↔ シナリオ
+## doctor findings の観点マッピング
 
-- **カバレッジ**: すべての US-XXX に対応する SC-XXX が存在するか。
-- **整合性**: ストーリーの「価値」とシナリオの「結果（Then）」が一致しているか。
+`yodogawa doctor --json`（手順1）の `findings[]` は `docs/project` 配下のみを検査対象とし、`{check, severity, file, line, message}` を返す。以下の対応表に従い、該当する観点へ**そのまま転記**する（grep での再実装はしない）。file:line は Read で開いて実際の行を引用すること（message は合成文のため、原文の引用を別途添える）。
 
-```bash
-# 全ユーザーストーリーの ID 抽出
-grep -oE "US-[0-9]+" docs/project/01-requirements/05-user-stories.md | sort -u
-# シナリオ側の参照
-grep -oE "US-[0-9]+" docs/project/02-behavior/01-scenarios.md | sort -u
-```
+| doctor check | finding 条件 | severity | 対応観点 | 備考 |
+|---|---|---|---|---|
+| `id-trace` | `id` が `US-` の finding（trace切れ） | error | 2.1 | US 側の片方向 trace 切れのみ検出。逆方向（Core Scenario→US の対応漏れ）とストーリーの「価値」↔シナリオ「Then」の整合は非対応（Read で確認） |
+| `id-trace` | `id` が `P-` の finding（trace切れ） | error | 2.1（役割↔ペルソナ） | `05-user-stories.md` が参照する未定義ペルソナ |
+| `id-trace` | `id` が `P-` の finding（孤児＝`05-user-stories.md`から未参照） | warning | 2.7（傍証） | 孤児ペルソナの検出のみ。Must の trace 判断そのものの代替にはならない |
+| `id-trace` | `id` が `FN-` の finding（trace切れ） | error | 2.2 | |
+| `id-trace` | `id` が `FN-` の finding（`02-behavior/01-core-scenarios.md` から未参照） | warning | 2.2 | Must機能のシナリオカバレッジ。doctor が最も強くカバーする部分 |
+| `structure` | `file` が `01-requirements/`〜`03-domain/` 配下 | error/warning | 手順1（前提） | 観点表には含めない。存在確認・必須見出しの欠落シグナル |
+| `placeholder` | 同上 | warning | 参考情報 | どの観点にも一対一対応しない。未記入セクションの兆候として補足に使う程度 |
+
+**doctor が対応しない観点（2.3〜2.6、2.7の大半）は、上記マッピングに現れない。エージェントが Read/Grep で内容を確認し、判定には file:line の引用を必須とする。**
+
+## 2.1 ユーザーストーリー ↔ Core Scenario
+
+- **カバレッジ**: MVP Scope の Must 機能に対応する Core Scenario（Day 1 Happy Path）が存在するか。User Story は要約 AC、Core Scenario は実行時の主要行動という SSoT の住み分けを保つ（全 US を逐一シナリオ化しない）。doctor 非対応（上記マッピング表参照）。Read で `05-user-stories.md` と `02-behavior/01-core-scenarios.md` を確認する。
+- **整合性**: ストーリーの「価値」と Core Scenario の「結果（Then）」が一致しているか。doctor 非対応。
+
+### ユーザーストーリーの役割 ↔ ペルソナ（trace）
+
+- **役割が宙に浮かない**: `05-user-stories.md` の各ストーリーの「ペルソナ」列が、`01-product-brief.md` のペルソナ表で定義済みの ID（P-XXX）を参照しているか。**未定義のペルソナを参照する US はフラグ**する（役割の trace 切れ）。doctor の `id-trace`（P族 trace切れ、上記マッピング表）をそのまま転記する。
+- **逆方向（任意）**: どの US からも参照されない主要ペルソナがあれば、スコープ漏れか過剰ペルソナのどちらかとして確認する。doctor の `id-trace`（P族 孤児、severity=warning）で検出できる。
+
+## 2.2 MVP スコープ・実装済み機能 ↔ シナリオ
+
+- **MVP スコープ**: `02-mvp-scope.md` の Must 機能にシナリオが存在するか。doctor の `id-trace`（FN族、上記マッピング表）がそのまま使える。
+- **実装済み機能**: `06-features-implemented.md`（existing モード）の機能にリグレッション用シナリオが存在するか。同じく FN 族で検出される。
+- **Parking Lot**: `03-parking-lot.md` は backlog のためシナリオ必須ではない（MVP 昇格時に MVP スコープ側で扱う）。doctor 非対応（この除外判断自体は Read で確認）。
 
-## 2.2 実装済み機能・予定機能 ↔ シナリオ
+## 2.3 クリティカル制約 ↔ スコープ/ドメイン
 
-- **実装済み機能**: `02-features-implemented.md` の機能にリグレッション用シナリオが存在するか。
-- **予定機能**: `03-features-planned.md` の優先度 High 機能にシナリオが存在するか。
+初期フェーズでは定量 NFR ではなく、Product Brief の「クリティカル制約」を確認する（詳細な定量 NFR は設計フェーズ `/a-014-define-infrastructure` の責務）。**doctor 非対応。** doctor は制約の「反映」という意味内容を判断できないため、Read で確認し file:line を引用する。
 
-## 2.3 非機能要件 ↔ ドメインモデル
+- **制約の反映**: `01-product-brief.md` のクリティカル制約（法務・セキュリティ・期限・予算・外部 API 等）が `02-mvp-scope.md` の Must 判断やドメインモデルに反映されているか。
+- **セキュリティ・権限**: 制約に挙げた認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
 
-- **パフォーマンス**: `04-non-functional-requirements.md` の要件（読み込み速度、スループット等）に対し、Read Model や CQRS が検討されているか。
-- **セキュリティ**: 認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
+## 2.4 Core Scenario ↔ Domain Sketch
 
-## 2.4 シナリオ ↔ ドメインモデル
+**doctor 非対応。** Core Scenario ↔ Domain Sketch の対応関係を機械検査する ID 族は存在しない。Read で確認し file:line を引用する。
 
-- **Command**: シナリオの When（アクション）がドメインモデルの Command として定義されているか。
-- **Event**: シナリオの Then（結果）が Domain Event として定義されているか。
-- **Actor**: シナリオの Actor がドメインモデルに存在するか。
+- **アクター**: Core Scenario のアクターが Domain Sketch の「アクター / 外部システム」に存在するか。
+- **中核エンティティ**: Core Scenario が扱う対象が Domain Sketch の「中核エンティティ」に定義されているか。
+- **重要ルール**: Critical Failure を防ぐルールが「重要なビジネスルール」に反映されているか。
+- **Full DDD 採用時**: `01-domain-model.md` がある場合は、When→Command / Then→Event / Actor の対応も確認する。
 
 ## 2.5 ユビキタス言語の遵守
 
-- **用語定義**: ドメインモデルの主要要素（Aggregate, Command, Event）がユビキタス言語一覧にあるか。
-- **禁止用語**: 各ドキュメントに禁止用語（Data, Process, Manager 等）が使われていないか。
+**doctor 非対応。**
+
+- **用語定義**: Domain Sketch の主要用語・中核エンティティ（Full DDD 採用時は Aggregate / Command / Event）がユビキタス言語一覧にあるか。
+- **禁止用語**: 各ドキュメントに禁止用語（Data, Process, Manager 等）が使われていないか。**用語の意味判断は doctor では担保できないため、以下の grep は補助検索として引き続き手動実行する（doctor で代替できない）。**
 
 ```bash
 # 禁止用語の簡易検索
@@ -44,8 +66,29 @@ grep -rn "Manager" docs/project/03-domain/ || echo "No 'Manager' found"
 
 ## 2.6 目的との整合性
 
-- システム概要（`01-system-overview.md`）の「目的」とドメインモデルの「Core Domain」が一致しているか。
-- ビジネス価値の提供元が Core に寄っているか（Generic に偏っていないか）。
+**doctor 非対応。**
+
+- Product Brief（`01-product-brief.md`）の「価値提案 / 差別化」が Domain Sketch の「中核エンティティ」「重要なビジネスルール」に反映されているか。
+- **価値提案の充足**: 「価値提案 / 差別化」のバリュープロポジション（1文）と差別化ポイント（Why us）が埋まり、Why us が「現在の代替手段・競合スキャン」表の各「弱み」と対応づいているか（漠然と「使いやすい」で済ませていないか）。
+- **目的 ↔ 成功指標**: Product Brief の成功指標（North Star / KPI / Guardrail）が「価値提案 / 解く課題」と整合しているか（目的と無関係な指標を測っていないか）。
+- **計測可能性**: 各成功指標に計測方法（どこで・どう取得）が記載され、計測可能か。今すぐ取れない指標が代理指標に置き換えられているか（MVP 段階は仮説値で可）。
+- Full DDD（`01-domain-model.md`）採用時は、ビジネス価値の提供元が Core Domain に寄っているか（Generic に偏っていないか）も確認する。
+
+## 2.7 MVP 正当化 / 過剰作り込み（YAGNI / PM Gate）
+
+「要らないものを作らない」を守るためのスコープ妥当性検査。**大半が doctor 非対応。** 孤児ペルソナ（doctor `id-trace` P族 warning、上記マッピング表）は過剰作り込みの傍証になるが、Must の trace 判断そのものの代替にはならない。以下は Read で確認し file:line を引用する。
+
+- **Must の trace**: `02-mvp-scope.md` の各 Must 機能が、Product Brief の 課題 / ターゲット（ペルソナ）/ 成功指標 / 検証仮説 のいずれかに紐づくか。**いずれにも trace しない Must は過剰作り込み候補としてフラグ**する。
+- **Out of Scope の矛盾**: `02-mvp-scope.md` の Won't / Out of Scope に挙げた機能が、他ドキュメント（シナリオ・ドメインモデル・`05-user-stories.md`）で実装対象として記述されていないか。doctor では代替できないため、以下の grep は補助検索として引き続き手動実行する。
+- **安い代替手段**: 手作業・既存ツール・外部サービスで足りるものが Must になっていないか（`02-mvp-scope.md` の「より安い代替手段」列を確認）。
+- **仮説の数**: 検証する仮説が 1〜3 個に絞れているか（多すぎる＝MVP が過大）。
+
+> 成功指標と目的の整合（目的 ↔ 成功指標）・計測可能性は [2.6 目的との整合性](#26-目的との整合性)で検査する。
+
+```bash
+# Out of Scope（Won't）に挙げた機能名が他 doc に混入していないか（例）
+grep -rn "{Won't機能名}" docs/project/02-behavior/ docs/project/03-domain/
+```
 
 ## エスカレーションの判断材料
 

package/skills/a-007-define-tech-stack/SKILL.md

@@ -1,99 +1,99 @@
----
-name: a-007-define-tech-stack
-description: 要件とドメインモデルを踏まえて推奨技術スタックを提案し、対話で最終確定する。ドメイン設計完了後、実装技術を選定する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineTechStack (a-007)
-
-## 目的
-
-- 既存の要件ドキュメント（システム概要、非機能要件、ドメインモデル）を分析し、適合する技術スタックを推奨する。
-- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
-- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
-
-## 前提
-
-- `docs/project/01-requirements/` 配下のドキュメントが作成されていること。
-- `docs/project/03-domain/` 配下のドキュメントが作成されていること。
-- `docs/project/04-design/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-```bash
-ls -la docs/project/04-design/ 2>/dev/null || echo "ディレクトリが存在しません"
-```
-
-要件ドキュメント（`01-system-overview.md`, `03-features-planned.md`, `04-non-functional-requirements.md`）とドメインモデル（`01-domain-model.md`）を読み込む。
-
-### 2. テンプレートの準備
-
-このスキルの配置ディレクトリ（`skills/a-007-define-tech-stack/`）を起点に、相対パス `../../templates/project/04-design/01-tech-stack.md` を Read で読み込み、その内容を `docs/project/04-design/01-tech-stack.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
-
-### 3. 要件分析と推奨技術スタックの生成
-
-- **システム特性の分析**: アプリケーションタイプ（SPA/SSR 等）、非機能要件、ドメイン複雑度
-- **レイヤー別推奨**: フロントエンド / バックエンド / データベース / インフラ・CI/CD / 監視・テスト
-- **提示形式**: 各技術に「推奨理由」と「代替案」を付ける
-
-提案フォーマットと各層の候補一覧は [examples/stack-interview.md](examples/stack-interview.md#推奨案提示フォーマット) を参照。
-
-### 4. 詳細インタビューと選定
-
-フィードバックを受けてレイヤーごとに詳細確認する。各レイヤーの具体的な質問項目は [examples/stack-interview.md](examples/stack-interview.md#レイヤー別インタビュー項目) を参照。
-
-- フロントエンド: フレームワーク、TypeScript、状態管理、スタイリング
-- バックエンド: 言語、フレームワーク、API スタイル
-- データベース: RDBMS/NoSQL、ORM、マイグレーション
-- インフラ: クラウド、コンテナ、IaC
-- 開発ツール: リンター、テスト、CI/CD
-
-### 5. ドキュメント作成
-
-ヒアリング結果を `docs/project/04-design/01-tech-stack.md` に記入する。必須項目:
-
-- 技術名、バージョン
-- 選定理由（要件とのマッピング）
-- 選定タイミング（初期/中期/後期/随時）
-
-記入例は [examples/stack-interview.md](examples/stack-interview.md#記入例表形式) を参照。
-
-### 6. 構造チェック
-
-```bash
-grep "### フロントエンド" docs/project/04-design/01-tech-stack.md \
-  && grep "### バックエンド" docs/project/04-design/01-tech-stack.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 7. Git への追加（任意）
-
-```bash
-git add docs/project/04-design/01-tech-stack.md
-git commit -m "docs: 技術スタック選定ドキュメントの作成"
-```
-
-詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
-
-## 完了条件
-
-- `docs/project/04-design/01-tech-stack.md` が作成されている。
-- すべてのレイヤーについて技術選定が完了している（または「保留」として記録されている）。
-- 選定理由とバージョンが明確になっている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **ユーザーが決められない**: 「要件に基づき、最も標準的でリスクの少ない [技術名] を仮採用とし、実装フェーズで再評価しませんか？」
-- **コスト・学習コストの懸念**: 「初期フェーズは慣れた技術（[技術名]）を採用し、複雑要件が出てから移行検討しましょう。」
-- 詳細応答例は [reference/structure-check.md](reference/structure-check.md#エスカレーション時の推奨応答) を参照。
-
-## 参考
-
-- [examples/stack-interview.md](examples/stack-interview.md) — 推奨案フォーマット、レイヤー別インタビュー項目、選定タイミング区分、記入例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例
+---
+name: a-007-define-tech-stack
+description: 要件とドメインモデルを踏まえて推奨技術スタックを提案し、対話で最終確定する。ドメイン設計完了後、実装技術を選定する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineTechStack (a-007)
+
+## 目的
+
+- 既存の要件ドキュメント（Product Brief（クリティカル制約含む）、ドメインモデル）を分析し、適合する技術スタックを推奨する。
+- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
+- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
+
+## 前提
+
+- `docs/project/01-requirements/` 配下のドキュメントが作成されていること。
+- `docs/project/03-domain/` 配下のドキュメントが作成されていること。
+- `docs/project/04-design/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+```bash
+ls -la docs/project/04-design/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+要件ドキュメント（`01-product-brief.md`（クリティカル制約含む）, `02-mvp-scope.md`）とドメイン（`01-domain-sketch.md`、Full DDD 採用時は `01-domain-model.md`）を読み込む。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-007-define-tech-stack/`）を起点に、相対パス `../../templates/project/04-design/01-tech-stack.md` を Read で読み込み、その内容を `docs/project/04-design/01-tech-stack.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
+
+### 3. 要件分析と推奨技術スタックの生成
+
+- **システム特性の分析**: アプリケーションタイプ（SPA/SSR 等）、クリティカル制約（NFR の要点）、ドメイン複雑度
+- **レイヤー別推奨**: フロントエンド / バックエンド / データベース / インフラ・CI/CD / 監視・テスト
+- **提示形式**: 各技術に「推奨理由」と「代替案」を付ける
+
+提案フォーマットと各層の候補一覧は [examples/stack-interview.md](examples/stack-interview.md#推奨案提示フォーマット) を参照。
+
+### 4. 詳細インタビューと選定
+
+フィードバックを受けてレイヤーごとに詳細確認する。各レイヤーの具体的な質問項目は [examples/stack-interview.md](examples/stack-interview.md#レイヤー別インタビュー項目) を参照。
+
+- フロントエンド: フレームワーク、TypeScript、状態管理、スタイリング
+- バックエンド: 言語、フレームワーク、API スタイル
+- データベース: RDBMS/NoSQL、ORM、マイグレーション
+- インフラ: クラウド、コンテナ、IaC
+- 開発ツール: リンター、テスト、CI/CD
+
+### 5. ドキュメント作成
+
+ヒアリング結果を `docs/project/04-design/01-tech-stack.md` に記入する。必須項目:
+
+- 技術名、バージョン
+- 選定理由（要件とのマッピング）
+- 選定タイミング（初期/中期/後期/随時）
+
+記入例は [examples/stack-interview.md](examples/stack-interview.md#記入例表形式) を参照。
+
+### 6. 構造チェック
+
+```bash
+grep "### フロントエンド" docs/project/04-design/01-tech-stack.md \
+  && grep "### バックエンド" docs/project/04-design/01-tech-stack.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/project/04-design/01-tech-stack.md
+git commit -m "docs: 技術スタック選定ドキュメントの作成"
+```
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
+
+## 完了条件
+
+- `docs/project/04-design/01-tech-stack.md` が作成されている。
+- すべてのレイヤーについて技術選定が完了している（または「保留」として記録されている）。
+- 選定理由とバージョンが明確になっている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **ユーザーが決められない**: 「要件に基づき、最も標準的でリスクの少ない [技術名] を仮採用とし、実装フェーズで再評価しませんか？」
+- **コスト・学習コストの懸念**: 「初期フェーズは慣れた技術（[技術名]）を採用し、複雑要件が出てから移行検討しましょう。」
+- 詳細応答例は [reference/structure-check.md](reference/structure-check.md#エスカレーション時の推奨応答) を参照。
+
+## 参考
+
+- [examples/stack-interview.md](examples/stack-interview.md) — 推奨案フォーマット、レイヤー別インタビュー項目、選定タイミング区分、記入例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例