yodogawa 2.1.1 → 2.2.0

package/package.json

@@ -1,56 +1,68 @@
-{
-  "name": "yodogawa",
-  "version": "2.1.1",
-  "description": "CLI to install Yodogawa Slash Commands workflows",
-  "bin": {
-    "yodogawa": "bin/cli.js"
-  },
-  "files": [
-    "bin",
-    "skills",
-    "templates",
-    "scripts",
-    "README.md",
-    "CHANGELOG.md"
-  ],
-  "scripts": {
-    "test": "echo \"Error: no test specified\" && exit 1",
-    "lint:md": "markdownlint-cli2 \"**/*.md\" \"#node_modules\"",
-    "lint:md:fix": "markdownlint-cli2 --fix \"**/*.md\" \"#node_modules\"",
-    "prepare": "husky"
-  },
-  "keywords": [
-    "antigravity",
-    "cursor",
-    "claude-code",
-    "codex",
-    "workflows",
-    "slash-commands",
-    "spec-driven-development",
-    "ai-coding",
-    "documentation",
-    "project-management",
-    "bdd",
-    "gherkin",
-    "domain-driven-design",
-    "event-storming",
-    "api-design",
-    "adr",
-    "task-management",
-    "user-stories",
-    "copilot",
-    "gpt",
-    "claude"
-  ],
-  "author": "",
-  "license": "MIT",
-  "dependencies": {
-    "fs-extra": "^11.2.0",
-    "kleur": "^4.1.5",
-    "prompts": "^2.4.2"
-  },
-  "devDependencies": {
-    "husky": "^9.1.7",
-    "markdownlint-cli2": "^0.20.0"
-  }
-}
+{
+  "name": "yodogawa",
+  "version": "2.2.0",
+  "description": "AIネイティブIDE向け仕様駆動開発スキル集",
+  "homepage": "https://github.com/tkysi-mi/Yodogawa#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/tkysi-mi/Yodogawa.git"
+  },
+  "bugs": {
+    "url": "https://github.com/tkysi-mi/Yodogawa/issues"
+  },
+  "bin": {
+    "yodogawa": "bin/cli.js"
+  },
+  "files": [
+    "bin",
+    "skills",
+    "templates",
+    "README.md",
+    "CHANGELOG.md"
+  ],
+  "scripts": {
+    "test": "node --test \"test/**/*.test.js\"",
+    "lint:md": "markdownlint-cli2 \"**/*.md\" \"#node_modules\" \"#test/fixtures\"",
+    "lint:md:fix": "markdownlint-cli2 --fix \"**/*.md\" \"#node_modules\" \"#test/fixtures\"",
+    "check:repo": "node scripts/repo-check.mjs",
+    "sync:manifests": "node scripts/sync-plugin-manifests.mjs",
+    "version": "node scripts/sync-plugin-manifests.mjs && git add .claude-plugin/plugin.json .claude-plugin/marketplace.json",
+    "prepare": "husky"
+  },
+  "keywords": [
+    "antigravity",
+    "cursor",
+    "claude-code",
+    "codex",
+    "skills",
+    "spec-driven-development",
+    "ai-coding",
+    "documentation",
+    "project-management",
+    "bdd",
+    "gherkin",
+    "domain-driven-design",
+    "event-storming",
+    "api-design",
+    "adr",
+    "task-management",
+    "user-stories",
+    "copilot",
+    "gpt",
+    "claude"
+  ],
+  "author": "tkysi-mi",
+  "license": "MIT",
+  "engines": {
+    "node": ">=18"
+  },
+  "dependencies": {
+    "fs-extra": "^11.2.0",
+    "kleur": "^4.1.5",
+    "prompts": "^2.4.2"
+  },
+  "devDependencies": {
+    "husky": "^9.1.7",
+    "markdownlint-cli2": "^0.22.1"
+  }
+}

package/skills/a-001-setup-doc-structure/SKILL.md

@@ -19,18 +19,19 @@ allowed-tools: Read, Write, Bash, Glob
 
 ## 手順
 
-### 1. スクリプトの実行
+### 1. ディレクトリ構造の作成
 
