presentation-builder

プレゼンテーションビルダー

成果物が、アウトラインや説明文書ではなく、レビュー、発表、またはスライドとして引き継ぐためのデッキである場合に、このスキルを使用します。

presentation-builder は、ドキュメント／公開クラスターの中核となるスキルです。対象は次のとおりです。

• 投資家向け、資金調達向け、取締役会向け、経営幹部向けのデッキ
• ロードマップ、QBR、状況報告、意思決定レビュー用のデッキ
• 発表、GTM、営業支援用のデッキ
• アーキテクチャの解説、デモ用デッキ、技術プレゼンテーション
• ワークショップ、トレーニング、基調講演用のデッキ
• ゲームのピッチ、パブリッシャー向け、マイルストーン更新用のデッキ

ワークフローを選ぶ前に、次のサポートドキュメントを読んでください。

• references/presentation-modes-and-routing.md
• references/artifact-packets-and-last-mile-handoffs.md
• references/source-and-handoff-patterns.md
• references/review-and-export-checklist.md

このスキルを使用する場合

• ユーザーが箇条書きやメモではなく、実際のスライドデッキを必要としている場合。
• ワークフローに、スライドの計画、ビジュアルの反復、デッキ固有のエビデンスが必要な場合。
• エクスポートや後続のオフィス／デザインツールでの調整の前に、ブラウザーでのレビューに耐える必要がある場合。
• HTML ビューアー、PPTX、PDF、Google Slides、Figma Slides など、編集可能または共有可能なスライド形式の出力が必要な場合。
• 依頼でデッキ成果物が明示されているか、レビュー、ピッチ、支援、意思決定のためのプレゼンテーション成果物が明確に想定されている場合。

このスキルを使用しない場合

• 主な作業が技術仕様、ADR、ランブック、移行ガイド、または内部実装ドキュメントである → technical-writing を使用します
• 主な作業がエンドユーザー向けチュートリアル、オンボーディングガイド、FAQ、またはスクリーンショット中心のヘルプセンターのフローである → technical-writing を使用します
• 主な作業が研究論文、反論文書、または学術論文である → research-paper-writing を使用します
• 主な作業が、具体的なデッキ成果物を伴わない広範な発表計画、キャンペーン戦略、ポジショニング、またはメッセージングである → marketing-automation を使用します
• 主な作業がアウトライン、メモ、または計画成果物のみで、デッキファイルが実際には必要ない → まず関連する計画またはライティングスキルを使用します

手順

ステップ 1：デッキモード、成果物パケット、引き継ぎ先をそれぞれ 1 つ選ぶ

草案の作成前に、依頼内容を整理します。

presentation_builder_mode:
  deck_mode: investor | roadmap-review | launch-gtm | architecture-demo | workshop-training | game-pitch | other
  audience: executives | investors | customers | internal-team | mixed | unknown
  source_material: brief | doc | spreadsheet | screenshots | charts | prototype | mixed | unknown
  review_need: outline-approval | visual-approval | export-ready | mixed
  artifact_packet: outline-brief | storyboard | review-ready-html | export-handoff | sync-packet | unknown
  handoff_surface: html-viewer | pptx | pdf | google-slides | figma-slides | mixed | unknown

実行ごとに、主要な deck_mode を 1 つだけ選びます。

• investor → 資金調達、取締役会、戦略的ピッチ、経営幹部向けのストーリーデッキ
• roadmap-review → ロードマップ、QBR、計画、KPI、状況報告、意思決定レビュー用のデッキ
• launch-gtm → 発表ブリーフィング、営業支援、製品ストーリー、GTM 用デッキ
• architecture-demo → 技術解説、アーキテクチャレビュー、開発者向け講演、デモ用デッキ
• workshop-training → ワークショップ、トレーニング、基調講演、支援用のデッキ
• game-pitch → パブリッシャー向けピッチ、ゲームコンセプト、マイルストーン更新、スタジオの事業開発用デッキ

references/artifact-packets-and-last-mile-handoffs.md を使って、必要最小限のパケットと、実際の最終引き継ぎ先を早い段階で選びます。

ステップ 2：伝える内容、エビデンス、後続の編集環境を確定する

スライドを生成する前に、次の 3 つの質問に答えます。

1. 最後までに、対象者に何を理解、承認、または決定してもらうべきですか？
2. スライドにどのようなエビデンスを載せる必要がありますか？ スクリーンショット、グラフ、指標、引用、リンク、映像、または製品ビジュアル。
3. 最終調整はどこで行いますか？ ブラウザー専用ビューアー、PPTX、PDF、Google Slides、または Figma Slides。

引き継ぎ先が重要でないかのように扱ってはいけません。実際のデッキ作成では、HTML や Markdown から始めても、最終的にオフィス／デザインツールでの調整が必要になることがよくあります。

ステップ 3：デッキ以外の作業は早めに振り分ける

最小限かつ適切な境界を設定します。

リクエストの主な内容	使用するもの
技術仕様、展開ドキュメント、ADR、移行の詳細	technical-writing
チュートリアル、ヘルプドキュメント、オンボーディング、スクリーンショットを使った手順	technical-writing
学術論文、反論文、原稿のセクション	research-paper-writing
メッセージング、ローンチ戦略、キャンペーン、コンテンツカレンダー	marketing-automation
レビュー可能、または引き継ぎ可能なデッキ成果物	presentation-builder

「スライドを作って」というリクエストの多くは、実際にはドキュメントやメッセージングに関するものです。スライドを作り始める前に、成果物を確認してください。

ステップ 4：最小限の成果物パケットを選ぶ

