slide-deck

/slide-deck — ブランドに沿った React デッキの作成、更新、変換、エクスポート

ユーザーのスライドシステムを使って、${SLIDE_DECK_REPO:-$HOME/code/your-slide-deck-site}/src/app/slides/<slug>/page.tsx に React/TypeScript デッキを作成します。ブランドに沿った出力（別途 HTML パイプラインは不要） — ポータブルな HTML/PDF が必要な場合、エクスポートモードでは Playwright を使ってレンダリング済みの React デッキをスナップショット化するため、ブランドを忠実に再現した出力になります。

モード（Step 1 の前に 1 つ選択）

モード	呼び出し方法	目的
new	/slide-deck new <topic>（デフォルト）	概要をもとに新しいデッキを作成
update	/slide-deck update <slug>	既存のデッキを修正（オーバーフロー対策あり）
ppt	/slide-deck ppt <path-to-pptx>	従来の PPTX を React デッキに変換
export	/slide-deck export <slug> [html|pdf|vercel]	デッキを HTML、PDF、または Vercel の URL にスナップショット化

update、ppt、export の場合は、該当するモードのセクションに進んでください。new の場合は、Step 1～8 に進んでください。

---

Step 1 — 概要を確認する（一度にすべて質問）

構成を整理したメッセージで、一度に質問します。個別に何度もやりとりしないでください。

1. トピック／タイトル — デッキのテーマは何ですか？
2. 対象者 — どのような人が参加しますか？（技術職／経営幹部／混合／クライアント）具体的に答えてもらいます。「創業者」では広すぎますが、「MicroConf に参加する B2B SaaS の創業者」なら十分具体的です。
3. 長さ — おおよそのスライド枚数：5～10 枚（ライトニングトーク／短い社内向け）／10～15 枚（短い基調講演、ピッチ）／20～25 枚（基調講演）／30 枚以上（ワークショップ — ブランドに沿ったデッキではまれ）。
4. 密度 — スピーカー主導（1 枚につき 1 つのアイデア、大きな文字、余白を多く取り、必要に応じてスライドを増やす）または 読者優先（1 枚につき 4～6 個の箇条書き、構成されたグリッド、非同期レビューでも内容が完結）。
5. CTA — 発表後、対象者に何をしてほしい／考えてほしい／感じてほしいですか？
6. スラッグ — ケバブケース（例：marketing-like-an-engineer）。
7. コンテンツの状態 — コンテンツはすべて準備済み／大まかなメモあり／トピックのみ。

密度を忘れずに考慮してください。スライド枚数、1 枚あたりのコピーの長さ、優先するプリミティブに影響します。密度ごとのルールについては references/narrative-and-voice.md を参照してください。

Step 2 — 3 つのストーリー展開案

zarazhangrui/frontend-slides の「見せて、語らない」を参考にします。ただし、ビジュアルではなく ストーリー に適用してください（ビジュアルシステムは固定です）。

それぞれ 1～2 文で、3 つの展開案を提示します。

• 無難な案 — 最も受け入れられやすい展開。対象者に合わせた一般的な構成です。
• 大胆な案 — 反対意見や直感に反する切り口。大きな成果が期待できる一方、多少のリスクがあります。
• 意外な案 — 予想外の構成（ストーリー優先、1 つの問いを軸にしたデッキ、反対命題など）。

ユーザーに 1 つ選んでもらいます。3 つとも却下された場合は、さらに 3 つ提案してください。無理に進めないでください。

Step 3 — 概要を作成する

選ばれた展開案について、次の項目を作成します。

1. セクション — 名前付きのセクションを 3～7 個提案します（例：Title、Hook、Problem、Framework、Examples、Close）。デフォルトの 3 幕構成は任意です。ユーザーが希望する場合、または基調講演の長さで 3 幕構成が効果的な場合にのみ使用してください。
2. 各セクション内のスライドタイトル
3. 各スライドの1 行の要点

スライドの合計枚数は、Step 1 で見積もった所要時間に合うようにします。