-環境に応じたスクリプトを実行。スクリプト本体とフォールバック実装は [reference/directory-structure.md](reference/directory-structure.md#スクリプト実行コマンド) を参照。
+次のディレクトリを作成する（`mkdir -p` なので既存の場合は不足分のみ追加される）。
 
 ```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-bash "$SCRIPT_DIR/scripts/setup-docs.sh"
+mkdir -p docs/project/01-requirements docs/project/02-behavior docs/project/03-domain docs/project/04-design docs/tasks
 ```
 
+続いて `docs/README.md` を作成する。内容は [reference/directory-structure.md](reference/directory-structure.md#docsreadmemd-テンプレート) の「docs/README.md テンプレート」をそのまま Write する。`docs/README.md` が既に存在する場合は、上書き前にユーザーへ確認する。
+
 ### 2. 結果の確認
 
-スクリプト実行結果にエラーがないこと、および期待した構造が生成されていることを確認。生成構造と各ディレクトリの用途は [reference/directory-structure.md](reference/directory-structure.md#生成されるディレクトリ構造) を参照。
+ディレクトリ構造と `docs/README.md` が期待どおり生成されていることを確認。生成構造と各ディレクトリの用途は [reference/directory-structure.md](reference/directory-structure.md#生成されるディレクトリ構造) を参照。
 
 ### 3. Git への追加（オプション）
 
@@ -45,8 +46,8 @@ git status
 
 ### 4. 完了条件の確認
 
-- [ ] スクリプトが正常に終了した
 - [ ] `docs/` ディレクトリ構造が正しく作成されている
+- [ ] `docs/README.md` が作成されている
 
 ## 完了条件
 

package/skills/a-001-setup-doc-structure/reference/directory-structure.md

@@ -17,8 +17,8 @@ docs/
 
 ### 各ディレクトリの用途
 
-- `project/01-requirements/` — 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリー）
-- `project/02-behavior/` — 振る舞い定義（Gherkin シナリオ）
+- `project/01-requirements/` — 要件定義（Product Brief、MVP スコープ、Parking Lot、ユーザーストーリー。詳細な非機能要件は設計フェーズ/a-014 で扱う）
+- `project/02-behavior/` — 振る舞い定義（Core Scenarios）
 - `project/03-domain/` — ドメインモデル、ユビキタス言語
 - `project/04-design/` — 画面設計、データモデル、API 仕様、アーキテクチャ等
 - `tasks/` — 個別タスク（`task{ID}-{SLUG}/` 形式）
@@ -32,17 +32,44 @@ docs/
 - ドキュメント構成を説明する docs/README.md を追加
 ```
 
-## スクリプト実行コマンド
+## docs/README.md テンプレート
 
-```bash
-if [ -d ".claude" ]; then
-  SCRIPT_DIR=".claude"
-elif [ -d ".agents" ]; then
-  SCRIPT_DIR=".agents"
-else
-  echo "エラー: .claude または .agents ディレクトリが見つかりません"
-  exit 1
-fi
+SKILL.md 手順1で `docs/README.md` として Write する内容。
 
-bash "$SCRIPT_DIR/scripts/setup-docs.sh"
+```markdown
+# プロジェクトドキュメント
+
+このディレクトリには、プロジェクト全体のドキュメントと個別タスクのドキュメントを管理します。
+
+## 構成
+
+### project/
+プロジェクト全体のドキュメント。要件定義、設計、アーキテクチャなど、プロジェクトスコープ全体に関わる情報を記載します。
+
+- **01-requirements/**: 要件定義（Product Brief、MVP スコープ、Parking Lot、ユーザーストーリーなど。詳細な非機能要件は設計フェーズ/a-014 で扱う）
+- **02-behavior/**: 振る舞い定義（Core Scenarios、ユースケース、ユーザージャーニーなど）
+- **03-domain/**: ドメインモデル（エンティティ、用語集など）
+- **04-design/**: 設計（アーキテクチャ、データモデル、API仕様など）
+
+### tasks/
+個別タスクのドキュメント。Issue やチケット単位で作成します。
+
+## 更新方針
+
+### プロジェクト全体のドキュメント (project/)
+- プロジェクトのスコープ全体に影響する情報を記載
+- チーム全体で共有すべき要件・設計・アーキテクチャを管理
+- 更新時は関係者にレビューを依頼
+
+### 個別タスクのドキュメント (tasks/)
+- 特定の Issue やチケットに紐づく情報を記載
+- タスク単位で作成・完了・アーカイブ
+- 完了後は参照資料として保持、または削除
+
+## ドキュメント作成ガイドライン
+
+- **具体的**: 抽象的な表現を避け、数値・期限・制約を明確に記載
+- **測定可能**: 成功基準やパフォーマンス目標を定量化
+- **最新**: 変更があれば速やかに更新し、古い情報を残さない
+- **簡潔**: 必要最低限の情報に絞り、詳細はコードやリンク先に委ねる
 ```

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

@@ -1,6 +1,6 @@
 ---
 name: a-002-initialize-project
-description: プロジェクトの要件を対話形式で収集し、システム概要・機能要件・非機能要件・ユーザーストーリーのドキュメントを生成する。新規プロジェクト開始時、または要件が未整備の場合に使用。
+description: プロジェクトの問題定義(Why)を Product Brief（誰のどの課題を・なぜ今・どう解き・どう成功を測るか）として対話形式で作成し、要件定義の起点とする。MVP スコープ・ユーザーストーリーは後続スキルが担う。新規（greenfield）/ 既存（existing）の2モードに対応し、既定は新規。新規プロジェクト開始時、または要件が未整備の場合に使用。
 disable-model-invocation: true
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ---
@@ -9,54 +9,73 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ## 目的
 
-- プロジェクトの目的・背景・機能要件を詳細にヒアリングし、具体的で実装可能なドキュメントを作成する。
-- システム概要・実装済み機能・予定機能・非機能要件・ユーザーストーリーを網羅する。
+- 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/project/01-requirements/` ディレクトリが存在すること（なければ先に `/a-001-setup-doc-structure` を実行）
-- `docs/` に書き込み権限があること
-- ユーザーがプロジェクト概要と主要機能の基本情報を提供できること
+- `docs/` 配下への書き込み権限があること（必要なディレクトリ構造は本スキルが自動作成するため、`/a-001-setup-doc-structure` の事前実行は不要）
+- ユーザーがプロジェクトの課題・対象ユーザー・期待価値の基本情報を提供できること
 
 ## 手順
 
-### 1. ドキュメントディレクトリの確認
+### 1. ドキュメント基盤の確保
+
+要件定義に必要なディレクトリ構造を確保する。`mkdir -p` なので冪等で、明示的な `/a-001-setup-doc-structure` 実行は不要（必要時に本手順が自動で初期化する）。
 
 ```bash
-ls -la docs/project/01-requirements/ 2>/dev/null || echo "ディレクトリが存在しません"
+mkdir -p docs/project/01-requirements docs/project/02-behavior docs/project/03-domain docs/project/04-design docs/tasks
 ```
 
-存在しない場合: 「`docs/project/01-requirements/` がありません。先に `/a-001-setup-doc-structure` を実行してください。」
+`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. テンプレート一括コピー
+### 2. モード判定（greenfield / existing）
 
-要件定義に必要な 5 ファイルのテンプレートを `docs/project/01-requirements/` に一括コピーする。既存ファイルはスキップされる（冪等）。
+このスキルは新規プロダクト（**greenfield**）と既存プロダクト（**existing / brownfield**）の2モードに対応する。後続手順（テンプレート選定・コード分析・実装済み機能の棚卸し）の分岐に影響するため、最初にモードを確定する。
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-bash "$SCRIPT_DIR/scripts/init-project-docs.sh" requirements
-```
+判定ロジック:
 
-コピーされるファイル:
+- ユーザーがモードを明示した場合はそれを優先する。
+- 明示がない場合は、軽量シグナルから推定する。
 
-- `01-system-overview.md`
-- `02-features-implemented.md`
-- `03-features-planned.md`
-- `04-non-functional-requirements.md`
-- `05-user-stories.md`
+  ```bash
+  ls -F
+  cat package.json 2>/dev/null
+  cat README.md 2>/dev/null
+  find src app lib -maxdepth 2 2>/dev/null
+  ```
 
-### 3. コードベースの自動分析と提案
+  - ソースコード・`package.json`・既存ドキュメントが揃い相応の規模があれば **existing** を候補にする。
+  - ファイルがほとんど無い／ソースコードが無い場合は **greenfield** を候補にする。
+- 推定が曖昧な場合の**既定は greenfield**（Yodogawa の主目的は新規プロダクトの仕様駆動立ち上げのため）。
+- 「このプロジェクトを greenfield（新規）/ existing（既存）として進めます。よろしいですか？」とユーザーに提示し、確認を取る。
 
-**規模確認**:
+確定したモードを以降の手順で参照する。
 
-```bash
-ls -F
-```
+### 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
@@ -64,51 +83,53 @@ 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）。
+結果から以下を推測・提示: Product Brief の下書き（課題・目的・技術スタック）、実装済み機能（ファイル構造からの推測）、想定ユーザー像。
 
-コード調査コマンドとヒアリング項目は [reference/hearing-questions.md](reference/hearing-questions.md#手順4-実装済み機能一覧) を参照。
+### 5. Product Brief の記入（中核）
 
-### 6. 予定機能一覧の記入
+`01-product-brief.md` を開き、深掘りヒアリングで埋める。**これがこのスキルの中核成果物**で、後続スキル（MVP Scope / Core Scenarios / PM Gate）が参照する。
 
-`03-features-planned.md` に、システム概要と実装済み機能のギャップを分析して未実装機能を提案し、ヒアリング結果をテーブルに記入する（機能 ID・優先度は未確定のまま）。
+- 記入対象: 背景/解く課題（証拠・規模つき）、ターゲットユーザー / 主要ペルソナ、ステークホルダー、現在の代替手段・競合スキャン、価値提案/差別化、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段以上掘り下げ、表層の要望ではなく本質的な課題に到達する。
+- 「この課題を作らずに放置したら何が起きるか」「既存の代替手段で十分ではないか」を必ず確認する。
 
-### 7. 非機能要件の記入
+質問例は [reference/hearing-questions.md](reference/hearing-questions.md#手順5-product-brief) を参照。
 
-`04-non-functional-requirements.md` に、詳細定義が必要か確認の上、パフォーマンス/セキュリティ/可用性/スケーラビリティ/ユーザビリティ・保守性の観点で**定量的な目標**をヒアリングして記入する。不要なら標準ベースライン（[examples/nfr-baseline.md](examples/nfr-baseline.md)）で仮置きする。
+### 6. 実装済み機能一覧の記入（existing モードのみ）
 
-### 8. ユーザーストーリーの記入
+> greenfield モードではこの手順をスキップする（`06-features-implemented.md` は任意の空資料）。
 
-`05-user-stories.md` に、作成済みドキュメントから主要ユーザージャーニーを抽出してストーリー案を提示し、ヒアリング結果をテーブルに記入する（優先度・受け入れ基準含む）。
+`06-features-implemented.md` に、コードベース調査で検出したディレクトリ/ファイル名から機能を提案し、ヒアリング結果をテーブルに記入する（Category 1/2、機能名、説明、機能 ID）。
 
-ストーリーテンプレート: 「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
+コード調査コマンドとヒアリング項目は [reference/hearing-questions.md](reference/hearing-questions.md#手順6-実装済み機能一覧) を参照。
 
-### 9. 全体レビュー
+### 7. 全体レビュー
 
 - 作成した全ドキュメントをユーザーに提示し、以下を確認:
   - 「記載内容に誤りや漏れはありませんか？」
   - 「抽象的すぎる記述や、解釈が分かれそうな表現はありますか？」
   - 「テンプレートのコメントや不要な例示は適切に処理されていますか？」
 
-### 10. 完了条件と構造の確認
+### 8. 完了条件と構造の確認
 
 - ファイルの存在と主要セクション/テーブル構造を検証。
 - 検証コマンド・チェックリスト・Git コミット手順は [reference/structure-check.md](reference/structure-check.md) を参照。
 
-### 11. Git への追加（オプション）
+### 9. Git への追加（オプション）
 
 詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加オプション) を参照。
 
 ## 完了条件
 
-- `docs/project/01-requirements/` に 5 つの要件定義ドキュメントが作成されている
+- `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` で作成する
 - すべてのドキュメントで抽象的表現が最小化され、具体的な数値・期限・制約が記載されている
 - ユーザーがドキュメント内容を確認し、承認またはフィードバックを提供している
 
@@ -120,6 +141,5 @@ find src app lib -maxdepth 2 2>/dev/null
 
 ## 参考
 
-- [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) — 非機能要件の標準ベースライン提案値
+- [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 に落とす。