進捗につながる最小限の出力を基本とします。

• outline-brief → 要点、根拠、リスクのメモを含む、スライドごとのアウトライン
• storyboard → ビジュアルを仕上げる前の、より具体的なスライド構成と大まかなコンテンツ計画
• review-ready-html → ビジュアルの反復作業を続けられる、ブラウザーでレビュー可能なデッキソース
• export-handoff → 承認済みデッキと、PPTX/PDF/Slidesの引き渡し状況の明示
• sync-packet → デッキと、後続の成果物または仕上げ作業のフォローアップ項目をまとめた短いリスト

アウトラインやストーリーボードが次の適切なステップである場合は、すぐにエクスポート済みのバイナリへ進まないでください。

ステップ 5：安定したソースワークスペースからデッキを作る

次のような専用ワークスペースを基本とします。

decks/<deck-name>/
  slide-outline.md
  slide-01-cover.html
  slide-02-...
  assets/

ソースのルール：

• 編集可能なソースはデッキのワークスペースに保存する
• 元の根拠資料やアセットはデッキの近くに置く
• エクスポート済みのPPTX/PDFではなく、ソースのスライドを修正する
• 数値を後で更新する可能性がある場合は、スプレッドシートやチャートの依存関係を明示する
• PowerPoint / Google Slides / Figmaは、隠れた信頼できる唯一の情報源ではなく、最終仕上げの場として扱う

ソースのライフサイクルに関するルールは、references/source-and-handoff-patterns.mdを参照してください。

ステップ 6：モード別パケットを使い、ビジュアルをレビューする

モード別のスライドパターンについては、references/presentation-modes-and-routing.mdを参照してください。

スライドの作成後または編集後：

slides-grab build-viewer --slides-dir decks/<deck-name>
slides-grab validate --slides-dir decks/<deck-name>

ビジュアルの反復作業を行う場合：

slides-grab edit --slides-dir decks/<deck-name>

レビューのルール：

• すべてのスライドに、明確な要点を1つ設ける
• スクリーンショット、チャート、映像は読み取れる状態にする
• 根拠のない主張や仮置きのビジュアルは明示する
• 非同期レビューが重要な場合は、ライブプレゼンテーションの流れだけでなく、PDFの読みやすさも考慮する
• ブラウザーを使ったワークフロー以外でデッキが編集される場合は、仕上げが必要になりそうな箇所を明示する

エクスポート前に、references/review-and-export-checklist.mdを確認してください。

ステップ 7：正確にエクスポートまたは引き渡す

選択したパケットの準備が整ってからエクスポートしてください。

slides-grab convert --slides-dir decks/<deck-name> --output decks/<deck-name>.pptx
slides-grab pdf --slides-dir decks/<deck-name> --output decks/<deck-name>.pdf

以下をすべて報告してください。

• ソースワークスペースのパス
• 選択した成果物パケット
• 検証状況
• レビュー状況（アウトライン承認済み／ビジュアル承認済み／エクスポート可能）
• 引き渡し先と、仕上げ作業が発生しそうな場所
• 出力ファイルのパス
• フォント、レイアウトのずれ、チャートの更新、オフィスツールでの仕上げなど、残っている手作業による調整のリスク

ステップ 8：適切な形式でデッキの状況を伝える

推奨する回答の構成：

1. デッキのモードと対象者
2. 選択した成果物パケット
3. ソースワークスペースのパス
4. 使用した根拠資料とレビュー結果
5. エクスポート／引き渡しの状況と残っているリスク

主なコマンド

slides-grab edit
slides-grab build-viewer
slides-grab validate
slides-grab convert
slides-grab pdf
slides-grab list-templates
slides-grab list-themes

すべてのコマンドで--slides-dir <path>を使用できます。

例

例 1：PPTXでの明示的な引き渡しを伴う投資家向けデッキ

Turn this product brief into a 10-slide investor deck. Show me the outline first, then generate the deck in decks/series-a and hand off an editable PPTX after visual review.

例 2：非同期レビュー用のアーキテクチャレビューデッキ

Build an 8-slide architecture review deck for our browser automation service. Use screenshots, flow diagrams, and one slide on failure handling. I need a reviewable HTML deck first and a PDF for async review.

例 3：別の手段に振り分けるべきローンチ計画

Help me figure out the launch messaging, channel plan, and owners for next month's release.

適切な方針です。具体的なデッキ成果物も必要でない限り、marketing-automationに振り分けてください。

ベストプラクティス

1. スライド作成は、単なるスタイリング作業ではなく、ストーリー、根拠、引き継ぎの問題として捉えます。
2. まず、スライドデッキのモードを1つ、パケットを1つ、最終仕上げの対象を1つ選びます。
3. バイナリを直接編集するのではなく、安定したHTMLソースを優先し、そこからエクスポートを再生成します。
4. ドキュメント、スプレッドシート、スクリーンショットなどの上流の根拠を明示します。
5. 再現性の限界を隠さず、手作業での仕上げが必要になりそうな箇所を明示します。
6. 進捗を正直に保てる範囲で、最小限のパケットを使用します。
7. 適切な別ルートを明確に示します。「スライド」に関する依頼の多くは、実際にはドキュメント、リサーチ、マーケティングの作業です。

参考資料

• 上流ツール：https://github.com/vkehfdl1/slides-grab
• Figma Slides：https://www.figma.com/slides/
• Marp：https://marp.app/
• Slidev：https://sli.dev/
• Google Slides：https://workspace.google.com/products/slides/
• Microsoft PowerPoint：https://support.microsoft.com/en-us/powerpoint