概要は表として提示します。展開する前に、ユーザーが編集／承認します。

ステップ 4 — スライドのコンテンツを展開する

各スライドについて、ユーザーのプリミティブを使って全コンテンツを書きます。プリミティブの語彙については references/system.md を、フックのパターンと語り口のルールについては references/narrative-and-voice.md を参照してください。

スライドの種類と適したプリミティブ：

スライドの種類	プリミティブ	パターン
タイトル	Eyebrow + <Accent> キーワードを含む <h1>	最初のスライド。ブランドとトピックを提示します
フック	Heading + Body	主張、物語の導入、逆説的な切り口、または具体的な統計
セクション区切り	Eyebrow + Heading（中央揃え、大きく）	セクション間の明確な区切り
フレームワーク	Heading + BulletList またはカスタムレイアウト	ユーザーが教えている内容
2 カラム	TwoCol	比較、ビフォー／アフター、問題／解決策
引用／抜粋引用	Body（大きく）	権威性を示す場面、または聴衆が自分ごととして感じる場面
リソース／リンク	Body + 独立した行に URL	外部へのリンク（まれに使用。ユーザーの語り口では最小限にする）
クロージング／CTA	Heading + Body + 次のステップ用の BulletList	聴衆にしてほしいこと

語り口の軸 — ページではなく、耳に届くように書く（詳しいルールについては narrative-and-voice.md を参照してください）：

• スライド資料は声に出して話すものです。 スライドのテキストも発表者ノートも、どちらも声に出して読まれます。普段話すように書いてください。
• 保存する前に、すべてのスライドを声に出して読みましょう。 つまずいたり、プレスリリースのように聞こえたりしたら、書き直してください。
• 短縮形をどこでも使います（don't、won't、you're、I'd）。読み物向けのスライド資料の場合に限り、短縮形を使わないようにします。
• 「あなた」と呼びかけます。「聴衆」「ユーザー」「人々」は使いません。
• 数字は自然な言い方にします（「23.7%」ではなく「4 分の 1」）。
• 確信のある語り口、聞き手の視点、短い文、具体的な名詞を使います。
• つなぎの言葉は使いません（「今日は……についてお話ししたいと思います」など）。主張から始めます。
• （読み物向けの密度モードの場合は例外です。スライドを声に出して話す人がいないため、書き言葉で構いません。詳しくは narrative-and-voice.md を参照してください。）

ステップ 5 — 発表者ノート

各スライドに 3～5 行のノートを付けます。ノートは話す内容のすべてです。間や余談も含め、実際に話すとおりに書いてください。スライドのテキストが見出しなら、ノートは考えをすべて伝える内容です。

ノートの構成：

1. 導入 — スライドが表示されたときに話すこと
2. 要点 — このスライドで伝える 1 つの考え
3. 補足 — 例、データ、または具体的な情報
4. つなぎ — 次のスライドへのつながり
5. （任意）余談 — 気の利いた一言や、前の話題への言及

タイトルスライドとセクション区切りでは、ノートは 2～3 行で構いません。

ステップ 6 — ファイルを生成する

${SLIDE_DECK_REPO:-$HOME/code/your-slide-deck-site}/src/app/slides/<slug>/ に書き込みます。

1. layout.tsx — <title> メタデータ（スライド資料のタイトルを使用）を含む Next.js レイアウト
2. page.tsx — スライド資料

ひな形として references/template.md のテンプレートを使います。

