@k2works/claude-code-booster 3.4.1 → 3.6.0

package/lib/assets/.claude/skills/developing-frontend/SKILL.md

@@ -1,93 +1,93 @@
----
-name: developing-frontend
-description: フロントエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとアウトサイドインアプローチで品質の高い UI を実装する。「フロントエンドを実装したい」「画面を作りたい」「コンポーネントを追加したい」「フロントエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、UI の振る舞いを自動テストで保証し、安全なリファクタリングを可能にする。
----
-
-# フロントエンド開発
-
-TDD サイクルに従いフロントエンドを開発する。アウトサイドインアプローチ（UI 層→ロジック層→データ層）で、ユーザー視点から内側へ段階的に構築する。
-
-アウトサイドインの利点は、ユーザーが実際に操作する画面から始めるため、不要な機能を作らずに済むこと。テストがユーザーの振る舞いに基づくため、実装の詳細に依存しにくい。
-
-## 参照ドキュメント
-
-| 種類 | パス |
-|------|------|
-| ワークフロー | @docs/reference/コーディングとテストガイド.md |
-| アーキテクチャ | @docs/design/architecture_frontend.md |
-| UI 設計 | @docs/design/ui-design.md |
-| 技術スタック | @docs/design/tech_stack.md |
-| テスト戦略 | @docs/design/test_strategy.md |
-
-## TDD サイクル
-
-10-15 分で 1 サイクルを完了させる。サイクルが長引くなら、タスクの粒度が大きすぎる。
-
-1. **Red**: 失敗するテストを最初に書く
-2. **Green**: テストを通す最小限のコードを実装する
-3. **Refactor**: 重複を除去し設計を改善する
-
-## アプローチ
-
-- **アウトサイドイン**（推奨）: UI から開始しロジックを段階的に実装する
-- **インサイドアウト**: ユーティリティ/hooks から開始し上位層へ展開する
-
-## テストコマンド
-
-```bash
-# 全テスト実行
-cd apps/frontend && npm run test
-
-# ウォッチモードでテスト実行
-cd apps/frontend && npm run test:watch
-
-# テストカバレッジ確認
-cd apps/frontend && npm run test:coverage
-
-# E2E テスト実行
-cd apps/frontend && npm run test:e2e
-```
-
-## 品質チェックリスト
-
-コミット前に必ず確認する。
-
-- [ ] すべてのテストがパス
-- [ ] ESLint の警告がゼロ
-- [ ] テストカバレッジが目標を満たしている
-- [ ] 単一の論理的作業単位を表現
-- [ ] コミットメッセージが変更内容を明確に説明
-
-## 途中から再開
-
-開発セッションの途中から再開する場合は、まず現在のテスト状態を確認する。
-
-**Example:**
-
-```
-ユーザー: 「ログイン画面のコンポーネントは作った。バリデーションを追加したい」
-回答: 既存テストを実行して Green 状態を確認する。
-      バリデーションの失敗するテスト（Red）を書いてから実装に進む。
-      ユーザーが不正な入力をした場合のエラー表示をテストする。
-```
-
-## コンテキスト管理
-
-タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
-
-- TDD サイクルを数回繰り返した後、コンポーネント完了時、コミット完了後に実施する
-- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
-
-## 注意事項
-
-- Node.js/npm のテスト環境が設定済みであること（前提条件）
-- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
-- コミット前に必ず品質チェックリストを実行する
-- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
-- コンポーネントは単一責任の原則に従い小さく保つ。TODO 駆動で分割し、Rule of Three でリファクタリングする
-
-## 関連スキル
-
-- `developing-backend` — バックエンド TDD 開発
-- `orchestrating-development` — 開発フェーズ全体のワークフロー
-- `git-commit` — Conventional Commits 準拠のコミット
+---
+name: developing-frontend
+description: フロントエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとアウトサイドインアプローチで品質の高い UI を実装する。「フロントエンドを実装したい」「画面を作りたい」「コンポーネントを追加したい」「フロントエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、UI の振る舞いを自動テストで保証し、安全なリファクタリングを可能にする。
+---
+
+# フロントエンド開発
+
+TDD サイクルに従いフロントエンドを開発する。アウトサイドインアプローチ（UI 層→ロジック層→データ層）で、ユーザー視点から内側へ段階的に構築する。
+
+アウトサイドインの利点は、ユーザーが実際に操作する画面から始めるため、不要な機能を作らずに済むこと。テストがユーザーの振る舞いに基づくため、実装の詳細に依存しにくい。
+
+## 参照ドキュメント
+
+| 種類 | パス |
+|------|------|
+| ワークフロー | @docs/reference/コーディングとテストガイド.md |
+| アーキテクチャ | @docs/design/architecture_frontend.md |
+| UI 設計 | @docs/design/ui-design.md |
+| 技術スタック | @docs/design/tech_stack.md |
+| テスト戦略 | @docs/design/test_strategy.md |
+
+## TDD サイクル
+
+10-15 分で 1 サイクルを完了させる。サイクルが長引くなら、タスクの粒度が大きすぎる。
+
+1. **Red**: 失敗するテストを最初に書く
+2. **Green**: テストを通す最小限のコードを実装する
+3. **Refactor**: 重複を除去し設計を改善する
+
+## アプローチ
+
+- **アウトサイドイン**（推奨）: UI から開始しロジックを段階的に実装する
+- **インサイドアウト**: ユーティリティ/hooks から開始し上位層へ展開する
+
+## テストコマンド
+
+```bash
+# 全テスト実行
+cd apps/frontend && npm run test
+
+# ウォッチモードでテスト実行
+cd apps/frontend && npm run test:watch
+
+# テストカバレッジ確認
+cd apps/frontend && npm run test:coverage
+
+# E2E テスト実行
+cd apps/frontend && npm run test:e2e
+```
+
+## 品質チェックリスト
+
+コミット前に必ず確認する。
+
+- [ ] すべてのテストがパス
+- [ ] ESLint の警告がゼロ
+- [ ] テストカバレッジが目標を満たしている
+- [ ] 単一の論理的作業単位を表現
+- [ ] コミットメッセージが変更内容を明確に説明
+
+## 途中から再開
+
+開発セッションの途中から再開する場合は、まず現在のテスト状態を確認する。
+
+**Example:**
+
+```
+ユーザー: 「ログイン画面のコンポーネントは作った。バリデーションを追加したい」
+回答: 既存テストを実行して Green 状態を確認する。
+      バリデーションの失敗するテスト（Red）を書いてから実装に進む。
+      ユーザーが不正な入力をした場合のエラー表示をテストする。
+```
+
+## コンテキスト管理
+
+タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
+
+- TDD サイクルを数回繰り返した後、コンポーネント完了時、コミット完了後に実施する
+- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
+
+## 注意事項
+
+- Node.js/npm のテスト環境が設定済みであること（前提条件）
+- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
+- コミット前に必ず品質チェックリストを実行する
+- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
+- コンポーネントは単一責任の原則に従い小さく保つ。TODO 駆動で分割し、Rule of Three でリファクタリングする
+
+## 関連スキル
+
+- `developing-backend` — バックエンド TDD 開発
+- `orchestrating-development` — 開発フェーズ全体のワークフロー
+- `git-commit` — Conventional Commits 準拠のコミット

