@k2works/claude-code-booster 4.13.0 → 4.14.0

package/lib/assets/.claude/skills/analyzing-data-model/SKILL.md

@@ -1,77 +1,77 @@
----
-name: analyzing-data-model
-description: PlantUML の ER 図を使用したデータモデル設計を支援。概念→論理データモデルの段階的設計とテーブル定義。「データモデルを設計したい」「ER 図を作りたい」「テーブル定義を作成したい」「データベース設計を始めたい」「正規化を検討したい」といった場面で発動する。データモデルを先に設計することで、実装時のテーブル設計の手戻りを防ぐ。
----
-
-# データモデル設計
-
-PlantUML の ER 図を使用して、概念データモデル→論理データモデルの順でデータモデルを設計する。
-
-データモデルはシステムの「記憶」を定義する設計。ドメインモデルが業務ロジックの構造を表すのに対し、データモデルはデータの永続化構造を定義する。両者の整合性がシステム全体の一貫性を保証する。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/データモデル設計ガイド.md | データモデル設計の進め方詳細 |
-| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
-| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
-| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
-| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
-| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
-| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
-| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
-| 成果物 | `docs/design/data-model.md` | データモデル設計 |
-
-## 概念データモデル作成
-
-業務の言葉でエンティティとリレーションシップを識別する。この段階では物理的な実装を考えない。ユースケースの「名詞」がエンティティ候補になる。
-
-- **エンティティの識別**: ユースケースとユーザーストーリーから管理対象を抽出する
-- **リレーションシップの定義**: エンティティ間の関係（1:1、1:N、N:N）を明確にする
-
-## 論理データモデル作成
-
-概念モデルを具体的なテーブル構造に落とし込む。正規化は第 3 正規形を基本とし、パフォーマンス要件に応じて非正規化を検討せよ。
-
-- **テーブル定義**: カラム名、データ型、制約を定義する
-- **主キー・外部キーの設計**: 識別子の戦略（自然キー/サロゲートキー）を決定する
-- **正規化の適用**: 第 3 正規形まで正規化し、必要に応じて非正規化の判断を記録する
-
-## ER 図作成
-
-PlantUML を使用して ER 図を作成する。テーブル間の関係を可視化することで、設計レビューの効率が上がる。
-
-## 作成の進め方
-
-1. 入力ドキュメント（要件定義、アーキテクチャ設計）を確認する
-2. @docs/reference/データモデル設計ガイド.md を読み込む
-3. 概念データモデル→論理データモデルの順に作成する
-4. ドメインモデルとの整合性を確認しながら `docs/design/data-model.md` として出力する
-
-## 途中から再開する場合
-
-既存の `docs/design/data-model.md` がある場合は、まずその内容を確認する。不足しているエンティティや更新が必要なリレーションシップのみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「概念モデルはできた。論理モデルを作りたい」
-回答: 既存の data-model.md の概念データモデルを確認し、
-      各エンティティのテーブル定義（カラム・データ型・制約）を作成する。
-      主キー・外部キーの設計を行い、ER 図を PlantUML で更新する。
-```
-
-## 注意事項
-
-- 要件定義とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
-- ER 図は必ず PlantUML で作成する。テキストベースの図はバージョン管理と差分レビューに適している
-- ドメインモデルとの整合性を常に確認する。データモデルとドメインモデルの乖離は実装時の混乱を招く
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
-- `analyzing-architecture` — 前段のアーキテクチャ設計
-- `analyzing-domain-model` — 並行して進めるドメインモデル設計
-- `analyzing-tech-stack` — 後続の技術スタック選定（DB 選定に影響）
+---
+name: analyzing-data-model
+description: PlantUML の ER 図を使用したデータモデル設計を支援。概念→論理データモデルの段階的設計とテーブル定義。「データモデルを設計したい」「ER 図を作りたい」「テーブル定義を作成したい」「データベース設計を始めたい」「正規化を検討したい」といった場面で発動する。データモデルを先に設計することで、実装時のテーブル設計の手戻りを防ぐ。
+---
+
+# データモデル設計
+
+PlantUML の ER 図を使用して、概念データモデル→論理データモデルの順でデータモデルを設計する。
+
+データモデルはシステムの「記憶」を定義する設計。ドメインモデルが業務ロジックの構造を表すのに対し、データモデルはデータの永続化構造を定義する。両者の整合性がシステム全体の一貫性を保証する。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/データモデル設計ガイド.md | データモデル設計の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/data-model.md` | データモデル設計 |
+
+## 概念データモデル作成
+
+業務の言葉でエンティティとリレーションシップを識別する。この段階では物理的な実装を考えない。ユースケースの「名詞」がエンティティ候補になる。
+
+- **エンティティの識別**: ユースケースとユーザーストーリーから管理対象を抽出する
+- **リレーションシップの定義**: エンティティ間の関係（1:1、1:N、N:N）を明確にする
+
+## 論理データモデル作成
+
+概念モデルを具体的なテーブル構造に落とし込む。正規化は第 3 正規形を基本とし、パフォーマンス要件に応じて非正規化を検討せよ。
+
+- **テーブル定義**: カラム名、データ型、制約を定義する
+- **主キー・外部キーの設計**: 識別子の戦略（自然キー/サロゲートキー）を決定する
+- **正規化の適用**: 第 3 正規形まで正規化し、必要に応じて非正規化の判断を記録する
+
+## ER 図作成
+
+PlantUML を使用して ER 図を作成する。テーブル間の関係を可視化することで、設計レビューの効率が上がる。
+
+## 作成の進め方
+
+1. 入力ドキュメント（要件定義、アーキテクチャ設計）を確認する
+2. @docs/reference/データモデル設計ガイド.md を読み込む
+3. 概念データモデル→論理データモデルの順に作成する
+4. ドメインモデルとの整合性を確認しながら `docs/design/data-model.md` として出力する
+
+## 途中から再開する場合
+
+既存の `docs/design/data-model.md` がある場合は、まずその内容を確認する。不足しているエンティティや更新が必要なリレーションシップのみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「概念モデルはできた。論理モデルを作りたい」
+回答: 既存の data-model.md の概念データモデルを確認し、
+      各エンティティのテーブル定義（カラム・データ型・制約）を作成する。
+      主キー・外部キーの設計を行い、ER 図を PlantUML で更新する。
+```
+
+## 注意事項
+
+- 要件定義とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
+- ER 図は必ず PlantUML で作成する。テキストベースの図はバージョン管理と差分レビューに適している
+- ドメインモデルとの整合性を常に確認する。データモデルとドメインモデルの乖離は実装時の混乱を招く
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-architecture` — 前段のアーキテクチャ設計
+- `analyzing-domain-model` — 並行して進めるドメインモデル設計
+- `analyzing-tech-stack` — 後続の技術スタック選定（DB 選定に影響）