クロージングスライドのフッターに使う <AUTHOR_HANDLE> / <AUTHOR_SITE> トークンは、${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/slide-deck/identity.yaml（キー：handle、site）が存在する場合は、そこから取得します。存在しない場合は、ユーザーにハンドルとサイトを一度だけ尋ね、そこに保存するか確認してから、それらを使用します。フッターを付けたくない場合は、<p> を丸ごと削除してください。他人の情報を載せたスライド資料を決して公開しないでください。

page.tsx は次の条件を満たす必要があります。

• 先頭に "use client" がある
• @/components/slides/slide-deck から SlideDeck と Slide 型をインポートする
• （セクションを使用する場合のみ）@/components/slides/sections から SectionRange をインポートする
• ユーザーが使うプリミティブを @/components/slides/slide-primitives からインポートする
• const slides: Slide[] = [...] を宣言する
• （任意）from / to に 0 始まりのインデックスを指定して、const sections: SectionRange[] = [...] を宣言する
• <SlideDeck slides={slides} sections={sections} /> を返すコンポーネントをデフォルトエクスポートする

ステップ 7 — プレビュー

ファイルを書き込んだ後、スライド資料の開発サーバーが実行中か確認します。

lsof -i :3000-3099 2>/dev/null | grep -E "LISTEN" | head

ポートが使用中の場合（portless に対応。開発スクリプトの命名は package.json で確認してください）：

# Suggested URL pattern
echo "Preview at: http://${SLIDE_DECK_DEV_HOST:-localhost:3000}/slides/<slug>"

開発サーバーが実行されていない場合は、ユーザーに次のように伝えます。

cd ${SLIDE_DECK_REPO:-$HOME/code/your-slide-deck-site} && npm run dev
# then visit http://${SLIDE_DECK_DEV_HOST:-localhost:3000}/slides/<slug>

開発サーバーを自動で起動しないでください（ほかの作業に支障をきたす可能性があります）。

Step 8 — アーカイブ

アーカイブは ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/slide-deck/archive/ に保存します（ディレクトリがない場合は作成してください）。アーカイブをスキル自体のフォルダー内に保存しないでください。スキルのインストールやアップグレード時にソースから再同期され、そこに保存した内容がすべて消去されます。**移行：**このスキルのフォルダーにユーザーのエントリーを含む古い references/decks-archive.md がある場合は、まず <archive dir>/INDEX.md に移動してください。

<archive dir>/INDEX.md に1行追加します（ファイルがない場合は作成してください）。

- 2026-06-17 — [<title>](${SLIDE_DECK_REPO:-$HOME/code/your-slide-deck-site}/src/app/slides/<slug>/page.tsx) — <audience> — <one-line angle>

こうして蓄積された情報を活用すると、今後のデッキ作成時に「Xについてどんな講演をしたか」を検索して、内容の重複を避けたり、再利用できるパターンを見つけたりできます。

---

Mode: update

既存のデッキを壊さずに変更します。リスク：スライドからのはみ出し、密度制限の超過、セクション範囲の破損。

変更前に確認すること：

1. 既存の page.tsx を読みます
2. スライド数を数え、セクション範囲を特定します
3. 変更ごとに適切なガードを適用します。

変更	ガード
箇条書きの追加	BulletList ごとに、読解重視の場合は最大6項目、スピーカー主導の場合は最大3項目です。超える場合は、2枚のスライドに分割します。
テキストの追加	スピーカー主導の場合、<Body> の段落が2文を超える場合は分割します。読解重視の場合は5文を超える場合に分割します。
画像の追加	画像は1920×1080のステージ内に収める必要があります。スライドにすでに大量のコンテンツがある場合は、画像を独立したスライドに移動します。
スライドの追加	sections 配列を更新し、挿入位置より後のすべてのセクションの from／to を増やします。
スライドの削除	削除位置より後のセクションの from／to を減らします。参照先のない id に注意してください。
スライドの書き換え	（アンカーに使われる）id は保持します。content と notes のみ変更してください。

変更後：

• スライド数を再度数え、セクション範囲の合計が正しいことを確認します
• コミット前に、開発サーバーで表示を抜き取り確認します

---

Mode: ppt

従来のPPTX（クライアント向けデッキ、カンファレンステンプレート）をユーザーのReactシステムに変換します。

1. python3 と python-pptx を使ってコンテンツを抽出します。

   pip install python-pptx 2>/dev/null
   python3 -c "
   from pptx import Presentation
   import json, sys
   p = Presentation(sys.argv[1])
   out = []
   for i, s in enumerate(p.slides):
       title = next((sh.text for sh in s.shapes if sh.has_text_frame and sh.shapes_element.tag.endswith('}sp') == False), '')
       texts = [sh.text for sh in s.shapes if sh.has_text_frame]
       notes = s.notes_slide.notes_text_frame.text if s.has_notes_slide else ''
       out.append({'i': i, 'texts': texts, 'notes': notes})
   print(json.dumps(out, indent=2))
   " "<path-to-pptx>"
   

   抽出とマッピングの手順全体については、references/ppt-conversion.md を参照してください。

2. 抽出した概要をユーザーに提示します — スライドタイトル、コンテンツの抜粋、画像数を示します。続行する前に確認を取ってください。

3. Reactプリミティブにマッピングします：

   • 1枚目のスライド → タイトルパターン（Eyebrow + h1 + Accent）
   • 箇条書きのあるコンテンツスライド → Heading + BulletList
   • 比較スライド → TwoCol
   • セクション区切り（PPTXのタイトルのみのスライド）→ セクション区切りパターン
   • PPTXの発表者ノート → 各スライドの notes 配列

4. 画像 — PPTXアセットから参照画像を ${SLIDE_DECK_REPO:-$HOME/code/your-slide-deck-site}/public/slide-assets/<slug>/ にコピーし、content 内で <img src="/slide-assets/<slug>/<filename>" /> を使ってスライドから参照します。

5. 新規デッキのフロー（Step 6）に従って、page.tsx と layout.tsx を書きます。

6. 元のPPTXを保持します — 上書き変更しないでください。監査用に、元のファイルと抽出したJSONを ~/Documents/slide-conversions/<slug>-from-pptx/ に保存します。

---

モード：export

スライドサイトの開発サーバーでレンダリングされたデッキを、ポータブルな HTML／PDF／Vercel URL としてスナップショットします。実際にレンダリングされた React デッキのスクリーンショットを使うため、ブランドを忠実に再現できます。

出力形式：

• html — スナップショットをインラインの <img> として含み、キーボード操作（矢印キー）によるナビゲーションを組み込んだスタンドアロン HTML ファイル
• pdf — スライドのスナップショットをまとめたもの
• vercel — スタンドアロン HTML を Vercel プロジェクトにデプロイし、共有可能な URL を作成

フロー（詳細は references/export.md を参照）：

1. 開発サーバーを確認する：${SLIDE_DECK_DEV_HOST:-localhost:3000}/slides/<slug> が読み込まれることを確認します。読み込まれない場合は、ユーザーに cd ${SLIDE_DECK_REPO:-$HOME/code/your-slide-deck-site} && npm run dev を実行するよう案内します。
2. スライド数を数える：page.tsx を読み込み、slides 配列のエントリー数を数えます。
3. Playwright でスナップショットを取得する：

   bash references/export.md script: snapshot-deck <slug> <count>
   

   • ヘッドレス Chromium を 1920×1080 で起動します
   • http://${SLIDE_DECK_DEV_HOST:-localhost:3000}/slides/<slug>?present=1 を読み込みます（プレゼンターモードでは UI が非表示になります）
   • localStorage["slides:/slides/<slug>"] = "0" を設定して、スライド 0 から開始します
   • N 枚のスライドについて、スクリーンショットの撮影 → キーボードで ArrowRight を押す → 待機、を繰り返します
   • PNG を ~/Documents/slide-exports/<slug>-<YYYY-MM-DD>/slide-<n>.png に保存します
4. 出力形式ごとにまとめる：
   • html → スナップショットを、矢印キーでナビゲーションできる最小限の HTML シェルでラップします
   • pdf → magick（ImageMagick）または img2pdf を使って PNG をまとめます
   • vercel → vercel deploy ~/Documents/slide-exports/<slug>-<date>/
5. 結果を報告する：パス／URL を伝えます。

注意事項（ユーザーに伝えてください）：

• アニメーションとプレゼンタービューは保持されません。エクスポートは静的なスナップショットです。
• インタラクティブなデモには React 版をライブで表示し、共有／PDF／ポータブル版にはエクスポートを使います。
• スナップショットは 1920×1080 です。どのデバイスでも高画質ですが、ファイルサイズはスライド数に応じて大きくなります。

---

モード（簡易実行）

呼び出し	モード	動作
/slide-deck new <topic>	new	全工程（ステップ 1～8）
/slide-deck angles <topic>	new	ステップ 2 で停止（3 つの切り口のみ）
/slide-deck outline <topic>	new	ステップ 3 で停止（アウトラインのみ）
/slide-deck expand <slug>	new	既存のアウトラインからステップ 4 に進む
/slide-deck notes <slug>	update	既存デッキのスピーカーノートを書き直す
/slide-deck rewrite <slug> <slide-id>	update	1 枚のスライドを編集する
/slide-deck update <slug>	update	オーバーフロー対策を適用して全般的に変更する
/slide-deck ppt <pptx-path>	ppt	従来の PPTX を React デッキに変換する
/slide-deck export <slug> html	export	スナップショットをスタンドアロン HTML にする
/slide-deck export <slug> pdf	export	スナップショットを PDF にする
/slide-deck export <slug> vercel	export	スナップショットを取得して Vercel にデプロイし、共有可能な URL を作成する
/slide-deck preview <slug>	—	デッキの URL を確認するだけ

連携するツール

• business-brainstorm — ピッチデッキを作成する場合は、まずオファーをブレインストーミングします。デッキには概要書の内容を反映します
• decide — 判断が中心となる講演（例：「VC からの資金を受けるべきか？」）では、先に /decide を実行します
• deep-research — デッキにまだないデータが必要な講演に使います
• second-brain — 関連する [[wiki]] ページをコンテンツソースとして取り込み、デッキで引用できます
• watch-video — ポッドキャストのエピソード、Loom、講演の録画をデッキのアウトラインに変換します（visual モードで実行すると、重要な場面と表示されたスライドも記録できます）
• jab-hook — 公開後、その講演から BIP ローテーション用のプロモーション案を作成します
• frontend-skills（外部）— React デッキのリポジトリを本拠地にしない、ブランド要素のない HTML デッキに使います

品質に関する注意事項

• 物語では「語る」のではなく「見せる」ことを徹底します。 スライド資料の切り口を1つに絞り込まず、異なる3つの案を提示し、ユーザーに選んでもらいます。別案を提示する前に物語を決めてしまうと、手堅くても印象に残らない資料になります。
• 見た目よりも情報密度のモードが重要です。 発表者主導の資料では、スライドは3語、発表者ノートは5行です。配布用など、読むことを前提とした資料では逆になります。同じ内容でも、成果物は正反対です。草案を作る前に、どちらのモードにするか確認します。
• スライドのテキストは「口頭で話す内容を簡潔にしたもの」です。 どちらも声に出して読んだときに自然である必要があります。スライドがメモのように読めるなら適切ではありません。発表者ノートがスライドのように読める場合も同様です。
• 更新モードでは、内容のあふれを防ぎます。 既存のスライドに内容をむやみに詰め込んではいけません。追加によってスライドの目標語数や行数を超える場合は、スライドの分割または既存内容の削減を提案します。黙って内容をあふれさせると、窮屈な資料になります。
• エクスポートでは発表者ビューを除外します。 Playwright は ?present=0 モードのスナップショットを取得するため、エクスポートはすっきりした状態になります。発表者ビューをエクスポートしてはいけません。
• 移植性よりもブランドの忠実さを優先します。 React の資料が信頼できる唯一の情報源です。HTML／PDF／Vercel へのエクスポートは共有用のスナップショットです。アニメーション、インタラクション、発表者ビューは React 版でのみ利用できます。
• デフォルトは1920×1080、プレビューは1280×720です。 フル解像度のスナップショットは、20枚の資料で30～50 MBになります。低解像度にすると、視覚的な損失を最小限に抑えながらサイズを半分にできます。
• デプロイには実際の費用が発生します。 エクスポートモードの vercel パスでは、デプロイ前に確認を求めます。ドメインと Vercel プロジェクトでは自動更新が有効になっています。