yodogawa 2.1.1 → 2.2.0

package/skills/b-002-create-task-definition/SKILL.md

@@ -17,7 +17,7 @@ argument-hint: "[task-id]"
 ## 前提
 
 - `docs/tasks/task{ID}-{SLUG}/` が `/b-001-create-task-directory` で作成済み
-- テンプレート: `{IDE_DIR}/templates/tasks/task-template/a-definition.md`
+- テンプレート: `../../templates/tasks/task-template/a-definition.md`（スキル配置ディレクトリ起点の相対参照）
 - タスクの概要が関係者と共有済み
 
 ## 手順
@@ -26,15 +26,14 @@ argument-hint: "[task-id]"
 
 ### 1. タスクディレクトリとテンプレートの確認
 
-対象タスクディレクトリを確認し、テンプレートをコピー。スクリプトが冪等なので、既存ファイルはスキップされる。
+対象タスクディレクトリを確認する。
 
 ```bash
 ls -d docs/tasks/task*
-
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-bash "$SCRIPT_DIR/scripts/init-task-doc.sh" "docs/tasks/task{ID}-{SLUG}" definition
 ```
 
+このスキルの配置ディレクトリ（`skills/b-002-create-task-definition/`）を起点に、相対パス `../../templates/tasks/task-template/a-definition.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/a-definition.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
 ### 2. 目的・背景のヒアリング
 
 現状の課題、困っている人、完了後の価値/KPI を具体的に確認。質問例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#目的背景のヒアリング) を参照。

package/skills/b-003-create-task-research/SKILL.md

@@ -18,7 +18,7 @@ argument-hint: "[task-id]"
 
 - `CreateTaskDefinition (b-002)` が完了し、`a-definition.md` に目的・変更内容が記載されている。
 - タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
-- テンプレート: `{IDE_DIR}/templates/tasks/task-template/b-research.md`
+- テンプレート: `../../templates/tasks/task-template/b-research.md`（スキル配置ディレクトリ起点の相対参照）
 
 ## 手順
 
@@ -26,15 +26,14 @@ argument-hint: "[task-id]"
 
 ### 1. ドキュメントとテンプレートの準備
 
-対象タスクディレクトリを確認し、テンプレートをコピー。スクリプトが冪等なので、既存ファイルはスキップされる。
+対象タスクディレクトリを確認する。
 
 ```bash
 ls -d docs/tasks/task*
-
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-bash "$SCRIPT_DIR/scripts/init-task-doc.sh" "docs/tasks/task{ID}-{SLUG}" research
 ```
 
+このスキルの配置ディレクトリ（`skills/b-003-create-task-research/`）を起点に、相対パス `../../templates/tasks/task-template/b-research.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/b-research.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
 ### 2. 調査計画の立案
 
 - `a-definition.md` を読み、変更対象・技術要件・制約を抽出。

package/skills/b-004-create-task-implementation/SKILL.md

@@ -18,7 +18,7 @@ argument-hint: "[task-id]"
 
 - `a-definition.md`（b-002）と `b-research.md`（b-003）が作成済み
 - タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
-- テンプレート: `{IDE_DIR}/templates/tasks/task-template/c-implementation.md`
+- テンプレート: `../../templates/tasks/task-template/c-implementation.md`（スキル配置ディレクトリ起点の相対参照）
 
 ## 手順
 
@@ -26,15 +26,14 @@ argument-hint: "[task-id]"
 
 ### 1. ドキュメント確認とテンプレート準備
 
-対象タスクディレクトリを確認し、テンプレートをコピー。スクリプトが冪等なので、既存ファイルはスキップされる。
+対象タスクディレクトリを確認する。
 
 ```bash
 ls -d docs/tasks/task*
-
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-bash "$SCRIPT_DIR/scripts/init-task-doc.sh" "docs/tasks/task{ID}-{SLUG}" implementation
 ```
 
