HTMLPPT.skill git:20260703.2920672A

Immutable. This exact content is served forever at /api/v1/blob/897007dac31f8303.

---
name: HTMLPPT.skill
description: 'HTML/PPT 风格网页演示文稿生成工作流。用户提供第一页 Hero Prompt、现有 Hero 工程、演示文稿扩展指令、或要求"先对齐再执行"、"需要你更改的部分: {}"、"把 hero 扩成多页汇报/slide deck/HTML PPT"时必须使用。本 skill 要求先同步理解、列出需要用户更改或确认的部分，得到明确确认后才修改代码，并保持第一页视觉系统一致。'
---

# 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

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

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

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

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

```text
需要你更改的部分: {}
```

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

## 阶段 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 路径，如已生成

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