# Create Pitch Deck > 事業企画の専門家として、アイデア・要件文書から PO 承認会向け企画提案スライドを 自己完結 HTML（フルスクリーン・キーボード操作・単一ファイル）で生成。 「ピッチデック作って」「企画スライドにまとめて」「プレゼン資料作って」「承認会用の 資料を作って」「勝ち筋を整理して」で使用。前半（前提と解釈・課題・解決アプローチ・ 対象範囲・勝ち筋）→後半（画面と操作の流れ・検証計画・承認いただきたい事項）の 10〜12枚可変構成。箇条書きは → キーでフラグメント（ステップ）ごとに出現し現在地が 強調される。画面と操作の流れは create-design-doc の wireframes/*.html を iframe で 実寸レンダリングし、ステップに合わせて対象要素をスポットライト表示する。両スキルは concept-brief.md を介して整合し、推奨実行順序は create-design-doc → create-pitch-deck。 PPTX は生成しない。 - Skill: `fandhe-ai/create-pitch-deck` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add fandhe-ai/create-pitch-deck` - Raw SKILL.md: https://api.skillmd.com/api/skills/fandhe-ai/create-pitch-deck/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: fandhe-ai (https://skillmd.com/u/fandhe-ai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fandhe-ai/create-pitch-deck --- # create-pitch-deck $ARGUMENTS で渡された入力文書（アイデア・要件文書）を読み、**事業企画の専門家**として PO （プロダクトオーナー）承認会向けの企画提案スライドを、自己完結 HTML（単一ファイル）として 生成する。 プロト開発の前に「なぜ必要か・どういう勝ち筋か」を分かりやすく捉えられるスライドを作り、 ユーザーのフィードバック・修正を挟むことで、期待値ずれを開発前に検出することが本スキルの 存在理由である。そのため成果物は必ず**冒頭に「前提と解釈」**、**末尾に「承認いただきたい 事項・確認事項」**を含む（詳細は後述の「スライド構成」節を参照）。 想定利用シーンは「ユーザーが PO で、AI が承認会に資料を持ってきて説明する」形。**前半で 解決する課題と解決方法、後半で具体的にどのような画面でどういう流れの操作になるのかを説明し、 PO から承認をもらう**という説明の流れを意識して構成する。**静的なレイアウトの模倣ではなく、 画面が実際に動き、説明テキストがそれと連動してハイライトされること**が品質の本質であり、 ブラウザでフルスクリーン表示し実際にキーボードで送りながら説明することを想定する。 ## ペルソナ 実行主体は事業企画の専門家として振る舞い、常に次を自問しながら作業する。 - なぜ今か（市場・タイミング） - 誰の・どんな痛みを解くか - 差別化・勝ち筋は何か。それは入力文書に根拠のある事実か、根拠のない仮説か - **PO に「この画面が・この場面で・こう使われる」と具体的に伝わる説明になっているか** - 検証（PoC）で何が分かっていて、何がまだ未検証か - 承認をもらう上で PO が判断に迷いそうな点は何か（承認事項・確認事項として明示する） ## 推奨実行タイミング アイデア文書と検証計画（PoC 結果を含む）が固まり、プロトタイプ／本開発に入る**前**が最適。 検証（PoC）の結果が出ていれば `winning.items[].label: "事実"` として反映できる。ビヘイビア・ 詳細仕様の定義を行うフローを持つ場合は、**その直前に本スキルを実行し、承認済みの資料を 仕様定義の入力にする**（承認後の手戻りを減らすため）。 ## 連携: create-design-doc との整合（concept-brief.md・推奨実行順序） 本スキルと `create-design-doc` は、共有合意文書 `concept-brief.md` を介して整合する （スキーマは [references/concept-brief-schema.md](references/concept-brief-schema.md)）。 企画（本スキル）とデザイン（`create-design-doc`）が別々に作った成果物で「言っていることが 食い違う」事態を防ぐための仕組みであり、両スキルとも同じ手順（Step 1・Step 9 相当）を持つ。 **推奨実行順序: `create-design-doc` → `create-pitch-deck`。** 本スキルの「画面と操作の 流れ」（`screen_flow`）スライドは `create-design-doc` が生成する `wireframes/*.html` を 実寸レンダリングして取り込むため、先に `create-design-doc` を実行しておく。 - **逆順で実行した場合**（本スキルを先に実行済み）: `screen_flow` はいったん `wireframe: null` ＋ `note: "create-design-doc 未実行のためテキスト概略のみ"` で生成する （Step 6 参照）。`create-design-doc` の実行後、本スキルを**画面素材が揃った状態で 再実行**する。deck spec の該当 `screen_flow` エントリの `wireframe` に実ファイルパスを 設定し `steps`（ハイライトしたい要素の CSS セレクタと説明文の配列）を追加すれば、 Step 7〜8 を再実行するだけで「動く画面デモ」が差し込まれる。 - 2スキルで確実に共有するには、両方の呼び出しで**同一の `--brief `** を明示指定する （既定値はスキルごとの成果物ディレクトリ直下で異なるため、指定なしでは自動的には共有 されない）。**`--brief` は入力文書ディレクトリ直下を指定することを推奨する**（例: `ideas//concept-brief.md`）。 ## 使い方 引数でアイデア・要件文書のパス（ディレクトリまたはファイル列挙）を渡す。無指定の場合は ユーザーに確認する。 - 出力先はユーザー指定がなければ `_/pitch-deck/.html` - `--theme dark|light` で配色テーマの明暗を切り替える（既定 `dark`。「没入感あるフル スクリーン・プレゼン」の空気感を保つため）。主色・アクセント等は spec の `brand` で concept-brief.md のトーン＆マナーに合わせて上書きする - `--brief ` で concept-brief.md の場所を指定できる（既定 `/concept-brief.md`。入力文書ディレクトリ直下の指定を推奨） - **大部な入力文書を読む際の優先順位**: ディレクトリを渡された場合、まず `README.md`（概要・ ステータス）→ 判定ゲート「判定」節（確定した結論）→ Go/No-Go 基準・成功基準の照合表 （`02-poc-plan.md` 等）の順に読み、その後に本文を読む - 利用例: アイデア検討フロー（`01-brainstorm.md` 〜 `03-poc/`）を入力とする場合、 `ideas//` をそのまま渡す ## スライド構成（前半固定＋後半可変・10〜12枚） **前半（固定・この順）**: 表紙 / **前提と解釈** / 課題 / 解決アプローチ / 対象範囲（In/Out） / **勝ち筋**。 **後半**: **画面と操作の流れ**（`screen_flow`、2〜4枚。シナリオの場面ごとに「この場面で・ この画面が・こう使われる」を説明）→ 検証計画・現在地 → **承認いただきたい事項・確認事項**。 各スライドの箇条書き・カード類は**フラグメント**として `→` キーで1つずつ出現し、尽きたら 次スライドへ進む（現在地は強調、既読は減光）。role・必須フィールド・順序契約・HTML の操作 仕様の詳細は [references/deck-spec.md](references/deck-spec.md) を、演出の設計思想は [references/presentation-patterns.md](references/presentation-patterns.md) を参照する。 ## フロー ### Step 1: concept-brief.md を確認する `--brief` で指定されたパス（既定 `/concept-brief.md`）を確認する。 - **存在する場合**: 必須入力として読む。Step 2 の文書読解の結果と矛盾を感じた場合、 concept-brief.md を無断で上書きせず、矛盾点を明示してユーザーに確認する。 - **存在しない場合**: Step 2 の文書読解を踏まえ、 [references/concept-brief-schema.md](references/concept-brief-schema.md) のテンプレート で起案する。各項目に出典を付ける。Step 4 の骨子確認と同時にユーザーへ提示し、承認を得て から確定版を書き出す。 ### Step 2: 入力文書を読解する 対象文書を読み、目的・要件概要・PoC 結果・未解決疑問点を把握する（優先順位は [使い方](#使い方)参照）。concept-brief.md の「プロダクトのトーン＆マナー」から、 spec の `brand`（`primary`/`accent` 等）と `--theme dark|light` の選択方針を決める。 ### Step 3: create-design-doc の成果物を探索する `create-design-doc` が先に実行され `wireframes/*.html` が生成済みかどうかを **Glob で 探索する**（既定パス `design/wireframes/*.html` を直書きで決め打ちしない。ユーザーが `--output` を変更している場合があるため）。見つかった場合は Step 6 の `screen_flow` 作成で 使う。見つからない場合は Step 6 でテキスト概略＋注記のみの `screen_flow` を作る。 ### Step 4: 骨子を提示しユーザー承認を得る（必須ゲート） 前半6枚のタイトル＋1行要旨、後半の `screen_flow` 各枚（シナリオ場面名・使う wireframe の 有無・ハイライトしたい要素の候補）、検証計画・承認事項の骨子、配色テーマ（`--theme` と 主色）、Step 1 の concept-brief.md 案（起案した場合）をまとめてユーザーに提示する。**承認を 得るまで Step 5 へ進まない**。無承認のまま生成しない。 ### Step 5: deck spec（JSON）を組み立てる [references/deck-spec.md](references/deck-spec.md) のスキーマに従い spec を作成する。 - 数値・事実は入力文書からの引用のみとする。捏造しない - `winning.items[].label` の `"事実"` は**入力文書に記録された実測・調査結果に限る**。留保 は `text` に併記する。それ以外の主張は必ず `"仮説"` にする（`事実` の item に含まれる 数値は自動でカウントアップ演出が付く） - `approval.items`（承認いただきたい事項・確認事項）は3〜5件。`kind: "承認"` は方針として 確定させたい事項、`kind: "確認"` は PO の判断を仰ぎたい事項に分ける - 各フラグメント（bullet・item）の文章量は少なめ・大胆にする（1メッセージ1フラグメント）。 長文はスライド内ではみ出す原因になる（Step 9 の validator が各フラグメント表示時点で検出 する） ### Step 6: screen_flow スライドを組み立てる シナリオの場面ごとに2〜4枚、次の方針で作成する。 - Step 3 で `wireframes/*.html` が見つかった場合: 場面に対応する wireframe ファイルを `wireframe` に **spec ファイルのディレクトリ配下への相対パス**で指定する（絶対パス・ `../` 脱出は `SpecError`。spec ディレクトリ配下に無い wireframe は `wireframes/` 等へ コピーしてから参照する）。`narrative` に導入文、`steps` に「ハイライトしたい要素の CSS セレクタ（`id`/`class` 等、wireframe の実装に存在するもの）」と「その要素が何を意味する 説明文」の配列（1件以上）を書く。ステップ送りに合わせて wireframe 内の対象要素が スポットライト表示され、対応する説明が強調される - 見つからない場合: `wireframe: null`、`note` に `"create-design-doc 未実行のためテキスト概略のみ"` 等を設定し、`narrative` にテキストの みで場面を概略する（この場合 `steps` は持たせない） ### Step 7: venv を用意し Playwright を導入する まず `python3` の存在を確認する。 ```bash command -v python3 >/dev/null || echo "python3 が見つからない" ``` 未導入の場合は処理を中止し、導入方法を案内する（macOS: `brew install python3`。その他の 環境: 各環境の公式セットアップ手順または環境管理者に確認する。権限昇格を要するコマンドは 案内しない）。 ```bash python3 -m venv "_/pitch-deck/.venv" 2>/dev/null || true "_/pitch-deck/.venv/bin/pip" install -q playwright "_/pitch-deck/.venv/bin/playwright" install chromium ``` グローバル環境を汚染しないよう、必ずスキル専用の venv へインストールする。venv の置き場所 （`_/pitch-deck/.venv`）はリポジトリ外の一時作業領域でもよく、パスは固定ではない。**既に 作成済みの venv（playwright 導入済み。`create-design-doc` 実行時に作った venv でもよい）が あれば再作成せず再利用してよい**（`pip install` は既存環境を壊さない冪等な操作のため、存在 確認せず実行しても害はない）。`playwright install chromium` はブラウザ本体（100MB超）を ダウンロードするため時間を要する。 以降のコマンド例では venv の Python を `"${PITCH_DECK_VENV_PY}"`（例: `_/pitch-deck/.venv/bin/python3`）として表記する。 ### Step 8: HTML スライドを生成する ```bash "${PITCH_DECK_VENV_PY}" "${CLAUDE_SKILL_DIR}/scripts/build_slides.py" \ --spec "" \ --output "" \ --theme dark ``` `${CLAUDE_SKILL_DIR}` が展開されない・未設定の環境では、本 SKILL.md ファイルが置かれて いるディレクトリの絶対パスに読み替える（例: `skills/create-pitch-deck`）。 `build_slides.py` は標準ライブラリのみで動作する（wireframe の埋め込みも Pillow 非依存。 `.screen_flow.wireframe` の自己完結性・inline JS 安全性をこの時点で検査する。wireframe 内の `