yodogawa 2.1.3 → 2.2.0

package/skills/a-002-initialize-project/SKILL.md

@@ -1,118 +1,145 @@
----
-name: a-002-initialize-project
-description: プロジェクトの要件を対話形式で収集し、システム概要・機能要件・非機能要件・ユーザーストーリーのドキュメントを生成する。新規プロジェクト開始時、または要件が未整備の場合に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# InitializeProject (a-002)
-
-## 目的
-
-- プロジェクトの目的・背景・機能要件を詳細にヒアリングし、具体的で実装可能なドキュメントを作成する。
-- システム概要・実装済み機能・予定機能・非機能要件・ユーザーストーリーを網羅する。
-- 抽象的・曖昧な表現を避け、対話を通じて具体的な数値・期限・制約・優先度を明確化する。
-
-## 前提
-
-- `docs/project/01-requirements/` ディレクトリが存在すること（なければ先に `/a-001-setup-doc-structure` を実行）
-- `docs/` に書き込み権限があること
-- ユーザーがプロジェクト概要と主要機能の基本情報を提供できること
-
-## 手順
-
-### 1. ドキュメントディレクトリの確認
-
-```bash
-ls -la docs/project/01-requirements/ 2>/dev/null || echo "ディレクトリが存在しません"
-```
-
-存在しない場合: 「`docs/project/01-requirements/` がありません。先に `/a-001-setup-doc-structure` を実行してください。」
-
-### 2. テンプレート一括コピー
-
-このスキルの配置ディレクトリ（`skills/a-002-initialize-project/`）を起点に、`docs/project/01-requirements/` へ次の 5 ファイルを Read→Write する（FOR EACH）。出力先に既に存在するファイルは上書きせずスキップして報告する（冪等）。出力先ディレクトリが無ければ作成する。
-
-- `../../templates/project/01-requirements/01-system-overview.md` → `docs/project/01-requirements/01-system-overview.md`
-- `../../templates/project/01-requirements/02-features-implemented.md` → `docs/project/01-requirements/02-features-implemented.md`
-- `../../templates/project/01-requirements/03-features-planned.md` → `docs/project/01-requirements/03-features-planned.md`
-- `../../templates/project/01-requirements/04-non-functional-requirements.md` → `docs/project/01-requirements/04-non-functional-requirements.md`
-- `../../templates/project/01-requirements/05-user-stories.md` → `docs/project/01-requirements/05-user-stories.md`
-
-### 3. コードベースの自動分析と提案
-
-**規模確認**:
-
-```bash
-ls -F
-```
-
-ファイルがほとんど無い／ソースコードが無い場合はスキップし、ユーザーへ通知。
-
-**詳細調査**（コードがある場合）:
-
-```bash
-cat package.json 2>/dev/null
-cat README.md 2>/dev/null
-find src app lib -maxdepth 2 2>/dev/null
-```
-
-結果から以下を推測・提示: システム概要（目的・技術スタック）、実装済み機能（ファイル構造からの推測）、想定ユーザー像。
-
-### 4. システム概要の記入
-
-`01-system-overview.md` を開き、「背景」「目的」をヒアリングして記入する。質問例は [reference/hearing-questions.md](reference/hearing-questions.md) を参照。
-
-### 5. 実装済み機能一覧の記入
-
-`02-features-implemented.md` に、コードベース調査で検出したディレクトリ/ファイル名から機能を提案し、ヒアリング結果をテーブルに記入する（Category 1/2、機能名、説明、機能 ID）。
-
-コード調査コマンドとヒアリング項目は [reference/hearing-questions.md](reference/hearing-questions.md#手順4-実装済み機能一覧) を参照。
-
-### 6. 予定機能一覧の記入
-
-`03-features-planned.md` に、システム概要と実装済み機能のギャップを分析して未実装機能を提案し、ヒアリング結果をテーブルに記入する（機能 ID・優先度は未確定のまま）。
-
-### 7. 非機能要件の記入
-
-`04-non-functional-requirements.md` に、詳細定義が必要か確認の上、パフォーマンス/セキュリティ/可用性/スケーラビリティ/ユーザビリティ・保守性の観点で**定量的な目標**をヒアリングして記入する。不要なら標準ベースライン（[examples/nfr-baseline.md](examples/nfr-baseline.md)）で仮置きする。
-
-### 8. ユーザーストーリーの記入
-
-`05-user-stories.md` に、作成済みドキュメントから主要ユーザージャーニーを抽出してストーリー案を提示し、ヒアリング結果をテーブルに記入する（優先度・受け入れ基準含む）。
-
-ストーリーテンプレート: 「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
-
-### 9. 全体レビュー
-
-- 作成した全ドキュメントをユーザーに提示し、以下を確認:
-  - 「記載内容に誤りや漏れはありませんか？」
-  - 「抽象的すぎる記述や、解釈が分かれそうな表現はありますか？」
-  - 「テンプレートのコメントや不要な例示は適切に処理されていますか？」
-
-### 10. 完了条件と構造の確認
-
-- ファイルの存在と主要セクション/テーブル構造を検証。
-- 検証コマンド・チェックリスト・Git コミット手順は [reference/structure-check.md](reference/structure-check.md) を参照。
-
-### 11. Git への追加（オプション）
-
-詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加オプション) を参照。
-
-## 完了条件
-
-- `docs/project/01-requirements/` に 5 つの要件定義ドキュメントが作成されている
-- すべてのドキュメントで抽象的表現が最小化され、具体的な数値・期限・制約が記載されている
-- ユーザーがドキュメント内容を確認し、承認またはフィードバックを提供している
-
-## エスカレーション
-
-- **ユーザーが重要な情報を提供できない**: 「この情報は後続の設計・実装で必須です。確認できる担当者や資料はありますか？」と確認し、TODO として記録。
-- **競合する要件や矛盾**: 「以下の要件が競合しています: [詳細]。優先順位や調整方針を確認させてください。」と報告。
-- **想定工数が非現実的に大きい**: 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案。
-
-## 参考
-
-- [reference/hearing-questions.md](reference/hearing-questions.md) — 手順4〜8のヒアリング質問集
-- [reference/structure-check.md](reference/structure-check.md) — 手順10の構造チェックコマンドと Git コミット手順
-- [examples/nfr-baseline.md](examples/nfr-baseline.md) — 非機能要件の標準ベースライン提案値
+---
+name: a-002-initialize-project
+description: プロジェクトの問題定義(Why)を Product Brief（誰のどの課題を・なぜ今・どう解き・どう成功を測るか）として対話形式で作成し、要件定義の起点とする。MVP スコープ・ユーザーストーリーは後続スキルが担う。新規（greenfield）/ 既存（existing）の2モードに対応し、既定は新規。新規プロジェクト開始時、または要件が未整備の場合に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# InitializeProject (a-002)
+
+## 目的
+
+- Product Brief を中核に、誰のどの課題を・なぜ今・どう解き・どう成功を測るかをステークホルダーと合意できる形で言語化する。
+- 新規（greenfield）/ 既存（existing）の2モードに分岐し、既定は新規プロダクト。
+- Product Brief を起点に後続スキルへ展開する: Parking Lot（アイデア backlog）と MVP スコープは `/a-002a-slice-mvp-scope`、ユーザーストーリーは `/a-002b-define-user-stories` が担う（実装済み機能の棚卸しは existing モードのみ本スキルが扱う）。
+- 詳細な非機能要件（応答時間・稼働率・スケーラビリティ等の定量値）は初期フェーズでは扱わない。MVP の作り方を変えるほど重要な制約のみを Product Brief の「クリティカル制約」に集約し、定量 NFR は設計フェーズ `/a-014-define-infrastructure` が所有する。
+- 抽象的・曖昧な表現を避け、対話を通じて具体的な数値・期限・制約・優先度を明確化する。
+
+## 前提
+
+- `docs/` 配下への書き込み権限があること（必要なディレクトリ構造は本スキルが自動作成するため、`/a-001-setup-doc-structure` の事前実行は不要）
+- ユーザーがプロジェクトの課題・対象ユーザー・期待価値の基本情報を提供できること
+
+## 手順
+
+### 1. ドキュメント基盤の確保
+
+要件定義に必要なディレクトリ構造を確保する。`mkdir -p` なので冪等で、明示的な `/a-001-setup-doc-structure` 実行は不要（必要時に本手順が自動で初期化する）。
+
+```bash
+mkdir -p docs/project/01-requirements docs/project/02-behavior docs/project/03-domain docs/project/04-design docs/tasks
+```
+
+`docs/README.md` が無ければ、[../a-001-setup-doc-structure/reference/directory-structure.md](../a-001-setup-doc-structure/reference/directory-structure.md#docsreadmemd-テンプレート) の「docs/README.md テンプレート」を Write する（既存の場合は上書きしない）。
+
+### 2. モード判定（greenfield / existing）
+
+このスキルは新規プロダクト（**greenfield**）と既存プロダクト（**existing / brownfield**）の2モードに対応する。後続手順（テンプレート選定・コード分析・実装済み機能の棚卸し）の分岐に影響するため、最初にモードを確定する。
+
+判定ロジック:
+
+- ユーザーがモードを明示した場合はそれを優先する。
+- 明示がない場合は、軽量シグナルから推定する。
+
+  ```bash
+  ls -F
+  cat package.json 2>/dev/null
+  cat README.md 2>/dev/null
+  find src app lib -maxdepth 2 2>/dev/null
+  ```
+
+  - ソースコード・`package.json`・既存ドキュメントが揃い相応の規模があれば **existing** を候補にする。
+  - ファイルがほとんど無い／ソースコードが無い場合は **greenfield** を候補にする。
+- 推定が曖昧な場合の**既定は greenfield**（Yodogawa の主目的は新規プロダクトの仕様駆動立ち上げのため）。
+- 「このプロジェクトを greenfield（新規）/ existing（既存）として進めます。よろしいですか？」とユーザーに提示し、確認を取る。
+
+確定したモードを以降の手順で参照する。
+
+### 3. テンプレートのコピー（モード別）
+
+このスキルの配置ディレクトリ（`skills/a-002-initialize-project/`）を起点に、`docs/project/01-requirements/` へテンプレートを Read→Write する（FOR EACH）。出力先に既に存在するファイルは上書きせずスキップして報告する（冪等）。出力先ディレクトリが無ければ作成する。
+
+**existing モード**（2 ファイル）:
+
+- `../../templates/project/01-requirements/01-product-brief.md` → `docs/project/01-requirements/01-product-brief.md`
+- `../../templates/project/01-requirements/06-features-implemented.md` → `docs/project/01-requirements/06-features-implemented.md`
+
+**greenfield モード**（必須 1 ファイル）: `01-product-brief.md` のみ。新規プロダクトでは実装済み機能がまだ存在しないため、`06-features-implemented.md` は**任意**扱いとし、ユーザーが棚卸しを希望した場合のみ「空の任意資料」としてコピーする。
+
+> `03-parking-lot.md` / `02-mvp-scope.md` は本スキルでは生成しない。次スキル `/a-002a-slice-mvp-scope` が作成する。
+> `05-user-stories.md` は `/a-002b-define-user-stories` が作成する。
+>
+> `04-non-functional-requirements.md`（詳細な定量 NFR）は初期フェーズでは生成しない。クリティカル制約は Product Brief（手順5）に集約し、詳細 NFR は設計フェーズ `/a-014-define-infrastructure` が扱う（採番上 04 は欠番）。
+
+### 4. コードベースの自動分析と提案（existing モードのみ）
+
+> greenfield モードではこの手順をスキップする。
+
+**詳細調査**:
+
+```bash
+cat package.json 2>/dev/null
+cat README.md 2>/dev/null
+find src app lib -maxdepth 2 2>/dev/null
+```
+
+結果から以下を推測・提示: Product Brief の下書き（課題・目的・技術スタック）、実装済み機能（ファイル構造からの推測）、想定ユーザー像。
+
+### 5. Product Brief の記入（中核）
+
+`01-product-brief.md` を開き、深掘りヒアリングで埋める。**これがこのスキルの中核成果物**で、後続スキル（MVP Scope / Core Scenarios / PM Gate）が参照する。
+
+- 記入対象: 背景/解く課題（証拠・規模つき）、ターゲットユーザー / 主要ペルソナ、ステークホルダー、現在の代替手段・競合スキャン、価値提案/差別化、Why now、成功指標（North Star / KPI / Guardrail ＋計測方法）、クリティカル制約、非ゴール、未確定事項。
+- **ペルソナ表**: 主要 1〜2 ペルソナを ID（P-XXX）付きで記入する（ゴール / 課題・ペイン / 利用文脈、任意でニーズの強さ）。この ID は後続の User Story（`/a-002b`）が「役割」を参照解決する SSoT になるため、過剰にせず・空欄にせず埋める。
+- **代替手段・競合スキャン**: 主要な数件（2〜4 件）を表で軽量にスキャンする（手作業/Workaround・既製ツール・競合プロダクト）。各代替の「弱み・不満」が価値提案の起点になる。網羅・深追いはしない（YAGNI）。
+- **価値提案 / 差別化**: バリュープロポジションを1文（誰の・どの課題を・どう解き・なぜ既存より良いか）に凝縮し、差別化ポイント（Why us、最大3点）をスキャン表の「弱み」と対応づける。
+- 「課題 → なぜ → なぜ」と3段以上掘り下げ、表層の要望ではなく本質的な課題に到達する。
+- 「この課題を作らずに放置したら何が起きるか」「既存の代替手段で十分ではないか」を必ず確認する。
+
+質問例は [reference/hearing-questions.md](reference/hearing-questions.md#手順5-product-brief) を参照。
+
+### 6. 実装済み機能一覧の記入（existing モードのみ）
+
+> greenfield モードではこの手順をスキップする（`06-features-implemented.md` は任意の空資料）。
+
+`06-features-implemented.md` に、コードベース調査で検出したディレクトリ/ファイル名から機能を提案し、ヒアリング結果をテーブルに記入する（Category 1/2、機能名、説明、機能 ID）。
+
+コード調査コマンドとヒアリング項目は [reference/hearing-questions.md](reference/hearing-questions.md#手順6-実装済み機能一覧) を参照。
+
+### 7. 全体レビュー
+
+- 作成した全ドキュメントをユーザーに提示し、以下を確認:
+  - 「記載内容に誤りや漏れはありませんか？」
+  - 「抽象的すぎる記述や、解釈が分かれそうな表現はありますか？」
+  - 「テンプレートのコメントや不要な例示は適切に処理されていますか？」
+
+### 8. 完了条件と構造の確認
+
+- ファイルの存在と主要セクション/テーブル構造を検証。
+- 検証コマンド・チェックリスト・Git コミット手順は [reference/structure-check.md](reference/structure-check.md) を参照。
+
+### 9. Git への追加（オプション）
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加オプション) を参照。
+
+## 完了条件
+
+- `docs/project/01-requirements/01-product-brief.md` が作成され、課題・ターゲット・代替手段・価値提案・Why now・成功指標・クリティカル制約・非ゴールが具体的に埋まっている（**中核成果物**）
+- あわせて要件定義ドキュメントが作成されている
+  - existing モード: `01`, `06` の 2 ドキュメント
+  - greenfield モード: `01`。`06-features-implemented.md` は任意
+  - `04`（詳細 NFR）は初期フェーズでは生成しない（設計フェーズ `/a-014` が所有）
+- Parking Lot（`03-parking-lot.md`）・MVP スコープ（`02-mvp-scope.md`）は次スキル `/a-002a-slice-mvp-scope` で、ユーザーストーリー（`05-user-stories.md`）は `/a-002b-define-user-stories` で作成する
+- すべてのドキュメントで抽象的表現が最小化され、具体的な数値・期限・制約が記載されている
+- ユーザーがドキュメント内容を確認し、承認またはフィードバックを提供している
+
+## エスカレーション
+
+- **ユーザーが重要な情報を提供できない**: 「この情報は後続の設計・実装で必須です。確認できる担当者や資料はありますか？」と確認し、TODO として記録。
+- **競合する要件や矛盾**: 「以下の要件が競合しています: [詳細]。優先順位や調整方針を確認させてください。」と報告。
+- **想定工数が非現実的に大きい**: 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案。
+
+## 参考
+
+- [reference/hearing-questions.md](reference/hearing-questions.md) — Product Brief（手順5）・実装済み機能（手順6）のヒアリング質問集。末尾に深掘りフレーム集（5 Whys / Pre-mortem / 代替手段・競合 / Day 1 MVP / 検証仮説 / Inversion）。深掘りフレーム集は `/a-002a-slice-mvp-scope` からも参照される
+- [reference/structure-check.md](reference/structure-check.md) — 手順8の構造チェックコマンドと Git コミット手順（手順9）

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

@@ -1,23 +1,65 @@
 # ヒアリング質問集
 
-SKILL.md 手順3〜7で各テンプレートに記入する際のヒアリング質問一覧。
+a-002 の各テンプレートに記入する際のヒアリング質問一覧。Product Brief（問題定義/Why）を中核に、existing モードの実装済み機能をカバーする。Parking Lot / ユーザーストーリーの質問は後続スキル（`/a-002a-slice-mvp-scope` / `/a-002b-define-user-stories`）が扱う。
 
-## 手順3: システム概要
+末尾の「[深掘りフレーム集](#深掘りフレーム集product-brief--mvp-scope-共通)」は Product Brief（a-002）と MVP Scope（`/a-002a-slice-mvp-scope`）の両方で使える思考技法。表層の要望で止めず、根本課題・失敗要因・最小スコープまで掘り下げるために併用する。
 
-### 背景
+## 手順5: Product Brief
 
-- 「このシステムで解決しようとしている**具体的な問題や課題**は何ですか？」
-- 「その問題はなぜ重要ですか？放置した場合のリスクは？」
-- 「問題の影響を受けるステークホルダー（ユーザー、組織、チームなど）は誰ですか？」
-- 「具体的な数値やデータ（作業時間、コスト、離脱率など）があれば教えてください。」
+`01-product-brief.md` の各節を埋めるための質問。表層の要望ではなく**本質的な課題**に到達することを重視する。
 
-### 目的
+### 背景 / 解く課題（Why-chain で深掘り）
 
-- 「このシステムが提供する**具体的な価値や解決策**は何ですか？」
-- 「期待される成果や変化を、測定可能な形で表現できますか？（例: 作業時間 50%削減）」
-- 「どのように問題を解決するか、具体的なメカニズムや仕組みを教えてください。」
+- 「このプロダクトで解決したい**具体的な課題**は何ですか？（誰が・いつ・どこで困っていますか）」
+- 「それはなぜ問題なのですか？」→ さらに「ではなぜそれが起きるのですか？」と**3段以上 Why を繰り返す**（5 Whys）。表層の要望の裏にある根本課題を特定する。
+- 「その課題の**証拠・規模**はありますか？（発生頻度、所要時間、コスト、影響人数などの具体的な数値）」
+- 「この課題を**解かずに放置したら何が起きますか？**（Cost of Inaction）」
 
-## 手順4: 実装済み機能一覧
+### ターゲットユーザー / ペルソナ
+
+> 主要 1〜2 ペルソナを ID（P-XXX）付きで `01-product-brief.md` のペルソナ表に記入する。この ID は後続の User Story（/a-002b）が「役割」を参照解決する SSoT になる。MVP では過剰な人物像づくりはしない（YAGNI）。
+
+- 「主に**誰のため**のプロダクトですか？1〜2の主要ペルソナに絞るとどうなりますか？」
+- 「そのユーザーが片付けたい**仕事（Job / ゴール）**は何ですか？どんな状況で発生しますか？」
+- 「そのペルソナが今抱えている**主な課題・ペイン**は何ですか？」
+- 「**いつ・どこで・どんな状況**で使いますか？（利用文脈: タイミング・デバイス・頻度）」
+- 「（任意）その課題の**切実さ**はどの程度ですか？（高/中/低。MVP の優先順位判断に使う）」
+
+### ステークホルダー / 決裁者
+
+- 「この施策の**意思決定者（決裁者）**は誰ですか？」
+- 「**影響を受ける関係者**は誰で、それぞれ何を気にしますか？（コスト、運用、セキュリティ等）」
+
+### 現在の代替手段・競合スキャン
+
+> 主要な数件（2〜4 件）を `01-product-brief.md` の「現在の代替手段・競合スキャン」表に記入する。網羅・深追いはしない（YAGNI）。
+
+- 「今この課題を**どうしのいでいますか？**（手作業、既存ツール、外部サービス、我慢）」
+- 「同じ課題を解く**競合・類似プロダクト**はありますか？（数件で可）」
+- 各代替について「それが**今も使われている理由（強み）**は？」「**何が不十分・不満（弱み）**ですか？」を問い、表の各行を埋める。
+- 「代替手段で十分なら、本当に作る必要がありますか？」（→ 不要なら MVP Scope で Must にしない）
+
+### 価値提案 / 差別化 / Why now
+
+- 「このプロダクトの価値を**1文**で言うと？」→ 「**[誰]** の **[課題]** を **[解決方法]** で解決する。**[代替手段]** と違い **[なぜ良いか]**」の穴埋めで凝縮する（バリュープロポジション）。
+- 「上のスキャン表の各『弱み』に対し、**我々は何で勝ちますか（Why us）？**」→ 差別化ポイントを最大3点、代替手段の弱みと対応づけて挙げる。
+- 「**なぜ今**作るのですか？（市場・組織・技術・コストの変化）」
+
+### 成功指標（North Star / KPI / Guardrail）
+
+- 「成功を**1つの指標（North Star）**で表すと何ですか？目標値は？」
+- 「補助的に追う **KPI** は何ですか？それは**先行指標**（行動の早期シグナル）ですか、**遅行指標**（成果の確定値）ですか？」
+- 「**悪化させてはいけない指標（Guardrail ＝失敗の許容ライン）**は？（例: 苦情件数、離脱率）」
+- 「各指標は**どこで・どう計測**しますか？（取得元・自動/手動・頻度）。今すぐ取れない場合、**代理指標**で測れますか？」
+
+### クリティカル制約 / 非ゴール
+
+- 「守らないと成立しない**制約**は何ですか？（法規制、セキュリティ、予算、期限、既存連携）」
+- 「このプロダクトが**明示的に目指さないこと（非ゴール）**は何ですか？スコープ外はどこですか？」
+
+## 手順6: 実装済み機能一覧
+
+> existing モードのみ。greenfield モードでは実装済み機能が存在しないため、この手順全体をスキップする。
 
 ### コード調査のヒントと提案
 
@@ -40,53 +82,61 @@ find . -type f -name "*Controller*" -o -name "*Service*" -o -name "*Component*"
   - **説明**（何ができるか）
   - **機能 ID**（FN-XXX 形式、連番）
 
-## 手順5: 予定機能一覧
+## 詳細な非機能要件について
 
-### 差分分析からの提案例
+初期フェーズでは、定量的な非機能要件（応答時間・稼働率・スケーラビリティ等）の詳細ヒアリングは行わない。MVP の作り方を変えるほど重要な制約のみを Product Brief の「クリティカル制約」に記載する（手順5 の「クリティカル制約 / 非ゴール」を参照）。詳細 NFR は設計フェーズ `/a-014-define-infrastructure` で扱う。
 
-- 「システム概要で『〇〇機能』への言及がありましたが、まだ実装されていないようです。予定機能に追加しますか？」
-- 「現在の実装に『××』が含まれていますが、関連する『△△機能』は将来的に必要ですか？」
+## 深掘りフレーム集（Product Brief / MVP Scope 共通）
 
-### ヒアリング項目
+表層の要望をそのまま機能化しないための思考技法。Product Brief（a-002）で課題・価値を掘り下げるとき、
+および MVP Scope（`/a-002a-slice-mvp-scope`）で「本当に作るべきか」を判定するときに併用する。
 
-- **Category 1** / **Category 2**
-- **機能名**（アイデア段階でも可）
-- **説明**（目的や価値を中心に）
+### 5 Whys（最低3段）
 
-※ 機能 ID・優先度はこの段階では確定させず、柔軟性を重視して記載しない。
+根本課題に到達するため「なぜ？」を最低3段繰り返す。
 
-## 手順6: 非機能要件
+- 「なぜそれが問題なのですか？」→「ではなぜそれが起きるのですか？」→ さらに「その背景にある原因は？」
+- 表層の要望（解決策）と、その裏の根本課題（問題）を分けて記録する。
+- 止め時: 「それ以上 why を遡っても自社で手を打てない」レベルまで来たら 1 つ上に戻る。
 
-### パフォーマンス
+### Pre-mortem（事前検死）
 
-- 「ページ読み込み時間の目標は？」
-- 「API レスポンス時間の目標は？」
-- 「想定される同時接続ユーザー数、データ量は？」
+リリース前に「すでに失敗した」と仮定し、原因を先回りで洗い出す。
 
-### セキュリティ
+- 「1年後、このプロダクトが**失敗に終わった**と想像してください。最も可能性の高い失敗原因は何ですか？」
+- 「Day 1 で誰も使わなかったとしたら、理由は？（価値が伝わらない / 既存手段で足りる / 使うのが面倒 等）」
+- 出てきた失敗要因を、Critical 制約・Core Scenarios の Critical Failure・Guardrail 指標に反映する。
 
-- 「認証方式、機密データの扱い、コンプライアンス要件は？」
+### より安い代替手段 / 競合分析
 
-### 可用性・信頼性
+「そもそも作らない」「もっと安く検証する」判断のため、既存手段と競合を必ず問う。
 
-- 「稼働率目標、許容ダウンタイム、バックアップ要件は？」
+- 「今この課題を**どうしのいでいますか？**（手作業 / 既存ツール / 外部 SaaS / 我慢）。その代替手段の何が不十分ですか？」
+- 「**手作業や既製ツールで MVP の仮説を検証できませんか？**（スプレッドシート / Slack / Zapier など）」
+- 「同じ課題を解く**競合・類似プロダクト**はありますか？それらに対して何で勝ちますか（Why us）？」
+- 代替手段で十分なら、その機能は Must にしない（→ Not Now / Won't）。
 
-### スケーラビリティ
+### Day 1 MVP の切り出し
 
-- 「ユーザー数の成長予測、ピーク時のトラフィック想定は？」
+価値提供が成立する最小の行動に絞り込む。
 
-### ユーザビリティ・保守性
+- 「**価値提供が成立する最小の利用者行動**は何ですか？（1〜3 ステップで言うと？）」
+- 「その体験から**外しても価値が壊れない**要素はどれですか？」
+- 「Day 1 に**必ず通ってほしい成功体験**を1〜3本に絞るとどれですか？」（→ Core Scenarios の Happy Path に対応）
 
-- 「アクセシビリティ、対応言語、デバイス、ブラウザは？」
-- 「ログ・監視要件、デプロイ頻度は？」
+### 1ヶ月後に検証したい仮説
 
-## 手順7: ユーザーストーリー
+MVP は仮説検証の手段。検証対象を 1〜3 個に絞る。
 
-### 提案テンプレート
+- 「このMVPで**検証したい仮説**は何ですか？『〜なら、ユーザーは〜する』の形で 1〜3 個に絞ると？」
+- 「リリース1ヶ月後に**どの指標がどう動けば**『仮説は正しかった』と言えますか？」（→ North Star / KPI に対応）
+- 仮説が 4 個以上に増えたら MVP が大きすぎる兆候。最も検証したい 1 つを選び直す。
 
-「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
+### 絶対にやらないこと（Inversion）
 
-### ヒアリング項目
+「やること」ではなく「やらないこと」から考え、スコープ境界を明示する。
 
-- 「他に主要なユーザージャーニーがあれば教えてください（[役割]として、[目的]がしたい、なぜなら[理由]）」
-- 各ストーリーの優先度、受け入れ基準
+- 「このプロダクトが**絶対にやらないこと**は何ですか？（理由付きで）」
+- 「**やると失敗する**ことは何ですか？（過剰な多機能化 / 全ユーザー対応 / 完璧な作り込み 等）」
+- 「ここまではやらない、と**ステークホルダーと合意**できる境界はどこですか？」
+- 結果は Product Brief の「非ゴール」、MVP Scope の Won't / Out of Scope に落とす。

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

@@ -1,28 +1,18 @@
 # 構造チェックコマンド集
 
-SKILL.md 手順9で使う、生成済みドキュメントの構造確認用コマンド。
+SKILL.md 手順8で使う、生成済みドキュメントの構造確認用コマンド。
 
-## 5ドキュメントの必須セクション/テーブル検証
+## a-002 生成ドキュメントの必須セクション/テーブル検証
 
 ```bash
-# 01-system-overview.md: 主要セクションの確認
-grep "## 背景" docs/project/01-requirements/01-system-overview.md && echo "OK" || echo "MISSING: 背景"
-grep "## 目的" docs/project/01-requirements/01-system-overview.md && echo "OK" || echo "MISSING: 目的"
-
-# 02-features-implemented.md: テーブルヘッダー
-grep "| 機能ID | Category 1 |" docs/project/01-requirements/02-features-implemented.md \
-  && echo "OK" || echo "MISSING: Table Header"
-
-# 03-features-planned.md: テーブルヘッダー
-grep "| Category 1 | Category 2 |" docs/project/01-requirements/03-features-planned.md \
-  && echo "OK" || echo "MISSING: Table Header"
-
-# 04-non-functional-requirements.md: テーブルヘッダー
-grep "| カテゴリ | 要件 |" docs/project/01-requirements/04-non-functional-requirements.md \
-  && echo "OK" || echo "MISSING: Table Header"
-
-# 05-user-stories.md: テーブルヘッダー
-grep "| ストーリーID | ストーリー |" docs/project/01-requirements/05-user-stories.md \
+# 01-product-brief.md: 主要セクションの確認
+grep "## 背景 / 解く課題" docs/project/01-requirements/01-product-brief.md && echo "OK" || echo "MISSING: 背景 / 解く課題"
+grep "## 成功指標" docs/project/01-requirements/01-product-brief.md && echo "OK" || echo "MISSING: 成功指標"
+grep "計測方法" docs/project/01-requirements/01-product-brief.md && echo "OK" || echo "MISSING: 成功指標の計測方法列"
+grep "## 非ゴール" docs/project/01-requirements/01-product-brief.md && echo "OK" || echo "MISSING: 非ゴール"
+
+# 06-features-implemented.md（existing モードのみ）: テーブルヘッダー
+grep "| 機能ID | Category 1 |" docs/project/01-requirements/06-features-implemented.md \
   && echo "OK" || echo "MISSING: Table Header"
 ```
 
@@ -42,7 +32,7 @@ git status
 推奨コミットメッセージ:
 
 ```
-docs: 要件定義ドキュメントの作成
+docs: Product Brief（問題定義/Why）の作成
 
-- システム概要、機能要件、非機能要件、ユーザーストーリーを追加
+- Product Brief を追加（existing モードは実装済み機能も）
 ```

package/skills/a-002a-slice-mvp-scope/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: a-002a-slice-mvp-scope
+description: Product Brief を起点に Parking Lot（アイデア backlog）を生成し、候補機能を Must / Not Now / Won't に切り分けて MVP スコープを確定する。各 Must 機能を課題・仮説・成功指標に紐づけて正当化し、やらないこと（Out of Scope）も明示する。Product Brief 作成後（a-002 の後）に実行。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# SliceMvpScope (a-002a)
+
+## 目的
+
+- 「本当に必要なものだけ作る」ため、候補機能を **Must / Not Now / Won't** に切り分けて MVP スコープを確定する。
+- 各 Must 機能を Product Brief の**課題・検証仮説・成功指標**に紐づけて正当化し、過剰作り込みを排除する。
+- **やらないこと（Out of Scope / Won't）**を理由付きで明示し、ステークホルダーと合意できる状態にする。
+- 実行順は a-002（Product Brief）の後、a-003（シナリオ）の前。
+
+## 前提
+
+- `docs/project/01-requirements/01-product-brief.md` が作成されていること（なければ先に `/a-002-initialize-project` を実行）。
+- 課題・ターゲット・成功指標・非ゴールが Product Brief に記載されていること。
+- アイデアの backlog（`03-parking-lot.md`）は本スキルが生成・管理する（Product Brief から候補を起こす）。
+
+## 手順
+
+### 1. 前提の確認
+
+```bash
+ls -l docs/project/01-requirements/01-product-brief.md 2>/dev/null || echo "MISSING: 01-product-brief.md"
+```
+
+存在しない場合: 「`01-product-brief.md` がありません。先に `/a-002-initialize-project` で Product Brief を作成してください。」と促して中断。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-002a-slice-mvp-scope/`）を起点に、以下を Read→Write でコピーする（FOR EACH）。出力先に既に存在する場合は上書きせずスキップして報告する（冪等）。
+
+- `../../templates/project/01-requirements/02-mvp-scope.md` → `docs/project/01-requirements/02-mvp-scope.md`
+- `../../templates/project/01-requirements/03-parking-lot.md` → `docs/project/01-requirements/03-parking-lot.md`
+
+### 3. 候補機能の洗い出し（Parking Lot への記入）
+
+`01-product-brief.md`（課題・価値提案・成功指標）を読み込み、課題・価値提案を満たすのに必要な機能を逆算して候補を列挙する。列挙したアイデアは `03-parking-lot.md` に幅広く記入する（この段階では**優先度・機能 ID を厳密に決めず**拾う）。
+
+- 差分提案例: 「Product Brief で『〇〇機能』への言及がありましたが backlog に未記載です。Parking Lot に追加しますか？」
+- 記入項目: Category 1 / Category 2 / 機能名（アイデア段階でも可）/ 説明（目的・価値中心）。
+
+> existing モードでは `06-features-implemented.md`（実装済み機能、a-002 が生成）も読み込み、未実装のギャップを Parking Lot 候補に加える。
+
+### 4. MVP 判定（Must / Not Now / Won't）
+
+FOR EACH 候補機能: `02-mvp-scope.md` のテーブルに記入する。
+
+- **MVP判定**を Must / Not Now / Won't のいずれかに決める。
+  - Must: この MVP の仮説検証に不可欠。これが無いと価値が成立しない。
+  - Not Now: 価値はあるが今回は不要（→ Parking Lot へ）。
+  - Won't: 明示的に作らない（→ Out of Scope へ）。
+- 各 Must は**課題 / 検証仮説 / 成功指標のいずれかに必ず紐づける**（同じ言葉で参照）。紐づかない Must は過剰作り込み候補として Not Now / Won't に倒す。
+- **「より安い代替手段（手作業・既存ツール・外部サービス）で足りるか」を必ず問う**。足りるなら Must にしない。
+
+検証する仮説は 1〜3 個に絞る。多すぎる場合は MVP が大きすぎる兆候として再検討する。
+
+### 5. やらないこと（Out of Scope）の明示
+
+`02-mvp-scope.md` の「Out of Scope」セクションに、Won't 機能と**作らない理由**を記入する。Product Brief の「非ゴール」と整合させる。
+
+### 6. Parking Lot の整理
+
+Not Now / Won't と判定したアイデアを `03-parking-lot.md` に移動・整理する。Parking Lot は優先度を厳密に決めない backlog として維持し、MVP Scope（優先度必須）と役割を分ける。
+
+### 7. レビュー
+
+- ユーザーに MVP Scope を提示し、以下を確認:
+  - 「Must が多すぎませんか？削れる Must はありませんか？」
+  - 「各 Must は仮説・指標に紐づいていますか？」
+  - 「やらないこと（Won't）に合意できますか？」
+
+## 完了条件
+
+- `docs/project/01-requirements/03-parking-lot.md` が作成され、候補アイデアが幅広く記入されている（優先度・機能 ID は未確定でよい）。
+- `docs/project/01-requirements/02-mvp-scope.md` が作成され、各候補機能に Must / Not Now / Won't 判定が入っている。
+- すべての Must 機能が課題 / 検証仮説 / 成功指標のいずれかに紐づいている。
+- Out of Scope（Won't）が理由付きで記入されている。
+- 検証する仮説が 1〜3 個に絞られている。
+- ユーザーがスコープに合意またはフィードバックを提供している。
+
+構造チェック:
+
+```bash
+grep "| Category 1 | Category 2 |" docs/project/01-requirements/03-parking-lot.md && echo "OK" || echo "MISSING: parking-lot Table Header"
+grep -E "Must|Not Now|Won't" docs/project/01-requirements/02-mvp-scope.md && echo "OK" || echo "MISSING: MVP 判定"
+```
+
+## エスカレーション
+
+- **Must が多すぎて削れない**: 「すべてを Day 1 に作ると MVP の意味が薄れます。最も検証したい仮説1つに絞ると、どれが Must ですか？」と問い直す。
+- **代替手段で足りる機能が Must になっている**: 「これは手作業/既存ツールで代替できそうです。まず代替手段で検証しませんか？」と提案。
+- **やらないことに合意が得られない**: 決裁者・関心事（Product Brief のステークホルダー）に立ち戻り、合意形成の論点として記録する。
+
+## 参考
+
+- [../../templates/project/01-requirements/02-mvp-scope.md](../../templates/project/01-requirements/02-mvp-scope.md) — MVP Scope テンプレート（判定基準・列定義）
+- [../../templates/project/01-requirements/03-parking-lot.md](../../templates/project/01-requirements/03-parking-lot.md) — Parking Lot テンプレート（アイデア backlog）
+- [../a-002-initialize-project/reference/hearing-questions.md](../a-002-initialize-project/reference/hearing-questions.md) — 深掘りフレーム集（より安い代替手段・競合 / Day 1 MVP / 1ヶ月後に検証したい仮説 / Inversion）。手順4・5 のスコープ判定で活用する
+- `01-product-brief.md` — 課題・成功指標・非ゴールの参照元
+- `03-parking-lot.md` — Not Now / Won't アイデアの backlog