从零开始创建惊艳、动画丰富且自包含的 HTML 演示文稿，或通过转换 PowerPoint 文件生成。当用户希望制作幻灯片、构建演示文稿、打造路演资料（pitch deck）、将 PPT/PPTX 转换为网页格式，或增强现有 HTML 演示文稿时，应使用此能力。该能力帮助用户通过视觉预览而非抽象选项来发掘自身审美偏好。
HTML 幻灯片 — 自定义演示文稿生成器
功能概述
HTML 幻灯片 — 自定义演示文稿生成器是一项面向实际任务的技能，主要用于创建零依赖性, 动画丰富的 HTML 演示文稿, 完全运行在浏览器中；单个 HTML 文件, 所有 CSS/ JS 内置；
核心要点
- . no npm, no b。
- 它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。
- 使用时应结合输入条件选择合适的执行方式，核对必要参数、依赖环境与输出内容，并按原始要求处理异常情况。
使用与执行
该技能适合需要稳定复用相关能力的场景，可作为自动化工作流的一部分，也便于后续检查、调整和扩展。从功能定位来看，该技能强调把分散的操作要求整理成清晰、可复用的处理流程，使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数，再依据技能说明逐步执行；
结果检查与注意事项
若输入条件不完整，应先补齐信息或采用保守配置，避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期，并对异常提示、缺失字段和边界情况进行处理；涉及批量任务时，还应保存进度，避免中断后重复操作。
HTML 幻灯片 — 自包含式演示文稿生成器
创建零依赖、动画丰富的 HTML 演示文稿，完全在浏览器中运行。单个 HTML 文件，所有 CSS/JS 均内联。无需 npm、无需构建工具。在任意浏览器中打开即可直接演示。
核心原则
- 零依赖 — 单个 HTML 文件，CSS/JS 全部内联。不依赖 npm、构建工具或任何框架。该文件可在 10 年后仍正常运行。
- 展示而非描述 — 为风格选择生成可视化预览。用户通过“看见”来发现所需，而非通过文字描述来表达偏好。
- 独特设计 — 拒绝千篇一律的“AI 套路”。每份演示文稿都必须具备手工定制感。避免紫色渐变配白底等陈旧套路，禁用 Inter/Roboto/Arial 等泛用无衬线字体作为标题字体，杜绝模板化卡片网格布局。
- 渐进式披露 — 本 SKILL.md 是一份工作流地图。请先阅读轻量级索引；仅在恰当阶段按需加载详细参考资料。
- 固定 16:9 舞台（不可协商） — 所有幻灯片均基于 1920×1080 画布构建，并整体缩放以适配视口。在包括手机在内的所有设备上，幻灯片始终维持 16:9 比例。严禁对幻灯片内容进行重排版（reflow）。
设计美学指南
生成演示文稿时，请重点关注：
- 排版：选用独特且美观的字体。避免使用 Inter、Roboto、Arial 及系统字体。优先选用 Google Fonts 或 Fontshare 字体库。合理搭配标题字体（display font）与正文字体（body font）。
- 色彩与主题：通过 CSS 自定义变量（CSS variables）建立统一视觉体系。确立主色基调，并辅以鲜明强调色。可从文化美学及主流 IDE 主题中汲取灵感。
- 动效：仅在高影响力时刻启用动画。错序逐显（staggered reveals，利用
animation-delay）比零散微交互更能带来愉悦感。参考animation-patterns.md获取规范。 - 背景：叠加 CSS 渐变、几何图案或上下文相关视觉效果。切勿单独使用纯色背景。
请避免以下通用化模式：
- 过度使用的字体（Inter、Roboto、Arial、每份 Deck 都用 Space Grotesk）
- 陈旧配色方案（白底紫渐变）
- 可预测的版式与雷同的卡片网格
- 无意义的玻璃态效果（glassmorphism）、无明确目的的投影（drop shadows）
工作流
第 0 阶段：模式识别
判断用户意图：
| 模式 | 触发条件 | 下一阶段 |
|---|---|---|
| A：新建演示文稿 | “做一份演示文稿”、“create slides”、“pitch deck” | 第 1 阶段 |
| B：PPT 转换 | 用户提供 .pptx/.ppt 文件 | 第 4 阶段 |
| C：增强编辑 | 用户希望修改已有的 HTML Deck | 直接修改，须严格遵守 Fixed Stage 规则 |
| D：风格迁移 | “change to X style”、“switch theme”、“换成X风格” | 风格迁移协议（Style Transfer Protocol） |
第 1 阶段：内容探索
使用 AskUserQuestion 工具一次性提出全部问题。切勿逐条提问。
问题 1 — 目的：该演示文稿用途为何？选项：Pitch deck / 教学-教程 / 会议演讲 / 内部汇报
问题 2 — 长度：约需多少张幻灯片？选项：短（5–10 张）/ 中（10–20 张）/ 长（20+ 张）
问题 3 — 内容就绪度：您是否已有内容？选项：全部内容就绪 / 仅有粗略笔记 / 仅确定主题
问题 4 — 密度偏好：您希望幻灯片呈现怎样的信息密度？
- “低密度 / 演讲者主导”——聚焦核心观点，文字精简，留白充足。每页仅承载一个核心观点，最多 1–3 个要点项。
- “高密度 / 阅读优先”——更自包含、适合异步阅读。每页含 4–8 个要点项或 4–6 张卡片。
若用户已有内容，请其一并提供。此阶段切勿询问内联编辑需求——该功能将在初稿生成后默认启用。
图像处理（如用户提供图像）：
- 扫描全部图像文件（.png、.jpg、.svg、.webp）
- 使用
Read工具（多模态）逐一检查图像 - 评估：图像所呈现内容、是否可用、代表的核心概念、主色调
- 协同设计大纲——图像与文本共同决定幻灯片结构
- 向用户确认最终大纲
第 2 阶段：风格探索
本阶段贯彻“展示而非描述”原则。 多数人无法用语言准确描述自身设计偏好。
生成 3 个风格迥异的单页 HTML 预览，分别展现排版、配色、动效及整体美学气质。每份预览须形如用户真实 Deck 的首张幻灯片，而非诊断性样卡。
预览组合规则：
- 1 份来自
style-presets.md的稳妥预设方案 - 1 份大胆/非常规选项（另一预设或定制设计）
- 1 份上下文适配选项（最契合用户用途与情绪倾向）
预览真实性规则（不可协商）：
- 幻灯片上严禁渲染内部工作流文本：禁止出现 “preview”、“Option A/B/C”、“generated from”、预设名称、文件路径等字样
- 严禁将用户需求备注直接作为幻灯片内容（例如 “bold and provocative”）
- 仅允许使用真实 Deck 的界面元素：Deck 标题、章节标题、日期、作者、页码，或真实内容短语
将预览保存至临时目录（style-a.html、style-b.html、style-c.html）。通过 present_files 依次向用户展示各预览。
请用户选择：Style A / Style B / Style C / 混合元素。
第 3 阶段：生成演示文稿
基于第 1 阶段获取的内容与第 2 阶段选定的风格，生成完整演示文稿。
生成前，请务必阅读以下参考文件：
| 文件 | 用途 | 使用时机 |
|---|---|---|
references/viewport-base.css |
强制性固定舞台 CSS —— 每份演示文稿必须完整包含其全部内容 | 第 3 阶段（生成前） |
references/html-template.md |
HTML 结构、JS 功能、代码质量标准 | 第 3 阶段（生成前） |
references/animation-patterns.md |
动画片段及“动效→情绪”映射指南 | 第 3 阶段（生成中） |
references/style-presets.md |
所选风格的完整预设定义 | 第 2–3 阶段（用户选定后） |
关键生成要求：
- 输出单个自包含 HTML 文件，所有 CSS/JS 必须内联
- 在