create-pitch-deck

name	create-pitch-deck
description	事業企画の専門家として、アイデア・要件文書から PO 承認会向け企画提案スライドを 自己完結 HTML（フルスクリーン・キーボード操作・単一ファイル）で生成。 「ピッチデック作って」「企画スライドにまとめて」「プレゼン資料作って」「承認会用の 資料を作って」「勝ち筋を整理して」で使用。前半（前提と解釈・課題・解決アプローチ・ 対象範囲・勝ち筋）→後半（画面と操作の流れ・検証計画・承認いただきたい事項）の 10〜12枚可変構成。箇条書きは → キーでフラグメント（ステップ）ごとに出現し現在地が 強調される。画面と操作の流れは create-design-doc の wireframes/*.html を iframe で 実寸レンダリングし、ステップに合わせて対象要素をスポットライト表示する。両スキルは concept-brief.md を介して整合し、推奨実行順序は create-design-doc → create-pitch-deck。 PPTX は生成しない。
model	sonnet
user-invocable	true
argument-hint	<入力文書のパス> [--output <path.html>] [--theme dark|light] [--brief <path>]
tools	["Bash","Read","Write","Glob","Grep"]

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）。 企画（本スキル）とデザイン（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 <path> を明示指定する （既定値はスキルごとの成果物ディレクトリ直下で異なるため、指定なしでは自動的には共有 されない）。--brief は入力文書ディレクトリ直下を指定することを推奨する（例: ideas/<name>/concept-brief.md）。

使い方

引数でアイデア・要件文書のパス（ディレクトリまたはファイル列挙）を渡す。無指定の場合は ユーザーに確認する。

• 出力先はユーザー指定がなければ _/pitch-deck/<deck-name>.html
• --theme dark|light で配色テーマの明暗を切り替える（既定 dark。「没入感あるフル スクリーン・プレゼン」の空気感を保つため）。主色・アクセント等は spec の brand で concept-brief.md のトーン＆マナーに合わせて上書きする
• --brief <path> で concept-brief.md の場所を指定できる（既定 <output の親ディレクトリ>/concept-brief.md。入力文書ディレクトリ直下の指定を推奨）
• 大部な入力文書を読む際の優先順位: ディレクトリを渡された場合、まず README.md（概要・ ステータス）→ 判定ゲート「判定」節（確定した結論）→ Go/No-Go 基準・成功基準の照合表 （02-poc-plan.md 等）の順に読み、その後に本文を読む
• 利用例: アイデア検討フロー（01-brainstorm.md 〜 03-poc/）を入力とする場合、 ideas/<name>/ をそのまま渡す

スライド構成（前半固定＋後半可変・10〜12枚）

前半（固定・この順）: 表紙 / 前提と解釈 / 課題 / 解決アプローチ / 対象範囲（In/Out） / 勝ち筋。

後半: 画面と操作の流れ（screen_flow、2〜4枚。シナリオの場面ごとに「この場面で・ この画面が・こう使われる」を説明）→ 検証計画・現在地 → 承認いただきたい事項・確認事項。

各スライドの箇条書き・カード類はフラグメントとして → キーで1つずつ出現し、尽きたら 次スライドへ進む（現在地は強調、既読は減光）。role・必須フィールド・順序契約・HTML の操作 仕様の詳細は references/deck-spec.md を、演出の設計思想は references/presentation-patterns.md を参照する。

フロー

Step 1: concept-brief.md を確認する

--brief で指定されたパス（既定 <output の親ディレクトリ>/concept-brief.md）を確認する。

• 存在する場合: 必須入力として読む。Step 2 の文書読解の結果と矛盾を感じた場合、 concept-brief.md を無断で上書きせず、矛盾点を明示してユーザーに確認する。
• 存在しない場合: Step 2 の文書読解を踏まえ、 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 のスキーマに従い 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 の存在を確認する。

command -v python3 >/dev/null || echo "python3 が見つからない"

未導入の場合は処理を中止し、導入方法を案内する（macOS: brew install python3。その他の 環境: 各環境の公式セットアップ手順または環境管理者に確認する。権限昇格を要するコマンドは 案内しない）。

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 スライドを生成する

"${PITCH_DECK_VENV_PY}" "${CLAUDE_SKILL_DIR}/scripts/build_slides.py" \
  --spec "<deck-spec.json>" \
  --output "<output.html>" \
  --theme dark

${CLAUDE_SKILL_DIR} が展開されない・未設定の環境では、本 SKILL.md ファイルが置かれて いるディレクトリの絶対パスに読み替える（例: skills/create-pitch-deck）。

build_slides.py は標準ライブラリのみで動作する（wireframe の埋め込みも Pillow 非依存。 .screen_flow.wireframe の自己完結性・inline JS 安全性をこの時点で検査する。wireframe 内の <script> は全面禁止で、スポットライト演出は埋め込み時に注入される）ため、 Step 7 の venv は次の Step 9（Playwright 検証）のためのものである。

SpecError（終了コード1）で失敗した場合はエラーメッセージに従って spec または wireframe を 修正し再実行する。

Step 9: 検証する

"${PITCH_DECK_VENV_PY}" "${CLAUDE_SKILL_DIR}/scripts/validate_slides.py" \
  "<output.html>" --screenshots-dir "<output の親ディレクトリ>/screenshots"

FAIL の場合は spec または HTML を修正し、再生成してから validator を再実行する。PASS するまで完了扱いにしない。--screenshots-dir を指定すると全スライド・全フラグメント ステップの PNG（slide-<n>-step-<s>.png。フラグメント無しのスライドは slide-<n>-<role>.png）が確認用に出力される。

Step 10: concept-brief.md との相互整合チェック

生成した spec・成果物を concept-brief.md と照合する。

• 課題定義・ターゲットユーザー・スコープ・解決コンセプトに矛盾がないか
• create-design-doc の成果物（Step 3 で発見できた場合）と、勝ち筋と画面設計の整合／ スコープ外機能の混入／用語・呼称の不一致／課題と解決内容の対応漏れを横断確認する

矛盾を検出した場合は concept-brief.md・本スライドのいずれも自動修正せず、「concept-brief.md を直すか／本スライドを直すか」をユーザーに提示する。

Step 11: フィードバック反映ループ

ユーザーからのフィードバックを反映する場合は spec（必要なら concept-brief.md も）を修正し、 Step 8〜10 を再実行する。create-design-doc を後から実行した場合は Step 6 に戻って screen_flow の wireframe/steps を差し込む。

検証

生成後、必ず validator を実行し、以下の5段階ゲートで完了を確認する （.claude/rules/verification.md 準拠）。

1. 特定: validate_slides.py の実行と終了コードをもって完了とみなす
2. 実行: "${PITCH_DECK_VENV_PY}" "${CLAUDE_SKILL_DIR}/scripts/validate_slides.py" "<output.html>" --screenshots-dir "<dir>" を新規実行する
3. 読取: 出力全体（PASS/FAIL・失敗一覧）と終了コードを確認する。--screenshots-dir に 出力された主要ステップの PNG（特に screen_flow のスポットライト移動）を目視確認する
4. 検証: 失敗が0件であること、スクリーンショット目視で崩れ・ハイライト位置のズレが 無いこと、Step 10 の相互整合チェックで未解決の矛盾が無いことを確認する
5. 宣言: validator が PASS し、目視確認・相互整合チェックが済んだ場合のみ完了を宣言 する。「たぶん通る」等の推測で完了主張しない

validator（validate_slides.py）は最低限以下を確認する。

• スライド枚数・role の順序契約（DOM の data-role 属性）
• 全スライド・全フラグメントステップを実際に → キーで遷移させながら、表示中スライド 自身のはみ出し（scrollHeight/scrollWidth が clientHeight/clientWidth を超えて いないか）
• screen_flow の各ステップで iframe 内に期待した1件だけスポットライトが付与されているか （セレクタ不一致・解除漏れの検出）。iframe 内 HTML にも外部リソース参照・危険な JS パターンが無いか
• 外部リソース参照・inline JavaScript の禁止識別子（eval・innerHTML・network API 等。 window['eval'] のようなブラケット表記も部分文字列一致で検出）・inline handler が 親 HTML にゼロ件。wireframe（srcdoc）内の script はスポットライト注入スクリプトの 完全一致のみ許可
• 末尾の clamp・R での先頭復帰・クリックでの遷移・フラグメント0での ← 逆戻りが仕様 どおり動く
• 2枚目に「前提」、最終スライドに「承認」と3〜5件の承認・確認事項が含まれる
• @media print でナビゲーション要素が非表示になり、全フラグメントが表示状態になる

よくある失敗

問題	回避策
差別化ポイントを断定的に書いてしまう	入力文書に数値・実測の根拠が無い主張は必ず label: "仮説" にする。「事実」は記録された実測・調査結果に限る
スライド内でテキストがはみ出す	document.documentElement ではなく表示中の .slide 要素自身の overflow で検出される（html/body の overflow:hidden に隠れて documentElement 側は変化しない）。1フラグメントの文章量を減らす。フォントサイズは clamp() で調整済みだが無限には縮まない
screen_flow の steps[].selector が wireframe 内に存在しない	validator がスポットライト0件として検出する。wireframe の実装（id/class）を確認してから selector を書く
iframe を transform: scale() で縮小しても .slide がはみ出す	scale はレイアウト上の占有サイズを縮めない。スケール後の実寸に固定した overflow:hidden のラッパーで iframe を包む（build_slides.py の .screen-frame 実装を参照。踏襲する場合は変更しない）
承認事項が形骸化する	3〜5件を「PO に実際に判断・確認してほしい具体的な事項」にする。曖昧な依頼文にしない
Google スライドに取り込みたいと言われる	各スライド・各ステップの PNG（--screenshots-dir の出力）を Google スライドへ1枚ずつ画像として貼り付ける方法を案内する（本スキルは PPTX を生成しない）

注意事項

• 生成される HTML は単一ファイル・自己完結（CDN・外部フォント・外部画像参照なし。 screen_flow の wireframe は srcdoc として同一文書内に埋め込む）・10〜12枚可変構成 （固定8枚 + screen_flow 2〜4枚）
• role・必須フィールド・順序は references/deck-spec.md の契約
• venv はビルドツールであり生成物ではない。_/ 配下に置いた場合は commit しない（_/ は .gitignore 済み）
• レポート化対象に機密情報・非公開の実数値が含まれる場合、出力先が公開領域でないことを 事前にユーザーへ確認する
• 出力先ディレクトリ（_/pitch-deck/ 等）が存在しない場合は mkdir -p で作成してから 書き出す（build_slides.py は --output の親ディレクトリを自動作成する）

最終報告

完了時は簡潔に以下を報告する。

• 生成した HTML の絶対パス・ファイルサイズ・スライド枚数・--theme
• validation result（PASS/FAIL）
• --screenshots-dir の絶対パス（全ステップ PNG）
• concept-brief.md のパスと、新規起案／既存読込のいずれか
• create-design-doc 成果物の取り込み状況（wireframe 連動あり枚数／未実行のためテキスト のみの枚数）
• Step 10 の相互整合チェック結果（矛盾の有無）
• デッキの要旨を一文

例:

企画提案スライド（HTML）を生成しました:
<absolute-path>/pitch-deck.html（29KB、11枚、theme=dark）

Validation: PASS
スクリーンショット: <absolute-path>/screenshots/（36枚、ステップ単位）
concept-brief.md: <absolute-path>/concept-brief.md（既存読込）
画面と操作の流れ: 3枚中2枚は create-design-doc の wireframes/*.html を実寸連動、1枚は
create-design-doc 未実行のためテキスト概略のみ
相互整合チェック: create-design-doc の成果物と用語・スコープの矛盾なし
内容: 徒歩圏内おつかい代行という課題に対し、3画面で完結する解決アプローチを提案

参照ファイル

必要な場合だけ読む。

• references/deck-spec.md — deck spec（JSON）のスキーマ・スライド role・HTML の操作仕様・検証ルール
• references/presentation-patterns.md — フラグメント・スポットライト等の演出パターンの設計思想（参考サイトを精読し一般化したもの）
• references/concept-brief-schema.md — concept-brief.md のスキーマ（create-design-doc と共有）
• samples/pitch-deck-sample.json — deck spec の記入例（架空アイデア「おつかいパンダ便」。screen_flow の wireframe あり×2／なし×1を含む）
• samples/wireframes/ — サンプル spec が参照する埋め込み用ワイヤーフレーム

sandbox 環境での実行

このスキルの主要フロー（Step 1〜6、Step 8、Step 10〜11）は sandbox 環境で実行できる。 build_slides.py は標準ライブラリのみで完結しネットワークを使わない。ネットワークを要する のは Step 7 の pip install playwright と playwright install chromium（初回セットアップ 時のみ。導入済み venv を再利用する2回目以降は不要）、および Step 9 の Playwright 起動処理 （ローカル Chromium で file:// の HTML を操作するのみで外部通信は行わないが、初回の ブラウザダウンロードはネットワークを要する）。これらのコマンドのみ sandbox を無効にして 実行する。既定の出力先（_/pitch-deck/）・既定の brief パスはいずれもワークスペース内だが、 --output / --brief に絶対パスや ../ を含む相対パスを指定した場合はワークスペース外へ も書き込み得るため、その場合は出力先を自らの責任で選ぶこと。