package/lib/assets/.claude/skills/developing-release/SKILL.md

@@ -1,120 +1,120 @@
----
-name: developing-release
-description: アプリケーションのリリースワークフローを一貫実行。品質ゲート→バージョンバンプ→CHANGELOG 生成→git commit + tag を自動化する。「リリースしたい」「バージョンを上げたい」「CHANGELOG を生成したい」「リリース前のチェックをしたい」といった場面で発動する。リリース手順を標準化することで、ヒューマンエラーを排除し、いつでも安全にリリースできる状態を維持する。
----
-
-# リリースワークフロー
-
-品質ゲート→バージョンバンプ→CHANGELOG 生成→git commit + tag を一貫して実行する。
-
-リリースを自動化する価値は「いつでもリリースできる」状態を維持すること。手作業によるミスを排除し、品質ゲートで最低品質を保証する。
-
-## 参照ドキュメント
-
-- @docs/reference/リリースガイド.md — リリースワークフロー全体
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | ドライランを実行（デフォルト） |
-| `--dry-run` | CHANGELOG プレビュー + バージョン計算 |
-| `--patch` | パッチリリース（バグ修正） |
-| `--minor` | マイナーリリース（新機能追加、後方互換あり） |
-| `--major` | メジャーリリース（破壊的変更） |
-| `--preflight` | 品質ゲートのみ実行 |
-| `--deploy` | リリース + デプロイ（`--patch` / `--minor` / `--major` と併用） |
-
-## リリースフロー
-
-1. **ドライラン**: CHANGELOG プレビューとバージョン計算を確認する
-2. **リリース種別選択**: patch / minor / major を選択する
-3. **品質ゲート（preflight）**: 全チェックを通過する
-4. **リリース実行**: バージョンバンプ→CHANGELOG 生成→commit + tag
-5. **リモートプッシュ**: コミットとタグをプッシュする
-6. **プルリクエスト作成**: リリースブランチからメインブランチへの PR を作成し、CHANGELOG の差分をレビューする
-7. **デプロイ**: 必要に応じて本番デプロイを実行する
-
-## 品質ゲート（preflight）
-
-リリース前に以下のチェックを直列実行する。全チェック通過が必須。
-
-| チェック | コマンド | 内容 |
-| :--- | :--- | :--- |
-| working tree クリーン | `release:preflight:clean` | 未コミット変更がないこと |
-| 静的解析 | `release:preflight:lint` | lint エラーがないこと |
-| ユニットテスト | `release:preflight:test` | 全テストパス |
-| ビルド確認 | `release:preflight:build` | ビルド成功 |
-| E2E テスト | `release:preflight:e2e` | E2E テスト全パス |
-
-## バージョニング規則
-
-[Semantic Versioning](https://semver.org/) に従う。
-
-| 種類 | 変更例 | バージョン変化 |
-| :--- | :--- | :--- |
-| `patch` | バグ修正、軽微な改善 | `0.1.0` → `0.1.1` |
-| `minor` | 新機能追加（後方互換あり） | `0.1.0` → `0.2.0` |
-| `major` | 破壊的変更 | `0.1.0` → `1.0.0` |
-
-モノレポ構成の場合、全パッケージのバージョンを同期管理する。
-
-## CHANGELOG 生成ルール
-
-[Conventional Commits](https://www.conventionalcommits.org/) に基づいて自動生成する。
-
-| prefix | カテゴリ |
-| :--- | :--- |
-| `feat` | Features |
-| `fix` | Bug Fixes |
-| `docs` | Documentation |
-| `refactor` | Refactoring |
-| `test` | Tests |
-| `chore` / `perf` / `ci` / `style` / `build` | その他 |
-
-直近の git tag から HEAD までのコミットを対象とする。タグが存在しない場合は全コミット履歴を対象とする。
-
-## リリース実行ステップ
-
-| ステップ | 内容 |
-| :--- | :--- |
-| [1/4] バージョン更新 | セマンティックバージョニングに従って更新 |
-| [2/4] CHANGELOG 生成 | コミットを分類し CHANGELOG.md を生成 |
-| [3/4] git commit + tag | `release: vX.X.X` でコミット→`vX.X.X` タグ作成 |
-| [4/4] サマリー表示 | バージョン変化、タグ名、次のステップを表示 |
-
-## 途中から再開
-
-リリース作業の途中から再開する場合は、現在の状態を確認する。
-
-**Example:**
-
-```
-ユーザー: 「品質ゲートは通った。リリースを実行したい」
-回答: --preflight の結果を確認し、全チェック通過を検証する。
-      --patch / --minor / --major のいずれかでリリースを実行する。
-```
-
-## トラブルシューティング
-
-- **working tree がクリーンでない**: 変更をコミットまたは `git stash` してからリリース再実行する
-- **テスト失敗**: テストを修正してからリリースを再実行する
-- **リリースを元に戻したい**: リモートプッシュ前なら `git tag -d vX.X.X && git reset --hard HEAD~1`
-
-## コンテキスト管理
-
-品質ゲート完了後、CHANGELOG 生成後、リリースコミット完了後に `/compact` を実施する。
-
-## 注意事項
-
-- ビルドツール・パッケージマネージャーがセットアップ済み、依存関係インストール済みであること（前提条件）
-- working tree がクリーンでないとリリース不可
-- リリース前に必ずドライランで内容を確認する
-- Conventional Commits でコミットメッセージを記述し CHANGELOG の品質を確保する
-
-## 関連スキル
-
-- `git-commit` — Conventional Commits 準拠のコミット作成
-- `managing-operations` — デプロイ・運用管理
-- `planning-releases` — リリース・イテレーション計画
-- `orchestrating-development` — 開発フェーズ全体のワークフロー
+---
+name: developing-release
+description: アプリケーションのリリースワークフローを一貫実行。品質ゲート→バージョンバンプ→CHANGELOG 生成→git commit + tag を自動化する。「リリースしたい」「バージョンを上げたい」「CHANGELOG を生成したい」「リリース前のチェックをしたい」といった場面で発動する。リリース手順を標準化することで、ヒューマンエラーを排除し、いつでも安全にリリースできる状態を維持する。
+---
+
+# リリースワークフロー
+
+品質ゲート→バージョンバンプ→CHANGELOG 生成→git commit + tag を一貫して実行する。
+
+リリースを自動化する価値は「いつでもリリースできる」状態を維持すること。手作業によるミスを排除し、品質ゲートで最低品質を保証する。
+
+## 参照ドキュメント
+
+- @docs/reference/リリースガイド.md — リリースワークフロー全体
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | ドライランを実行（デフォルト） |
+| `--dry-run` | CHANGELOG プレビュー + バージョン計算 |
+| `--patch` | パッチリリース（バグ修正） |
+| `--minor` | マイナーリリース（新機能追加、後方互換あり） |
+| `--major` | メジャーリリース（破壊的変更） |
+| `--preflight` | 品質ゲートのみ実行 |
+| `--deploy` | リリース + デプロイ（`--patch` / `--minor` / `--major` と併用） |
+
+## リリースフロー
+
+1. **ドライラン**: CHANGELOG プレビューとバージョン計算を確認する
+2. **リリース種別選択**: patch / minor / major を選択する
+3. **品質ゲート（preflight）**: 全チェックを通過する
+4. **リリース実行**: バージョンバンプ→CHANGELOG 生成→commit + tag
+5. **リモートプッシュ**: コミットとタグをプッシュする
+6. **プルリクエスト作成**: リリースブランチからメインブランチへの PR を作成し、CHANGELOG の差分をレビューする
+7. **デプロイ**: 必要に応じて本番デプロイを実行する
+
+## 品質ゲート（preflight）
+
+リリース前に以下のチェックを直列実行する。全チェック通過が必須。
+
+| チェック | コマンド | 内容 |
+| :--- | :--- | :--- |
+| working tree クリーン | `release:preflight:clean` | 未コミット変更がないこと |
+| 静的解析 | `release:preflight:lint` | lint エラーがないこと |
+| ユニットテスト | `release:preflight:test` | 全テストパス |
+| ビルド確認 | `release:preflight:build` | ビルド成功 |
+| E2E テスト | `release:preflight:e2e` | E2E テスト全パス |
+
+## バージョニング規則
+
+[Semantic Versioning](https://semver.org/) に従う。
+
+| 種類 | 変更例 | バージョン変化 |
+| :--- | :--- | :--- |
+| `patch` | バグ修正、軽微な改善 | `0.1.0` → `0.1.1` |
+| `minor` | 新機能追加（後方互換あり） | `0.1.0` → `0.2.0` |
+| `major` | 破壊的変更 | `0.1.0` → `1.0.0` |
+
+モノレポ構成の場合、全パッケージのバージョンを同期管理する。
+
+## CHANGELOG 生成ルール
+
+[Conventional Commits](https://www.conventionalcommits.org/) に基づいて自動生成する。
+
+| prefix | カテゴリ |
+| :--- | :--- |
+| `feat` | Features |
+| `fix` | Bug Fixes |
+| `docs` | Documentation |
+| `refactor` | Refactoring |
+| `test` | Tests |
+| `chore` / `perf` / `ci` / `style` / `build` | その他 |
+
+直近の git tag から HEAD までのコミットを対象とする。タグが存在しない場合は全コミット履歴を対象とする。
+
+## リリース実行ステップ
+
+| ステップ | 内容 |
+| :--- | :--- |
+| [1/4] バージョン更新 | セマンティックバージョニングに従って更新 |
+| [2/4] CHANGELOG 生成 | コミットを分類し CHANGELOG.md を生成 |
+| [3/4] git commit + tag | `release: vX.X.X` でコミット→`vX.X.X` タグ作成 |
+| [4/4] サマリー表示 | バージョン変化、タグ名、次のステップを表示 |
+
+## 途中から再開
+
+リリース作業の途中から再開する場合は、現在の状態を確認する。
+
+**Example:**
+
+```
+ユーザー: 「品質ゲートは通った。リリースを実行したい」
+回答: --preflight の結果を確認し、全チェック通過を検証する。
+      --patch / --minor / --major のいずれかでリリースを実行する。
+```
+
+## トラブルシューティング
+
+- **working tree がクリーンでない**: 変更をコミットまたは `git stash` してからリリース再実行する
+- **テスト失敗**: テストを修正してからリリースを再実行する
+- **リリースを元に戻したい**: リモートプッシュ前なら `git tag -d vX.X.X && git reset --hard HEAD~1`
+
+## コンテキスト管理
+
+品質ゲート完了後、CHANGELOG 生成後、リリースコミット完了後に `/compact` を実施する。
+
+## 注意事項
+
+- ビルドツール・パッケージマネージャーがセットアップ済み、依存関係インストール済みであること（前提条件）
+- working tree がクリーンでないとリリース不可
+- リリース前に必ずドライランで内容を確認する
+- Conventional Commits でコミットメッセージを記述し CHANGELOG の品質を確保する
+
+## 関連スキル
+
+- `git-commit` — Conventional Commits 準拠のコミット作成
+- `managing-operations` — デプロイ・運用管理
+- `planning-releases` — リリース・イテレーション計画
+- `orchestrating-development` — 開発フェーズ全体のワークフロー

package/lib/assets/.claude/skills/generating-slides/SKILL.md

@@ -1,94 +1,94 @@
----
-name: generating-slides
-description: インセプションデッキの Markdown から PowerPoint スライド（.pptx）を自動生成。pptxgenjs を使用し、テンプレート準拠の 12 枚構成プレゼンテーションを出力する。「スライドを生成したい」「インセプションデッキの pptx を作りたい」「プレゼン資料を出力したい」「スライドを更新したい」といった場面で発動する。Markdown から自動生成することで、内容更新のたびに手動でスライドを作り直す手間を排除する。
----
-
-# スライド生成
-
-インセプションデッキの Markdown ドキュメントから pptxgenjs を使用して PowerPoint スライド（.pptx）を生成する。テンプレートのスライド構成・テーマに準拠した 12 枚構成のプレゼンテーションを出力する。
-
-## 参照ドキュメントと成果物
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| テンプレート | @docs/template/インセプションデッキ.pptx | スライド構成のリファレンス（15 枚、4:3） |
-| 生成スクリプト | @.claude/scripts/generate-inception-deck.mjs | 内容の編集は可能 |
-| 入力 | @docs/strategy/inception-deck.md | `analyzing-inception-deck` の成果物 |
-| 入力（補足） | @docs/strategy/business_architecture.md | ビジネスアーキテクチャ分析書 |
-| 成果物 | `docs/strategy/slide/xxxxx_v0.1.0.pptx` | 生成された PowerPoint スライド |
-
-## スライド構成（12 枚）
-
-| # | スライドタイトル | SLIDE_DATA キー | データソース |
-| :--- | :--- | :--- | :--- |
-| 1 | タイトル | `titleSlide` | プロジェクト基本情報 |
-| 2 | 我われはなぜここにいるのか | `whyAreWeHere` | なぜやるのか？ |
-| 3 | エレベーターピッチ | `elevatorPitch` | どんなビジョンなのか？ |
-| 4 | どんな価値をもたらすのか？ | `values` | どんな価値をもたらすのか？ |
-| 5 | やらないことリスト | `scope` | スコープの範囲はどこか？ |
-| 6 | プロジェクトコミュニティ | `stakeholders` | 主なステークホルダーは？ |
-| 7 | 技術的な解決策の概要 | `technicalSolution` | 基本的な解決策 |
-| 8 | 夜も眠れなくなるような問題 | `risks` | 主なリスクは何か？ |
-| 9 | 俺たちの "A チーム" | `team` | どのくらい作業があり費用はいくらか？ |
-| 10 | 期間を見極める | `timeline` | 初回リリースはいつか？ |
-| 11 | トレードオフ・スライダー | `tradeoffs` | トレードオフにどう向き合うか？ |
-| 12 | 初回のリリースに必要なもの | `initialRelease` | MVP スコープ・リリース戦略 |
-
-## テーマ設定
-
-テンプレートから抽出したテーマに準拠する。
-
-- **フォント**: Yu Gothic（游ゴシック）— Windows / Mac 両対応
-- **テーマカラー**: ダークブルー `#333399`、ティール `#009999`、ライトティール `#BBE0E3`
-- **スライドサイズ**: 4:3（10" x 7.5"）
-
-## 生成の進め方
-
-### 新規生成
-
-1. `npm install pptxgenjs`（初回のみ）
-2. `docs/strategy/inception-deck.md` の内容を確認する
-3. `.claude/scripts/generate-inception-deck.mjs` の `SLIDE_DATA` をプロジェクト固有の内容に書き換える
-4. `node .claude/scripts/generate-inception-deck.mjs` を実行する
-5. `docs/strategy/slide/` に .pptx が生成されたことを確認する
-
-### 更新時の再生成
-
-1. `docs/strategy/inception-deck.md` の更新内容を確認する
-2. `.claude/scripts/generate-inception-deck.mjs` の `SLIDE_DATA` を更新する
-3. `node .claude/scripts/generate-inception-deck.mjs` を実行する
-
-## スクリプト構成
-
-| セクション | 内容 | 編集対象 |
-| :--- | :--- | :--- |
-| `SLIDE_DATA` | プロジェクト固有のデータ（テキスト・数値） | 毎回更新 |
-| テーマ設定 | カラー・フォント定義 | 通常変更不要 |
-| ヘルパー関数 | スライド部品の描画ロジック | 通常変更不要 |
-| スライド生成 | `SLIDE_DATA` を読み取り 12 枚を生成 | 通常変更不要 |
-
-## 途中から再開
-
-スライドの一部を修正したい場合は、`SLIDE_DATA` の該当キーのみを更新して再生成する。
-
-**Example:**
-
-```
-ユーザー: 「エレベーターピッチの内容が変わった。スライドを更新したい」
-回答: inception-deck.md の更新内容を確認し、
-      SLIDE_DATA.elevatorPitch のみを更新して再生成する。
-      出力ファイル名の meta.outputFileName のバージョンも更新する。
-```
-
-## 注意事項
-
-- `docs/strategy/inception-deck.md` が作成済みであること（`analyzing-inception-deck` を先に実行する）
-- テンプレート `docs/template/インセプションデッキ.pptx` は編集しない
-- 日本語フォントは Yu Gothic を使用する（Gill Sans 等の欧文フォントは文字化けする）
-- 出力ファイル名は `SLIDE_DATA.meta.outputFileName` で指定する。`meta.title` と同時に更新する
-- 生成後は PowerPoint で開いてレイアウトを目視確認し、必要に応じてスクリプトのレイアウトパラメータを微調整する
-
-## 関連スキル
-
-- `analyzing-inception-deck` — 入力となるインセプションデッキの作成
-- `analyzing-business` — ビジネスアーキテクチャ分析（補足情報の参照元）
+---
+name: generating-slides
+description: インセプションデッキの Markdown から PowerPoint スライド（.pptx）を自動生成。pptxgenjs を使用し、テンプレート準拠の 12 枚構成プレゼンテーションを出力する。「スライドを生成したい」「インセプションデッキの pptx を作りたい」「プレゼン資料を出力したい」「スライドを更新したい」といった場面で発動する。Markdown から自動生成することで、内容更新のたびに手動でスライドを作り直す手間を排除する。
+---
+
+# スライド生成
+
+インセプションデッキの Markdown ドキュメントから pptxgenjs を使用して PowerPoint スライド（.pptx）を生成する。テンプレートのスライド構成・テーマに準拠した 12 枚構成のプレゼンテーションを出力する。
+
+## 参照ドキュメントと成果物
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| テンプレート | @docs/template/インセプションデッキ.pptx | スライド構成のリファレンス（15 枚、4:3） |
+| 生成スクリプト | @.claude/scripts/generate-inception-deck.mjs | 内容の編集は可能 |
+| 入力 | @docs/strategy/inception-deck.md | `analyzing-inception-deck` の成果物 |
+| 入力（補足） | @docs/strategy/business_architecture.md | ビジネスアーキテクチャ分析書 |
+| 成果物 | `docs/strategy/slide/xxxxx_v0.1.0.pptx` | 生成された PowerPoint スライド |
+
+## スライド構成（12 枚）
+
+| # | スライドタイトル | SLIDE_DATA キー | データソース |
+| :--- | :--- | :--- | :--- |
+| 1 | タイトル | `titleSlide` | プロジェクト基本情報 |
+| 2 | 我われはなぜここにいるのか | `whyAreWeHere` | なぜやるのか？ |
+| 3 | エレベーターピッチ | `elevatorPitch` | どんなビジョンなのか？ |
+| 4 | どんな価値をもたらすのか？ | `values` | どんな価値をもたらすのか？ |
+| 5 | やらないことリスト | `scope` | スコープの範囲はどこか？ |
+| 6 | プロジェクトコミュニティ | `stakeholders` | 主なステークホルダーは？ |
+| 7 | 技術的な解決策の概要 | `technicalSolution` | 基本的な解決策 |
+| 8 | 夜も眠れなくなるような問題 | `risks` | 主なリスクは何か？ |
+| 9 | 俺たちの "A チーム" | `team` | どのくらい作業があり費用はいくらか？ |
+| 10 | 期間を見極める | `timeline` | 初回リリースはいつか？ |
+| 11 | トレードオフ・スライダー | `tradeoffs` | トレードオフにどう向き合うか？ |
+| 12 | 初回のリリースに必要なもの | `initialRelease` | MVP スコープ・リリース戦略 |
+
+## テーマ設定
+
+テンプレートから抽出したテーマに準拠する。
+
+- **フォント**: Yu Gothic（游ゴシック）— Windows / Mac 両対応
+- **テーマカラー**: ダークブルー `#333399`、ティール `#009999`、ライトティール `#BBE0E3`
+- **スライドサイズ**: 4:3（10" x 7.5"）
+
+## 生成の進め方
+
+### 新規生成
+
+1. `npm install pptxgenjs`（初回のみ）
+2. `docs/strategy/inception-deck.md` の内容を確認する
+3. `.claude/scripts/generate-inception-deck.mjs` の `SLIDE_DATA` をプロジェクト固有の内容に書き換える
+4. `node .claude/scripts/generate-inception-deck.mjs` を実行する
+5. `docs/strategy/slide/` に .pptx が生成されたことを確認する
+
+### 更新時の再生成
+
+1. `docs/strategy/inception-deck.md` の更新内容を確認する
+2. `.claude/scripts/generate-inception-deck.mjs` の `SLIDE_DATA` を更新する
+3. `node .claude/scripts/generate-inception-deck.mjs` を実行する
+
+## スクリプト構成
+
+| セクション | 内容 | 編集対象 |
+| :--- | :--- | :--- |
+| `SLIDE_DATA` | プロジェクト固有のデータ（テキスト・数値） | 毎回更新 |
+| テーマ設定 | カラー・フォント定義 | 通常変更不要 |
+| ヘルパー関数 | スライド部品の描画ロジック | 通常変更不要 |
+| スライド生成 | `SLIDE_DATA` を読み取り 12 枚を生成 | 通常変更不要 |
+
+## 途中から再開
+
+スライドの一部を修正したい場合は、`SLIDE_DATA` の該当キーのみを更新して再生成する。
+
+**Example:**
+
+```
+ユーザー: 「エレベーターピッチの内容が変わった。スライドを更新したい」
+回答: inception-deck.md の更新内容を確認し、
+      SLIDE_DATA.elevatorPitch のみを更新して再生成する。
+      出力ファイル名の meta.outputFileName のバージョンも更新する。
+```
+
+## 注意事項
+
+- `docs/strategy/inception-deck.md` が作成済みであること（`analyzing-inception-deck` を先に実行する）
+- テンプレート `docs/template/インセプションデッキ.pptx` は編集しない
+- 日本語フォントは Yu Gothic を使用する（Gill Sans 等の欧文フォントは文字化けする）
+- 出力ファイル名は `SLIDE_DATA.meta.outputFileName` で指定する。`meta.title` と同時に更新する
+- 生成後は PowerPoint で開いてレイアウトを目視確認し、必要に応じてスクリプトのレイアウトパラメータを微調整する
+
+## 関連スキル
+
+- `analyzing-inception-deck` — 入力となるインセプションデッキの作成
+- `analyzing-business` — ビジネスアーキテクチャ分析（補足情報の参照元）