presentation-builder

演示文稿构建器

当交付物是供他人审阅、演示或作为幻灯片交接的演示文稿，而不只是大纲或叙述文档时，请使用此技能。

presentation-builder 是文档/发布集群的核心技能，适用于：

• 投资者、融资、董事会和高管演示文稿
• 路线图、季度业务回顾、状态汇报和决策评审演示文稿
• 发布、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
• 主要工作是面向终端用户的教程、入门指南、常见问题解答或包含大量截图的帮助中心流程 → 使用 technical-writing
• 主要工作是研究论文、答辩书或学术稿件 → 使用 research-paper-writing
• 主要工作是广泛的发布规划、营销活动策略、定位或信息传达，且不需要具体的演示文稿交付物 → 使用 marketing-automation
• 主要工作仅是大纲、备忘录或规划文档，无需实际的演示文稿文件 → 先使用相关的规划或写作技能

说明

第 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：

• investor → 融资、董事会、战略提案或高管叙事演示文稿
• roadmap-review → 路线图、季度业务回顾、规划、KPI、状态汇报或决策评审演示文稿
• launch-gtm → 发布简报、销售赋能、产品叙事或 GTM 演示文稿
• architecture-demo → 技术讲解、架构评审、开发者演讲或演示文稿
• workshop-training → 工作坊、培训、主题演讲或赋能演示文稿
• game-pitch → 发行商提案、游戏概念、里程碑更新或工作室业务拓展演示文稿

使用 references/artifact-packets-and-last-mile-handoffs.md，尽早选定最小且实用的交付物包以及实际的最终交接载体。

第 2 步：明确目标、证据和后续编辑者

生成幻灯片前，回答以下三个问题：

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>

审阅规则：

• 每张幻灯片都应有一个明确的要点
• 截图、图表和视频素材必须清晰易读
• 必须指出缺乏依据的说法或占位视觉素材
• 如果异步审阅很重要，应确保 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. 首先选定一种演示文稿模式、一个资料包和一个收尾环节。
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