HTMLPPT.skill

把一个已经确定风格的第一页 Hero，扩展成一套一致、可演示、可交付的 HTML/PPT 式网页演示文稿。

核心原则：先对齐，再执行。第一页 Hero 是视觉母版。

适用场景

当用户给出以下任一输入时使用：

• 第一页 Hero 生成 Prompt
• 已存在的 Hero 页面或 Vite/React 工程
• 多页演示文稿扩展指令
• 个人汇报、产品汇报、路演、复盘、方案讲解等 HTML slide deck
• 明确要求先输出 需要你更改的部分: {} 再执行

阶段 1：先读完，再同步

不要立刻写代码。先完整阅读用户给的 Hero Prompt、执行指令、附件、现有工程文件。

提炼并同步：

• 技术栈与依赖限制
• 字体、字号、字重、行高
• 颜色 token
• 页面间距与布局节奏
• 组件母题，如 pill、卡片、点阵、视频、按钮
• 动画方式，如打字机、切页、hover、进场
• 交互要求，如键盘翻页、hash、移动端、reduced motion
• 交付物要求，如本地预览、build、zip

然后输出一段简短理解说明，并且必须输出下面这个块。

如果有需要用户确认或替换的内容：

需要你更改的部分: {
  "主题/主旨": "需要用户确认或替换的内容",
  "页面数量": "需要用户确认或替换的内容",
  "内容文案": "需要用户确认或替换的内容",
  "视觉保留范围": "需要用户确认或替换的内容",
  "交互方式": "需要用户确认或替换的内容",
  "交付物": "需要用户确认或替换的内容"
}

只保留真正需要确认的 key。没有不确定项时输出：

需要你更改的部分: {}

最后问用户是否确认执行。

阶段 2：确认后再执行

只有当用户明确回复类似下面的话，才开始修改代码：

• 确认
• 执行
• 开始做
• 没问题
• 就按这个来

如果用户继续补充内容，不要急着执行；更新理解和 需要你更改的部分。

执行规则

执行时必须：

1. 先检查当前工程结构，不凭空假设。
2. 保留现有技术栈，不随意新增依赖。
3. 第一页 Hero 尽量原样复用为第一页。
4. 后续页面继承第一页视觉系统，不重新设计风格。
5. 共享组件只在减少重复且不破坏风格时创建。
6. 屏幕文案保持精炼，适合上台讲，不写成长文档。
7. 用户给定稿文案时，不改写含义。
8. 内容放不下时，优先重排和精简屏上文字，不把字号缩到看不清。
9. 内容页不要滥用循环动画、打字机、视频背景或无关装饰。
10. 所有页面要在目标视口内一屏可讲，避免意外滚动。

验收

前端演示文稿完成后，必须尽量验证：

• npm run build 或项目等价构建命令成功
• 本地 dev/preview 能打开
• 首页视觉仍然像原 Hero
• 所有页面能渲染
• 键盘/按钮/hash 等交互符合要求
• 目标投影视口下没有不必要滚动
• reduced-motion 要求可用，如指令中有要求
• 如用户要给别人看，生成 zip 并排除 node_modules/、dist/、.git/

交付回复

最终回复保持简短，包含：

• 改了什么
• 关键文件路径
• 本地预览 URL
• 构建/验证结果
• zip 路径，如已生成

不要只给概念方案；确认执行后要完成到可运行、可验证、可交付。