package/lib/assets/.claude/skills/analyzing-domain-model/SKILL.md

@@ -1,117 +1,117 @@
----
-name: analyzing-domain-model
-description: DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。
----
-
-# ドメインモデル設計
-
-DDD（ドメイン駆動設計）の戦術的設計パターンに基づき、エンティティ・値オブジェクト・集約・ドメインサービスを設計する。
-
-ドメインモデルの価値は、業務の専門家と開発者が同じ言葉（ユビキタス言語）で会話できるようになること。モデルとコードが一致することで、「仕様と実装の乖離」という根本的な問題を解消する。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/ドメインモデル設計ガイド.md | ドメインモデル設計の進め方詳細 |
-| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
-| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
-| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
-| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
-| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
-| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
-| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
-| 成果物 | `docs/design/domain-model.md` | ドメインモデル設計 |
-
-## エンティティ定義
-
-ライフサイクルを持ち、識別子で区別されるドメインオブジェクトを識別する。「同じ属性値でも別のものとして扱う必要がある」ものがエンティティ。
-
-- **ライフサイクルを持つドメインオブジェクトの識別**: ユースケースの動詞（作成・更新・削除）の対象がエンティティ候補
-- **識別子の設計**: 自然キーかサロゲートキーかを決定する。ドメイン的に意味のある識別子があれば自然キーを優先せよ
-
-## 値オブジェクト定義
-
-不変で識別子を持たないドメインオブジェクトを識別する。「属性値が同じなら同じもの」として扱えるものが値オブジェクト。プリミティブ型の代わりに値オブジェクトを使うことで、バリデーションとドメイン知識をカプセル化する。
-
-- **不変オブジェクトの識別**: 金額、メールアドレス、住所などの業務概念を値オブジェクト化する
-- **バリデーションルールの定義**: 生成時にバリデーションを行い、不正な状態の値オブジェクトが存在できないようにする
-
-## 集約の設計
-
-トランザクション整合性の境界を定義する。集約が大きすぎると競合が発生し、小さすぎると整合性が保てない。適切な境界の見極めが最も重要。
-
-- **集約ルートの識別**: 外部からのアクセスポイントとなるエンティティを決定する
-- **集約境界の定義**: トランザクション整合性が必要な範囲を最小限にせよ
-- **不変条件の設計**: 集約内で常に満たすべきビジネスルールを明確にする
-
-## ドメインサービス定義
-
-エンティティにも値オブジェクトにも属さないビジネスロジックを識別する。ドメインサービスは動詞で命名し、ステートレスに保て。
-
-## ダイアグラム作成
-
-PlantUML を使用してクラス図・オブジェクト図を作成する。図はコードと同様にバージョン管理し、設計の変更を追跡可能にせよ。
-
-コンテキストの戦略的分類には Mermaid.js の Quadrant Chart を使用する。
-
-- **X 軸**: 競合他社との差別化（低い差別化 → 高い差別化）
-- **Y 軸**: 業務ロジックの複雑さ（低い複雑さ → 高い複雑さ）
-- **象限**（左上から時計回り）:
-  - quadrant-2（左上）: **一般** — 複雑だが差別化が低い（業界共通ロジック）
-  - quadrant-1（右上）: **中核** — 複雑かつ差別化が高い（Core Domain）
-  - quadrant-4（右下）: **補完** — 差別化はあるが複雑さは低い（Supporting Subdomain）
-  - quadrant-3（左下）: **一般または補完** — 複雑さも差別化も低い（Supporting/Generic  Subdomain）
-
-```mermaid
-quadrantChart
-    title 差別化の度合いと業務ロジックの複雑さによる業務領域の分類
-    x-axis "低い差別化" --> "高い差別化"
-    y-axis "低い複雑さ" --> "高い複雑さ"
-    quadrant-1 "中核"
-    quadrant-2 "一般"
-    quadrant-3 "一般または補完"
-    quadrant-4 "補完"
-    "Aコンテキスト": [0.75, 0.82]
-    "Bコンテキスト": [0.82, 0.68]
-    "Cコンテキスト": [0.62, 0.60]
-    "Dコンテキスト": [0.28, 0.42]
-    "Eコンテキスト": [0.65, 0.28]
-    "Fコンテキスト": [0.30, 0.65]
-    "Gコンテキスト": [0.18, 0.22]
-```
-
-## 作成の進め方
-
-1. 入力ドキュメント（要件定義、ユースケース、アーキテクチャ設計）を確認する
-2. @docs/reference/ドメインモデル設計ガイド.md を読み込む
-3. ユビキタス言語の用語集を作成し、エンティティ→値オブジェクト→集約→ドメインサービスの順に設計する
-4. 境界付けられたコンテキストを Mermaid.js Quadrant Chart で戦略的に分類し、概要セクションに追加する
-5. `docs/design/domain-model.md` として出力する
-
-## 途中から再開する場合
-
-既存の `docs/design/domain-model.md` がある場合は、まずその内容を確認する。不足しているドメインオブジェクトや集約境界の見直しが必要な部分のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「エンティティは識別した。集約の境界を決めたい」
-回答: 既存の domain-model.md のエンティティ一覧を確認し、
-      トランザクション整合性が必要な範囲を分析して集約境界を定義する。
-      集約ルートを決定し、不変条件を明記する。
-```
-
-## 注意事項
-
-- 要件定義とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
-- ダイアグラムは必ず PlantUML で作成する
-- ユビキタス言語を使用してドメインエキスパートと共通認識を持つ。コード上のクラス名・メソッド名もユビキタス言語に合わせよ
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
-- `analyzing-architecture` — 前段のアーキテクチャ設計
-- `analyzing-data-model` — 並行して進めるデータモデル設計
-- `analyzing-usecases` — 入力となるユースケース・ユーザーストーリー
+---
+name: analyzing-domain-model
+description: DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。
+---
+
+# ドメインモデル設計
+
+DDD（ドメイン駆動設計）の戦術的設計パターンに基づき、エンティティ・値オブジェクト・集約・ドメインサービスを設計する。
+
+ドメインモデルの価値は、業務の専門家と開発者が同じ言葉（ユビキタス言語）で会話できるようになること。モデルとコードが一致することで、「仕様と実装の乖離」という根本的な問題を解消する。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/ドメインモデル設計ガイド.md | ドメインモデル設計の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/domain-model.md` | ドメインモデル設計 |
+
+## エンティティ定義
+
+ライフサイクルを持ち、識別子で区別されるドメインオブジェクトを識別する。「同じ属性値でも別のものとして扱う必要がある」ものがエンティティ。
+
+- **ライフサイクルを持つドメインオブジェクトの識別**: ユースケースの動詞（作成・更新・削除）の対象がエンティティ候補
+- **識別子の設計**: 自然キーかサロゲートキーかを決定する。ドメイン的に意味のある識別子があれば自然キーを優先せよ
+
+## 値オブジェクト定義
+
+不変で識別子を持たないドメインオブジェクトを識別する。「属性値が同じなら同じもの」として扱えるものが値オブジェクト。プリミティブ型の代わりに値オブジェクトを使うことで、バリデーションとドメイン知識をカプセル化する。
+
+- **不変オブジェクトの識別**: 金額、メールアドレス、住所などの業務概念を値オブジェクト化する
+- **バリデーションルールの定義**: 生成時にバリデーションを行い、不正な状態の値オブジェクトが存在できないようにする
+
+## 集約の設計
+
+トランザクション整合性の境界を定義する。集約が大きすぎると競合が発生し、小さすぎると整合性が保てない。適切な境界の見極めが最も重要。
+
+- **集約ルートの識別**: 外部からのアクセスポイントとなるエンティティを決定する
+- **集約境界の定義**: トランザクション整合性が必要な範囲を最小限にせよ
+- **不変条件の設計**: 集約内で常に満たすべきビジネスルールを明確にする
+
+## ドメインサービス定義
+
+エンティティにも値オブジェクトにも属さないビジネスロジックを識別する。ドメインサービスは動詞で命名し、ステートレスに保て。
+
+## ダイアグラム作成
+
+PlantUML を使用してクラス図・オブジェクト図を作成する。図はコードと同様にバージョン管理し、設計の変更を追跡可能にせよ。
+
+コンテキストの戦略的分類には Mermaid.js の Quadrant Chart を使用する。
+
+- **X 軸**: 競合他社との差別化（低い差別化 → 高い差別化）
+- **Y 軸**: 業務ロジックの複雑さ（低い複雑さ → 高い複雑さ）
+- **象限**（左上から時計回り）:
+  - quadrant-2（左上）: **一般** — 複雑だが差別化が低い（業界共通ロジック）
+  - quadrant-1（右上）: **中核** — 複雑かつ差別化が高い（Core Domain）
+  - quadrant-4（右下）: **補完** — 差別化はあるが複雑さは低い（Supporting Subdomain）
+  - quadrant-3（左下）: **一般または補完** — 複雑さも差別化も低い（Supporting/Generic  Subdomain）
+
+```mermaid
+quadrantChart
+    title 差別化の度合いと業務ロジックの複雑さによる業務領域の分類
+    x-axis "低い差別化" --> "高い差別化"
+    y-axis "低い複雑さ" --> "高い複雑さ"
+    quadrant-1 "中核"
+    quadrant-2 "一般"
+    quadrant-3 "一般または補完"
+    quadrant-4 "補完"
+    "Aコンテキスト": [0.75, 0.82]
+    "Bコンテキスト": [0.82, 0.68]
+    "Cコンテキスト": [0.62, 0.60]
+    "Dコンテキスト": [0.28, 0.42]
+    "Eコンテキスト": [0.65, 0.28]
+    "Fコンテキスト": [0.30, 0.65]
+    "Gコンテキスト": [0.18, 0.22]
+```
+
+## 作成の進め方
+
+1. 入力ドキュメント（要件定義、ユースケース、アーキテクチャ設計）を確認する
+2. @docs/reference/ドメインモデル設計ガイド.md を読み込む
+3. ユビキタス言語の用語集を作成し、エンティティ→値オブジェクト→集約→ドメインサービスの順に設計する
+4. 境界付けられたコンテキストを Mermaid.js Quadrant Chart で戦略的に分類し、概要セクションに追加する
+5. `docs/design/domain-model.md` として出力する
+
+## 途中から再開する場合
+
+既存の `docs/design/domain-model.md` がある場合は、まずその内容を確認する。不足しているドメインオブジェクトや集約境界の見直しが必要な部分のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「エンティティは識別した。集約の境界を決めたい」
+回答: 既存の domain-model.md のエンティティ一覧を確認し、
+      トランザクション整合性が必要な範囲を分析して集約境界を定義する。
+      集約ルートを決定し、不変条件を明記する。
+```
+
+## 注意事項
+
+- 要件定義とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
+- ダイアグラムは必ず PlantUML で作成する
+- ユビキタス言語を使用してドメインエキスパートと共通認識を持つ。コード上のクラス名・メソッド名もユビキタス言語に合わせよ
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-architecture` — 前段のアーキテクチャ設計
+- `analyzing-data-model` — 並行して進めるデータモデル設計
+- `analyzing-usecases` — 入力となるユースケース・ユーザーストーリー