+このスキルの配置ディレクトリ（`skills/b-004-create-task-implementation/`）を起点に、相対パス `../../templates/tasks/task-template/c-implementation.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/c-implementation.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
 `a-definition.md` から目的・変更内容・受け入れ基準を、`b-research.md` から技術方針・ライブラリ選定・リスクを読み取る。
 
 ### 2. フェーズ設計

package/skills/b-005-review-task/reference/assessment-criteria.md

@@ -11,7 +11,7 @@ SKILL.md 手順5「実装開始可否の判定」で参照する基準とアク
 
 ## 推奨アクション
 
-- 総合評価が「優」「良」の場合：「実装開始可能です。`/c-001-ImplementTask` を実行してください。」
+- 総合評価が「優」「良」の場合：「実装開始可能です。`/c-001-implement-task` を実行してください。」
 - 総合評価が「可」の場合：「Error を修正後、実装を開始してください。」
 - 総合評価が「不可」の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
 
@@ -21,8 +21,8 @@ SKILL.md 手順5「実装開始可否の判定」で参照する基準とアク
 
 - Errorが検出された場合：「以下の問題を優先的に修正してください：」
 - 修正すべきドキュメントとスキルを案内：
-  - 例：「ユーザーストーリーUS-002に対応する実装ステップがありません → `/b-003-CreateTaskImplementation` で実装計画を更新」
-  - 例：「受け入れ基準が一致していません → `/b-001-CreateTaskDefinition` でタスク定義を見直し」
+  - 例：「ユーザーストーリーUS-002に対応する実装ステップがありません → `/b-004-create-task-implementation` で実装計画を更新」
+  - 例：「受け入れ基準が一致していません → `/b-002-create-task-definition` でタスク定義を見直し」
 
 ユーザーに確認：「今すぐ修正作業を開始しますか？それとも後で個別に修正しますか？」
 

package/skills/c-001-implement-task/SKILL.md

@@ -170,7 +170,7 @@ npm run build
 
 ## エスカレーション
 
-- **必須ドキュメントが不足**: 「{ドキュメント名} が見つかりません。先に該当スキルを実行してください（タスク定義 → `/b-001` / リサーチ → `/b-002` / 実装タスクリスト → `/b-003`）。」
+- **必須ドキュメントが不足**: 「{ドキュメント名} が見つかりません。先に該当スキルを実行してください（タスク定義 → `/b-002` / リサーチ → `/b-003` / 実装タスクリスト → `/b-004`）。」
 - **開発環境が未準備**: 「必要なツールがインストールされていません：{ツール名}」とインストール方法をガイド。
 - **ステップ実装中のエラー**: 原因を分析し修正を試行。修正不能ならユーザーに報告しガイダンスを求める。
 - **テスト失敗**: 失敗の原因を分析し、修正が必要なコードを特定して提案 or 実行。

package/skills/c-001-implement-task/reference/implementation-loop.md

@@ -51,7 +51,7 @@ SKILL.md の手順全体を俯瞰するための参考資料。
 
 ## speckit.implement との対応
 
-| speckit.implement | c-001-ImplementTask | 説明 |
+| speckit.implement | c-001-implement-task | 説明 |
 |-------------------|---------------------|------|
 | constitution ファイル確認 | タスク定義ドキュメント確認 | プロジェクトのガバナンスと標準 |
 | specification ドキュメント確認 | タスク定義・リサーチ確認 | 何を構築するかの仕様 |

package/skills/c-002-update-documentation/SKILL.md

@@ -17,7 +17,7 @@ argument-hint: "[task-id]"
 
 ## 前提
 
-- `/c-001-ImplementTask` で実装が完了していること
+- `/c-001-implement-task` で実装が完了していること
 - タスクディレクトリ `docs/tasks/task000001-{スラッグ}/` とタスクドキュメントが存在すること
 - 実装タスクリストの全ステップが完了していること
 - プロジェクトドキュメント構造（`docs/01-requirements/`, `docs/03-domain/`, `docs/04-design/` など）が存在すること
@@ -35,7 +35,7 @@ argument-hint: "[task-id]"
 - [ ] テストが全て通っている
 - [ ] PR/MR が作成されている（該当する場合）
 
-未完了なら「タスク {task-id} の実装がまだ完了していません。先に `/c-001-ImplementTask` を実行してください。」と案内する。
+未完了なら「タスク {task-id} の実装がまだ完了していません。先に `/c-001-implement-task` を実行してください。」と案内する。
 
 ### 2. 実装内容の確認
 
@@ -82,13 +82,13 @@ git log --name-only --oneline main..HEAD
 
 **要件** (`docs/01-requirements/`):
 
-- [ ] `02-features-implemented.md`: 実装済み機能リストに追加
-- [ ] `03-features-planned.md`: 計画中機能リストから削除
+- [ ] `06-features-implemented.md`: 実装済み機能リストに追加（existing モードのみ）
+- [ ] `03-parking-lot.md`: 実装した（または不要判断した）アイデアを backlog から削除
 - [ ] `05-user-stories.md`: ユーザーストーリーのステータス更新
 
 **ドメイン** (`docs/03-domain/`):
 
-- [ ] `01-domain-model.md`: エンティティ・値オブジェクトの追加
+- [ ] `01-domain-sketch.md`: 中核エンティティ・重要ルールの更新（Full DDD 採用時は `01-domain-model.md`）
 - [ ] `02-ubiquitous-language.md`: 新しいドメイン用語の追加
 
 **設計** (`docs/04-design/`):
@@ -133,7 +133,7 @@ git add README.md CHANGELOG.md .env.example
 
 - `c-implementation.md` の振り返りから共通化候補を特定
 - ベストプラクティスを次タスクのリサーチ入力として記録
-- 必要に応じてタスクテンプレート (`{IDE_DIR}/templates/tasks/task-template/`) を改善
+- 必要に応じてタスクテンプレート (`templates/tasks/task-template/`) を改善
 
 ## 完了条件
 
@@ -146,7 +146,7 @@ git add README.md CHANGELOG.md .env.example
 
 ## エスカレーション
 
-- **実装未完了**: 「タスクの実装がまだ完了していません。先に `/c-001-ImplementTask` を実行してください。」
+- **実装未完了**: 「タスクの実装がまだ完了していません。先に `/c-001-implement-task` を実行してください。」
 - **計画との差異が大きい**: 差異の理由と影響範囲を明確化し、関係者に共有。必要ならアーキテクチャレビューを実施。
 - **ドキュメント更新が複雑**: 段階的更新を推奨（タスクドキュメント → プロジェクトドキュメント、重要度順）。
 - **用語の不一致**: `ubiquitous-language.md` で用語を統一し、既存ドキュメントを一括修正。

package/skills/c-002-update-documentation/examples/project-doc-updates.md

@@ -2,7 +2,7 @@
 
 SKILL.md 手順4で使うテンプレート。要件・ドメイン・設計・README など各ドキュメントに追記するサンプル。
 
-## features-implemented.md
+## 06-features-implemented.md
 
 ```markdown
 ## ユーザー認証・認可