package/lib/assets/.claude/skills/analyzing-inception-deck/SKILL.md

@@ -1,84 +1,84 @@
----
-name: analyzing-inception-deck
-description: インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
----
-
-# インセプションデッキ作成
-
-プロジェクトの方向性・スコープ・リスク・トレードオフをチーム全体で共有するためのインセプションデッキを作成する。ビジネスアーキテクチャ分析書（`analyzing-business-architecture` の成果物）をもとに、10 の問いに回答する形式で整理する。
-
-インセプションデッキは「チーム全員が同じ方向を向く」ための道具であり、完璧な計画書ではない。不明点は仮定を明記し、後続のステークホルダーレビューで検証する方が、分析を止めるより効果的。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/開発ガイド.md | 開発ライフサイクルにおける位置づけ |
-| テンプレート | @docs/template/インセプションデッキ.md | 編集禁止。コピーして使用する |
-| 入力 | @docs/strategy/business_architecture.md | ビジネスアーキテクチャ分析書 |
-| 成果物 | `docs/strategy/inception-deck.md` | テンプレートを基に作成 |
-
-## 10 の問いと情報源
-
-ビジネスアーキテクチャ分析書から情報を抽出し、各問いに回答する。ビジネスアーキテクチャ分析書が未作成の場合は、プロジェクトの基本情報をヒアリングして直接回答する。
-
-| # | 問い | 主な情報源 |
-|---|------|-----------|
-| 1 | なぜやるのか？ | ケイパビリティヒートマップの低成熟度領域、バリューストリームのボトルネック |
-| 2 | どんなビジョンなのか？ | ビジネスプリンシプル、ガイディングプリンシプル、価値提案 |
-| 3 | どんな価値をもたらすのか？ | ビジネスモデルキャンバスの価値提案・主要活動 |
-| 4 | スコープの範囲はどこか？ | バリューストリーム、ケイパビリティマップ、ビジネスシナリオ |
-| 5 | 主なステークホルダーは？ | 組織マップ、ビジネスシナリオのアクター一覧 |
-| 6 | 基本的な解決策は？ | ガイディングプリンシプル（アプリケーション・データ・テクノロジー） |
-| 7 | 主なリスクは何か？ | ビジネス環境、組織体制、技術的制約 |
-| 8 | どのくらい作業があり費用はいくらか？ | 組織マップの人員構成、フィーチャの優先度 |
-| 9 | トレードオフにどう向き合うか？ | ビジネスプリンシプル（時間・予算・品質・スコープの優先度） |
-| 10 | 初回リリースはいつか？ | フェーズ分割に基づくマイルストーン |
-
-## 作成の進め方
-
-### 新規作成
-
-1. `docs/strategy/business_architecture.md` が存在するか確認する。存在しない場合は `analyzing-business-architecture` スキルを先に実行するか、基本情報をヒアリングする
-2. テンプレート（@docs/template/インセプションデッキ.md）を読み込む
-3. 10 の問いに順番に回答する。各問いの回答にはビジネスアーキテクチャ分析書からの根拠を示す
-4. 概念アーキテクチャ図を PlantUML で作成する（問い 6）
-5. マイルストーンの Gantt チャートを PlantUML で作成する（問い 10）
-6. `docs/strategy/inception-deck.md` として出力する
-
-### 途中から再開・更新
-
-既存の `docs/strategy/inception-deck.md` がある場合は、まずその内容を確認する。更新が必要な問いのみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「スコープが変わったのでインセプションデッキを更新したい」
-回答: 既存のインセプションデッキを読み込み、問い 4（スコープ）と
-      問い 8（作業量・費用）、問い 10（マイルストーン）を更新する。
-```
-
-## PlantUML の活用
-
-問い 6 と問い 10 では PlantUML を使って視覚的に表現する。図があることでチーム間の認識合わせが格段にスムーズになる。
-
-- **概念アーキテクチャ図**（問い 6）: コンポーネント図で主要なシステム要素と外部連携を示す
-- **マイルストーン Gantt チャート**（問い 10）: フェーズ分割と MVP リリースポイントを示す
-
-## スライド生成
-
-インセプションデッキの Markdown ドキュメントが完成したら、`generating-slides` スキルで PowerPoint スライドを生成できる。チームへのプレゼンテーション用に活用する。
-
-## 注意事項
-
-- ビジネスアーキテクチャ分析書が前提だが、未作成でもプロジェクト情報から直接作成可能。完璧な入力を待つより、仮定を置いて進める方が効果的
-- テンプレートは編集禁止。コピーして成果物を作成する
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `analyzing-business-architecture` — 前提となるビジネスアーキテクチャ分析（本スキルの入力を生成）
-- `analyzing-requirements` — 後続の要件定義（スコープを詳細化）
-- `generating-slides` — インセプションデッキの PowerPoint スライド生成
-- `planning-releases` — 後続のリリース計画（マイルストーンを詳細化）
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+---
+name: analyzing-inception-deck
+description: インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
+---
+
+# インセプションデッキ作成
+
+プロジェクトの方向性・スコープ・リスク・トレードオフをチーム全体で共有するためのインセプションデッキを作成する。ビジネスアーキテクチャ分析書（`analyzing-business-architecture` の成果物）をもとに、10 の問いに回答する形式で整理する。
+
+インセプションデッキは「チーム全員が同じ方向を向く」ための道具であり、完璧な計画書ではない。不明点は仮定を明記し、後続のステークホルダーレビューで検証する方が、分析を止めるより効果的。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/開発ガイド.md | 開発ライフサイクルにおける位置づけ |
+| テンプレート | @docs/template/インセプションデッキ.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/strategy/business_architecture.md | ビジネスアーキテクチャ分析書 |
+| 成果物 | `docs/strategy/inception-deck.md` | テンプレートを基に作成 |
+
+## 10 の問いと情報源
+
+ビジネスアーキテクチャ分析書から情報を抽出し、各問いに回答する。ビジネスアーキテクチャ分析書が未作成の場合は、プロジェクトの基本情報をヒアリングして直接回答する。
+
+| # | 問い | 主な情報源 |
+|---|------|-----------|
+| 1 | なぜやるのか？ | ケイパビリティヒートマップの低成熟度領域、バリューストリームのボトルネック |
+| 2 | どんなビジョンなのか？ | ビジネスプリンシプル、ガイディングプリンシプル、価値提案 |
+| 3 | どんな価値をもたらすのか？ | ビジネスモデルキャンバスの価値提案・主要活動 |
+| 4 | スコープの範囲はどこか？ | バリューストリーム、ケイパビリティマップ、ビジネスシナリオ |
+| 5 | 主なステークホルダーは？ | 組織マップ、ビジネスシナリオのアクター一覧 |
+| 6 | 基本的な解決策は？ | ガイディングプリンシプル（アプリケーション・データ・テクノロジー） |
+| 7 | 主なリスクは何か？ | ビジネス環境、組織体制、技術的制約 |
+| 8 | どのくらい作業があり費用はいくらか？ | 組織マップの人員構成、フィーチャの優先度 |
+| 9 | トレードオフにどう向き合うか？ | ビジネスプリンシプル（時間・予算・品質・スコープの優先度） |
+| 10 | 初回リリースはいつか？ | フェーズ分割に基づくマイルストーン |
+
+## 作成の進め方
+
+### 新規作成
+
+1. `docs/strategy/business_architecture.md` が存在するか確認する。存在しない場合は `analyzing-business-architecture` スキルを先に実行するか、基本情報をヒアリングする
+2. テンプレート（@docs/template/インセプションデッキ.md）を読み込む
+3. 10 の問いに順番に回答する。各問いの回答にはビジネスアーキテクチャ分析書からの根拠を示す
+4. 概念アーキテクチャ図を PlantUML で作成する（問い 6）
+5. マイルストーンの Gantt チャートを PlantUML で作成する（問い 10）
+6. `docs/strategy/inception-deck.md` として出力する
+
+### 途中から再開・更新
+
+既存の `docs/strategy/inception-deck.md` がある場合は、まずその内容を確認する。更新が必要な問いのみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「スコープが変わったのでインセプションデッキを更新したい」
+回答: 既存のインセプションデッキを読み込み、問い 4（スコープ）と
+      問い 8（作業量・費用）、問い 10（マイルストーン）を更新する。
+```
+
+## PlantUML の活用
+
+問い 6 と問い 10 では PlantUML を使って視覚的に表現する。図があることでチーム間の認識合わせが格段にスムーズになる。
+
+- **概念アーキテクチャ図**（問い 6）: コンポーネント図で主要なシステム要素と外部連携を示す
+- **マイルストーン Gantt チャート**（問い 10）: フェーズ分割と MVP リリースポイントを示す
+
+## スライド生成
+
+インセプションデッキの Markdown ドキュメントが完成したら、`generating-slides` スキルで PowerPoint スライドを生成できる。チームへのプレゼンテーション用に活用する。
+
+## 注意事項
+
+- ビジネスアーキテクチャ分析書が前提だが、未作成でもプロジェクト情報から直接作成可能。完璧な入力を待つより、仮定を置いて進める方が効果的
+- テンプレートは編集禁止。コピーして成果物を作成する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `analyzing-business-architecture` — 前提となるビジネスアーキテクチャ分析（本スキルの入力を生成）
+- `analyzing-requirements` — 後続の要件定義（スコープを詳細化）
+- `generating-slides` — インセプションデッキの PowerPoint スライド生成
+- `planning-releases` — 後続のリリース計画（マイルストーンを詳細化）
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内