@@ -27,10 +27,10 @@ SKILL.md 手順4で使うテンプレート。要件・ドメイン・設計・R
 **PR/MR**: #123
 ```
 
-## features-planned.md
+## 03-parking-lot.md
 
-- 実装完了した機能をリストから削除
-- または、ステータスを「実装済み」に変更し `02-features-implemented.md` への参照を追加
+- 実装完了した（または不要判断した）アイデアを backlog から削除
+- または、ステータスを「実装済み」に変更し `06-features-implemented.md` への参照を追加
 
 ## domain-model.md
 

package/skills/c-002-update-documentation/reference/doc-structure-and-checks.md

@@ -6,7 +6,7 @@ SKILL.md 手順5（整合性検証）とベストプラクティスで参照す
 
 ### クロスリファレンスの確認
 
-- [ ] **要件 ↔ ドメインモデル**: features-implemented.md の機能が domain-model.md に反映されているか
+- [ ] **要件 ↔ ドメインモデル**: 06-features-implemented.md の機能が domain-model.md に反映されているか
 - [ ] **ドメインモデル ↔ データモデル**: domain-model.md のエンティティが data-model.md のテーブルに対応しているか
 - [ ] **ドメインモデル ↔ API 仕様**: domain-model.md の振る舞いが api-spec.md のエンドポイントに対応しているか
 - [ ] **API 仕様 ↔ 実装**: api-spec.md のエンドポイントが実際に実装されているか
@@ -55,11 +55,13 @@ SKILL.md 手順5（整合性検証）とベストプラクティスで参照す
 ### プロジェクトレベル（`docs/`）
 
 - `01-requirements/`: 要件定義
-  - `02-features-implemented.md`: 実装済み機能
-  - `03-features-planned.md`: 計画中機能
+  - `01-product-brief.md`: Product Brief
+  - `02-mvp-scope.md`: MVP スコープ（Must / Not Now / Won't）
+  - `03-parking-lot.md`: アイデア backlog
   - `05-user-stories.md`: ユーザーストーリー
+  - `06-features-implemented.md`: 実装済み機能（existing モード）
 - `03-domain/`: ドメイン
-  - `01-domain-model.md`: ドメインモデル
+  - `01-domain-sketch.md`: ドメイン（Full DDD 採用時は `01-domain-model.md`）
   - `02-ubiquitous-language.md`: ユビキタス言語
 - `04-design/`: 設計
   - `03-screen-design.md`: 画面設計
@@ -75,10 +77,7 @@ SKILL.md 手順5（整合性検証）とベストプラクティスで参照す
 
 ## 自動化のヒント
 
-将来的に、以下のスクリプトでドキュメント更新を一部自動化することを検討：
-
-- `scripts/update-docs.sh`: コミットログから変更内容を抽出してドラフトを作成
-- `scripts/generate-api-docs.sh`: コードから API 仕様書を生成
+将来的に、コミットログからの変更抽出やコードからの API 仕様生成などで、ドキュメント更新を一部自動化することを検討。
 
 ## コミットメッセージのテンプレート
 
@@ -91,7 +90,7 @@ Task-level documentation:
 - Update c-implementation.md with implementation notes and retrospective
 
 Project-level documentation:
-- Add {機能名} to features-implemented.md
+- Add {機能名} to 06-features-implemented.md
 - Update domain-model.md / data-model.md / api-spec.md
 - Update README.md with setup instructions
 - Add changelog entry

package/templates/project/01-requirements/01-product-brief.md

@@ -0,0 +1,186 @@
+# Product Brief
+
+<!--
+何のドキュメントか: ステークホルダーと5分で「なぜ作るのか」を合意するための軽量資料。
+                    詳細な PRD ではない。実装前に Go / No-Go を判断できる最小情報に絞る。
+
+使い方:
+  - 各セクションは数文〜小さな表で簡潔に。抽象論ではなく証拠・数値・固有名で書く。
+  - 埋まらない箇所は「未確定事項」に逃がし、空欄のまま放置しない。
+  - 成功指標・非ゴール・クリティカル制約は後続スキル（MVP Scope / PM Gate）が参照するため必須。
+-->
+
+## 背景 / 解く課題
+
+<!--
+何を書くか: 誰の・どの課題を・なぜ今解くのか。問題の証拠と規模を添える。
+必須情報:
+  - 具体的な課題（「〜できない」「〜に時間がかかる」）
+  - 問題の証拠・規模（数値・頻度・影響範囲。例: 「月◯件」「1件あたり2時間」）
+  - 放置した場合に何が起きるか
+ベストプラクティス: 抽象表現（「効率が悪い」）より具体表現（「手動で2時間かかる」）。
+-->
+
+**例:**
+新入社員が既存社員と接点を持つ機会が少なく、チームに馴染むまで平均◯週間かかる。リモート増加で雑談・自然な関係構築の場が減り、オンボーディング満足度が低下している（直近アンケートで◯%が「孤立を感じた」と回答）。
+
+## ターゲットユーザー / 主要ペルソナ
+
+<!--
+何を書くか: 主に誰のためのプロダクトか。MVP段階は主要 1〜2 ペルソナに絞る（過剰な人物像づくりはしない / YAGNI）。
+列の意味:
+  - ペルソナID: P-001 形式。05-user-stories.md の「ペルソナ」列がこの ID を参照し、ストーリーの [役割] を解決する SSoT。
+  - 種別: 主要 / 副次。
+  - 役割・ひとこと: どんな人か（職種・立場・状況を一言で）。
+  - ゴール（Job）: その人が片付けたい仕事・達成したいこと。
+  - 主な課題・ペイン: 今困っていること（「〜できない」「〜に時間がかかる」）。
+  - 利用文脈: いつ・どこで・どんな状況で使うか（タイミング・デバイス・頻度）。
+  - ニーズの強さ（任意）: 課題の切実さ（高/中/低）。MVP の優先順位判断の材料。今は仮で可。
+後続参照: 05-user-stories.md の各ストーリーは「ペルソナ」列で P-XXX を参照し、本表と紐づける。
+         a-006 レビューが「US の役割 → 本表」の trace を検証する。
+-->
+
+| ペルソナID | 種別 | 役割・ひとこと | ゴール（Job） | 主な課題・ペイン | 利用文脈 | ニーズの強さ（任意） |
+|---|---|---|---|---|---|---|
+| <!-- P-001 --> | <!-- 主要 --> | <!-- 例: 入社3ヶ月以内の新入社員 --> | <!-- 例: 早くチームに馴染みたい --> | <!-- 例: 誰に何を聞けばよいか分からない --> | <!-- 例: 入社直後・リモート・週数回 --> | <!-- 高/中/低 --> |
+
+**例:**
+
+| ペルソナID | 種別 | 役割・ひとこと | ゴール（Job） | 主な課題・ペイン | 利用文脈 | ニーズの強さ（任意） |
+|---|---|---|---|---|---|---|
+| P-001 | 主要 | 入社3ヶ月以内の新入社員 | 早くチームに馴染み、誰に何を聞けるか把握したい | 社内に知り合いが少なく孤立を感じる | 入社直後・リモート中心・PC/スマホで週数回 | 高 |
+| P-002 | 副次 | 受け入れ側のチームメンバー | 新人の人となりを早く知り接点を作りたい | 新人の興味・背景が見えず雑談の糸口がない | 新人受け入れ時・業務の合間 | 中 |
+
+## ステークホルダー / 決裁者 / 関心事
+
+<!--
+何を書くか: 誰が意思決定し、誰が影響を受け、それぞれ何を気にするか。
+-->
+
+| ステークホルダー | 役割 | 主な関心事 |
+|---|---|---|
+| <!-- 例: 人事部長 --> | <!-- 決裁者 --> | <!-- 例: 早期離職率の低減 --> |
+| <!-- 例: 情シス --> | <!-- 影響を受ける --> | <!-- 例: セキュリティ・運用負荷 --> |
+
+## 現在の代替手段・競合スキャン
+
+<!--
+何を書くか: ユーザーが今この課題をどうしのいでいるか（手作業・既存ツール・我慢）と、同じ課題を解く競合・類似プロダクト。
+なぜ重要か: 「安い代替手段で十分」なら、そもそも作らない判断につながる（MVP Scope で再検討）。各代替の「弱み」＝我々の付け入る隙。
+スコープ: MVP段階は主要な数件（2〜4件）まで。網羅・深追いはしない（YAGNI）。深いリサーチは別途。
+列の意味:
+  - 代替手段・競合: 具体名（手作業の手順 / ツール名 / プロダクト名）。
+  - 種別: 手作業/Workaround / 既製ツール / 競合プロダクト。
+  - 強み: その代替がなぜ今も使われているか。
+  - 弱み・不満（付け入る隙）: ユーザーが困っている点。ここが価値提案の起点になる。
+後続参照: 「価値提案 / 差別化」の Why us が本表の「弱み」と対応づく。
+         02-mvp-scope.md の「より安い代替手段」判定（a-002a）が本表を参照する。
+-->
+
+| 代替手段・競合 | 種別 | 強み | 弱み・不満（付け入る隙） |
+|---|---|---|---|
+| <!-- 例: Slack 自己紹介投稿 --> | <!-- 手作業/Workaround --> | <!-- 例: 全員が既に使える --> | <!-- 例: 投稿が流れて埋もれる --> |
+| <!-- 例: ◯◯（社内SNS SaaS） --> | <!-- 競合プロダクト --> | <!-- 例: プロフィール機能が充実 --> | <!-- 例: 高価・自社カルチャーに非対応 --> |
+
+**例:**
+
+| 代替手段・競合 | 種別 | 強み | 弱み・不満（付け入る隙） |
+|---|---|---|---|
+| オンライン歓迎会・Slack 自己紹介投稿 | 手作業/Workaround | 全員が既に使える・追加コスト無し | 投稿が流れて埋もれ、共通点が見つけにくい |
+| ◯◯（汎用社内SNS SaaS） | 競合プロダクト | プロフィール・タイムラインが充実 | 高価で、ライフラインによる共通点可視化に非対応 |
+
+## 価値提案 / 差別化
+
+<!--
+何を書くか:
+  1) バリュープロポジション（1文）: 誰の・どの課題を・どう解き・なぜ既存より良いか。穴埋め式で1文に凝縮する。
+  2) 差別化ポイント / Why us（最大3点）: 上の「現在の代替手段・競合スキャン」表の「弱み・不満」に対し、我々が何で勝つか。
+ベストプラクティス:
+  - 技術ではなくユーザー価値で書く（before/after が想像できる表現）。
+  - Why us は代替手段の弱みと1対1で対応づける（漠然と「使いやすい」ではなく、どの代替の何に勝つか）。
+スコープ: MVP段階は1文＋3点以内。過剰な訴求文づくりはしない（YAGNI）。
+後続参照: a-006 レビューが「価値提案 ↔ 解く課題 / 成功指標」の整合と、Domain Sketch の中核エンティティへの反映を検証する。
+-->
+
+**バリュープロポジション（1文）:**
+
+<!-- [誰] の [課題] を [解決方法] で解決する。[代替手段] と違い [なぜ良いか]。 -->
+
+**差別化ポイント / Why us:**
+
+- <!-- 例: 流れて消える投稿と違い、いつでも参照でき関係構築の起点になる -->
+- <!-- 例: 双方向コメントで関係が継続する（一方向の自己紹介で終わらない） -->
+
+**例:**
+
+> 新入社員（P-001）の「誰に何を聞けるか分からない孤立」を、ライフラインチャートによる共通点の可視化で解決する。流れて消える Slack 投稿や高価な汎用社内SNSと違い、いつでも参照でき・自社オンボーディングに最適化されている。
+
+- 共通点が一目で分かり会話のきっかけになる（Slack 投稿は流れて埋もれる）
+- 双方向コメントで関係が継続する（一方向の自己紹介投稿で終わらない）
+- 自社オンボーディング特化で安価（汎用 SaaS は高価・過剰機能）
+
+## Why now（なぜ今）
+
+<!--
+何を書くか: なぜ今このタイミングで作るのか（市場・組織・技術・コストの変化）。
+-->
+
+**例:**
+リモート比率が◯%に上昇し従来のオフライン施策が機能しなくなった。来期の大量採用前に仕組みを用意する必要がある。
+
+## 成功指標（North Star / KPI / Guardrail）
+
+<!--
+何を書くか: 成功をどう測るか。North Star は1つ。Guardrail は「悪化させてはいけない指標（失敗の許容ライン）」。
+計測方法: 各指標を「どこで・どう取れるか」（取得元・自動/手動・頻度）。今すぐ取れない指標は、測れる代理指標に置き換える。
+先行/遅行: KPI は先行（行動の早期シグナル。早く動く）/ 遅行（成果の確定値。遅れて出る）を区別すると健全。各1つずつ持つとよい。
+MVP段階: 目標値・計測方法は「仮説」で可。過剰な精緻化はしない（YAGNI）。実測が出たら更新する。
+後続参照: MVP Scope の各機能・PM Gate の Go/No-Go 判定がこの指標に紐づく。
+-->
+
+| 種別 | 指標 | 目標 | 計測方法（どこで / どう取得） |
+|---|---|---|---|
+| North Star | <!-- 例: 入社90日時点の社内つながり数 --> | <!-- 例: 平均◯人以上 --> | <!-- 例: 接点ログをDB集計・月次自動 --> |
+| KPI（先行） | <!-- 例: プロフィール作成率 --> | <!-- 例: 入社2週で◯% --> | <!-- 例: プロダクトDB・週次自動 --> |
+| KPI（遅行） | <!-- 例: 入社90日定着率 --> | <!-- 例: ◯%以上 --> | <!-- 例: 人事システム連携・四半期 --> |
+| Guardrail | <!-- 例: 個人情報に関する苦情 --> | <!-- 例: 0件を維持 --> | <!-- 例: 問い合わせ窓口の記録・随時 --> |
+
+## クリティカル制約
+
+<!--
+何を書くか: 守らねば成立しない制約のみ（網羅的な NFR ではない）。外すと作り直しになるものに絞る。
+            例: 法務・セキュリティ・個人情報・課金・固定期限・対応デバイス・外部 API・予算・運用。
+なぜ重要か: MVP の作り方を変えるほど重要な制約をここに集約する。
+            応答 200ms / 稼働率 99.9% のような定量 NFR は初期では当て推量になりやすいため、
+            ここには書かず設計フェーズ（/a-014-define-infrastructure）で詳細化する。
+後続参照: MVP Scope の Must 判定・PM Gate（a-006）が本セクションを SSoT として参照する。
+列の意味: 制約種別 / 内容 / MVP 判断への影響 / 回避策・緩和策 / 未確定時の確認先。
+-->
+
+| 制約種別 | 内容 | MVP判断への影響 | 回避策・緩和策 | 未確定時の確認先 |
+|---|---|---|---|---|
+| <!-- 例: セキュリティ --> | <!-- 例: 社内 SSO(SAML) 必須・社外公開不可 --> | <!-- 例: 認証は SSO 前提で設計 --> | <!-- 例: 初期は社内限定で回避 --> | <!-- 例: 情シス --> |
+| <!-- 例: 期限 --> | <!-- 例: 来期開始(◯月)までにリリース --> | <!-- 例: スコープを更に絞る判断材料 --> | <!-- 例: 段階リリース --> | <!-- 例: 人事部長 --> |
+
+## 非ゴール（このプロダクトが目指さないこと）
+
+<!--
+何を書くか: 明示的に「やらない」こと。スコープクリープ防止。
+後続参照: MVP Scope の Won't / PM Gate の過剰作り込みチェックの根拠になる。
+-->
+
+**例:**
+
+- 人事評価・勤怠管理は対象外（既存システムが担う）。
+- 社外向け SNS 機能は作らない。
+
+## 未確定事項（Open Questions）
+
+<!--
+何を書くか: まだ答えが出ていない論点・確認待ち事項。空欄で放置せずここに集約する。
+-->
+
+**例:**
+
+- 既存社員のプロフィール移行をどこまで行うか未定。
+- North Star の測定方法（手動集計 / 自動）を要確認。

package/templates/project/01-requirements/02-mvp-scope.md

@@ -0,0 +1,64 @@
+# MVP Scope
+
+<!--
+何のドキュメントか: 「本当に必要なものだけ作る」ための MVP スコープ確定資料。
+                    候補機能を Must / Not Now / Won't に切り分け、各 Must を課題・仮説・成功指標に紐づけて正当化する。
+
+使い方:
+  - 入力は `01-product-brief.md`（課題・ターゲット・成功指標・非ゴール）と `03-parking-lot.md`（アイデア backlog）。
+  - 「機能を並べる」ではなく「削る」ための資料。迷ったら Not Now / Won't に倒す。
+  - Must は「価値検証に不可欠なもの」だけ。1つでも仮説・指標に紐づかない Must は過剰作り込み候補。
+  - 「より安い代替手段（手作業・既存ツール・外部サービス）で足りるか」を必ず問う。足りるなら Must にしない。
+
+判定基準:
+  - Must:    この MVP の仮説検証に不可欠。これが無いと価値が成立しない。
+  - Not Now: 価値はあるが今回は不要。次以降のバックログ（→ Parking Lot）。
+  - Won't:   このプロダクトとして明示的に作らない（→ Out of Scope）。
+-->
+
+## 検証する仮説（1〜3 個）
+
+<!--
+何を書くか: この MVP で検証したい仮説を 1〜3 個に絞る。多すぎる場合は MVP が大きすぎる兆候。
+形式: 「[ターゲット] は [課題] に対して [解決策] を使う／価値を感じる」を検証可能な形で。
+-->
+
+**例:**
+
+1. 新入社員は、ライフラインチャート型の自己紹介があれば、入社2週間以内に自発的にプロフィールを作成する（作成率で検証）。
+2. 共通点が可視化されると、新入社員は既存社員へ自分から話しかける（つながり数で検証）。
+
+## MVP Scope
+
+<!--
+各行 = 候補機能。MVP判定 列は Must / Not Now / Won't のいずれか。
+「解決する課題」「検証指標」は Product Brief の課題・成功指標を参照する（同じ言葉で書く）。
+「より安い代替手段」が十分なら、その機能は Must にしない（手作業・既存ツールで代替）。
+-->
+
+| 候補機能 | 対象ユーザー / Job | 解決する課題 | 検証したい仮説 | MVP判定 | 入れる理由 | 入れない場合の影響 | より安い代替手段 | 検証指標 |
+|---|---|---|---|---|---|---|---|---|
+| <!-- 機能名 --> | <!-- 誰の何の仕事 --> | <!-- Brief の課題参照 --> | <!-- 検証する仮説 --> | <!-- Must / Not Now / Won't --> | <!-- なぜ Day 1 に必要か --> | <!-- 無いと何が壊れるか --> | <!-- 手作業/既存ツール等 --> | <!-- どの KPI/Guardrail --> |
+
+---
+
+**例:**
+
+| 候補機能 | 対象ユーザー / Job | 解決する課題 | 検証したい仮説 | MVP判定 | 入れる理由 | 入れない場合の影響 | より安い代替手段 | 検証指標 |
+|---|---|---|---|---|---|---|---|---|
+| ライフラインチャート作成 | 新入社員 / 自己紹介する | 共通点が見つけにくい | 仮説1 | Must | これ自体が検証対象の中核 | 価値検証が成立しない | なし | プロフィール作成率 |
+| 共通点ハイライト | 新入社員 / 話す相手を探す | 接点を持ちにくい | 仮説2 | Must | つながり創出の主要動線 | つながり数を検証できない | なし | 90日つながり数 |
+| コメント機能 | 双方 / 反応する | 双方向対話が起きない | 仮説2 | Not Now | 閲覧だけで仮説検証は可能 | 初期検証には影響小 | Slack スレッドで代替 | （後続） |
+| 実績バッジ | 新入社員 / 自己表現 | — | — | Won't | 課題・仮説に紐づかない | なし | — | — |
+
+## Out of Scope（やらないこと / Won't）
+
+<!--
+何を書くか: このプロダクトとして「作らない」と明示合意するもの。理由を必ず添える（スコープクリープ防止）。
+Product Brief の「非ゴール」と整合させる。
+-->
+
+| 項目 | 作らない理由 |
+|---|---|
+| <!-- 例: 人事評価機能 --> | <!-- 既存システムが担う。本プロダクトの課題に無関係 --> |
+| <!-- 例: 社外公開プロフィール --> | <!-- セキュリティ制約。非ゴールに記載済み --> |

package/templates/project/01-requirements/03-parking-lot.md

@@ -0,0 +1,29 @@
+# Parking Lot（後回しバックログ）
+
+<!--
+何のドキュメントか: 今は MVP に「入れない」と判断したアイデア・要望の backlog。捨てずに保持し将来に備える。
+役割分担（重要）: MVP の取捨選択（Must / Not Now / Won't と優先順位付け）は 02-mvp-scope.md（/a-002a）が正。
+                  本書は Not Now / Won't や未判断のアイデアの「置き場」で、優先度は厳密に決めない。
+使い方:
+  - 機能 ID なし。ユーザーが認識できる機能単位で、価値（〜したい）中心に 1〜2 文で書く。
+  - MVP に昇格したら 02-mvp-scope.md へ移し本書から削除。不要判断したものも削除（理由は Git に残す）。
+  - 洗い出しのヒアリングは skills/a-002-initialize-project/reference/hearing-questions.md（手順5）を参照。
+-->
+
+| Category 1 | Category 2 | 機能名 | 説明 |
+|-----------|-----------|--------|------|
+| <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
+
+---
+
+**例:**
+
+| Category 1 | Category 2 | 機能名 | 説明 |
+|-----------|-----------|--------|------|
+| ユーザー管理 | 認証 | 二段階認証 | SMS/アプリでの二段階認証 |
+| ユーザー管理 | 認証 | ソーシャルログイン | Google/GitHubアカウントでログイン |
+| ユーザー管理 | プロフィール | バッジシステム | 実績に応じたバッジ表示 |
+| コンテンツ | 投稿 | 下書き保存 | 記事の下書き保存機能 |
+| コンテンツ | 投稿 | 予約投稿 | 指定日時での自動投稿 |
+| コンテンツ | コメント | 返信機能 | コメントへの返信スレッド |
+| コンテンツ | コメント | いいね機能 | コメントへのいいね |