img-to-html

Img → HTML

内容是什么

这项 Skill 可逐步将界面 mock（PNG/JPG/WebP）忠实地还原为 HTML。

**输入：**参考图（附在聊天中、提供路径或 URL）。如果缺少，请索取。

输出：design-systems/<slug>/ 文件夹，包含复制的参考图、线框图、index.html，以及包含生成的 CSS、JS 和媒体文件的 assets/ 文件夹。

最终入口文件必须准确命名为 index.html。主 HTML 文件不要使用其他名称。

<slug> = mock 的简短 kebab-case 名称（例如：chatgpt-glass-dash）。如果用户未指定，请根据文件名生成，或询问用户。

为什么要分阶段

一次性还原整个界面容易失败（颜色、玻璃效果、图标和字体会混杂出错）。工作流采用 自底向上 的方式：每一层都要等上一层经用户批准后才能开始。线框图定义了有哪些内容，而计划则说明每个区域何时以及如何实现。按用途添加资源：构成背景的图像与背景一起制作。

流程

1. reference → $to-wireframe format=ascii → wireframe.txt + plano → [usuário aprova ambos]
2. fundo completo (CSS e/ou imagens)       → [usuário aprova]
3. estrutura e componentes + fontes       → [usuário aprova]
4. assets restantes (ícones, imagens etc.) → [usuário aprova, se houver]
5. revisão final integrada                → [usuário aprova]

审批关卡（适用于所有阶段）

完成一个阶段后：

1. 展示结果（路径 + macOS 上的 open 命令和/或浏览器截图）。
2. 询问结果是否正确，用户是否想要修改。
3. **停止。**不要开始下一阶段。

只有收到明确确认（“已批准”“可以继续”“ok”）后才能继续。如果用户要求修改：进行编辑、再次展示，然后等待新的批准。

计划获批即表示用户授权按提议的顺序继续，但不会取代实现阶段的审批关卡。如果没有剩余资源，请在计划中说明并省略第 4 阶段；第 3 阶段获批后，继续进行最终审核。

文件夹布局

design-systems/<slug>/
  reference.[ext]      # cópia da imagem de entrada
  wireframe.txt        # planta tipada criada por $to-wireframe format=ascii; plano apresentado junto
  index.html           # markup — só estrutura, sem <style>/<script> inline
  assets/
    styles.css         # todo o CSS
    app.js             # todo o JS (só se o mock precisar de comportamento)
    crops/             # recortes da reference
    *.png / *.mp4 …    # imagens, ícones, vídeos gerados

技术栈：HTML + CSS + JS 分离

无需构建、无需打包器、无需框架、无需 node_modules、无需开发服务器——使用 open index.html 打开即可运行。

• index.html 加载另外两个文件：在 <head> 中使用 <link rel="stylesheet" href="assets/styles.css">，并使用 <script src="assets/app.js" defer></script>。
• HTML 中不得使用内联 <style> 或 <script>，元素上也不得使用 style="…"。所有 CSS 都放在 assets/styles.css 中。
• 只使用一个 styles.css。如果超过约 1500 行，再按区域拆分（assets/nav.css、assets/cards.css），并添加对应的 <link>——默认只使用一个文件。
• assets/ 是唯一的辅助文件夹：CSS、JS、图像、图标、视频和裁剪图都放在其中。
• 不使用 Tailwind，不通过 CDN 加载框架。使用纯 CSS，并在 :root 中用 custom properties 定义设计系统（颜色、圆角、阴影、排版）。
• 线框图中的每个区域都对应一个 CSS 类（.nav、.hero、.card、.card2、……），每个带类型的标签都对应一个工具类（.h1、.t2、.btn、.lnk、……）。线框图中的相同 id = 相同类。
• 重复内容（卡片列表、导航项）直接写在 HTML 中。只有 mock 要求实际交互时才创建 app.js；不要通过 JS 循环生成标记。
• 路径始终使用相对路径：assets/{id}.png。

如果用户明确要求使用 React/Vite，则切换技术栈。

---

第 1 阶段 — 带类型的 ASCII 线框图 + 计划

目标：提供界面的结构蓝图——包含哪些区域，以及其中的文本——并附上按区域划分的简短实现计划。

线框图是 HTML 的契约：每个区域和每个带类型的标签之后都会对应一个 CSS 类（相同 id = 相同视觉样式）。线框图的创建、类型化词汇、嵌套和结构审核完全归 $to-wireframe 负责。不要在此 Skill 中重复这些规则。

创建线框

1. 创建 design-systems/<slug>/，并将图像复制为 reference.[ext]。
2. 使用 format=ascii、image=design-systems/<slug>/reference.[ext] 和 output=design-systems/<slug>/wireframe.txt 调用技能 $to-wireframe。
3. 将 wireframe.txt 保留为本次执行的规范契约。本阶段不要生成 SVG。
4. $to-wireframe 交付后，不要修改线框；任何结构性修正都应使用同一张图像和 format=ascii 重新提交给 $to-wireframe。

实施计划（在同一次审批中）

收到 $to-wireframe 的 ASCII 后，为每个区域注明实施阶段和预期技术。将相同的区域归为一组。在消息中以简短表格呈现计划。不要将计划添加到 ASCII 中：阶段和技术不属于 id/class 或界面文本。

计划示例（根据参考图调整）：

区域 / 元素	阶段	预期技术
屏幕背景 + 装饰性图案	2	CSS 渐变 + 透明插画
导航、主视觉区域和卡片	3	HTML/CSS；微调前先确定字体系列和字重
卡片的插画背景	3	图像 + CSS，与卡片表面一同实现
媒体区域	3 / 4	第 3 阶段搭建结构；第 4 阶段添加内容图像
图标和头像	4	根据裁切区域生成素材
完整屏幕	5	综合比较并进行最终修正

根据视觉效果，在 CSS、图像或两者组合中做出选择，同时考虑保真度、工作量以及调整位置/缩放的便利性。颜色、渐变和简单形状适合使用 CSS；复杂图案和纹理适合使用图像；需要独立调整时，分层更有帮助。若单张背景图能更好地还原构图，也可以使用。文本和控件应保留为 HTML。

按功能对图像分类，而非按格式分类：屏幕背景 → 第 2 阶段；组件背景 → 第 3 阶段；内容图像、图标或头像 → 第 4 阶段。任何表面在其背景关键部分仍未完成时，都不能通过审批。在第 1 阶段规划这些素材，不代表要在该阶段裁切或生成它们。

只审核计划：计划是否涵盖线框的所有区域，并区分背景素材与其余素材？然后展示 wireframe.txt 和计划，并对结构 + 拟议的阶段/技术执行唯一关卡。

---

第 2 阶段 — 完整背景（CSS 和/或图像）

前提：线框和计划均已获批。

1. 创建 index.html（最简骨架，包含指向 assets/styles.css 的 <link>，且 <body> 为空）和 assets/styles.css（简短重置样式 + :root，其中包含目前能够确定的自定义属性）。
2. 使用计划中选定的技术重建完整背景：CSS、单张图像或分层组合。现在就使用下方的素材流程生成所需图像；不要留到第 4 阶段。若有多个独立图层，应在同一批次中并行生成，待全部完成后再组合背景。
3. 不添加导航栏、卡片或内容。必要时可以向 <body> 添加装饰元素以组成背景；也可以使用 CSS 背景和伪元素。
4. 调整图层的位置、缩放、裁切、透明度和混合效果。在浏览器中打开文件（open index.html），并将组合后的背景与参考图进行比较。
5. 关卡。

---

第 3 阶段 — 结构与组件 + 字体

在此阶段实现线框的结构和文本（在 index.html 中编写标记，在 assets/styles.css 中编写样式）：先实现页面框架（nav — 顶栏和/或侧边栏），然后实现各类卡片（card、card2，……）和其他区域。构成组件背景的图像应与组件一同实现；独立图像则使用素材流程中的同一套并行批次。仅在最后设置一个关卡。

微调前的字体

1. 对每种不同的标签类型（h1…t3、btn、lnk 等），识别字体系列 + 字重。如果本地 find-font skill/API 可用，使用 text= 区分大小写地裁剪一行；否则通过视觉判断选择最接近的 Google Font，并说明这是近似结果。
2. 在 index.html 中应用 Google Fonts 的 <link>，或在 styles.css 中应用 @font-face，并在相应类中设置 font-family / font-weight。相同的标签 id 使用相同的字体。
3. 确认字体加载后，再调整换行、尺寸和间距。不要把字体系列/字重的选择推迟到最终审查。

目标：每个表面都要与参考图无法区分。通过测量迭代，而不是猜测：

• 颜色（使用吸管工具 / 对 reference 进行像素取样）
• 渐变（角度 + 色标）
• 透明度（玻璃效果还是不透明）
• 边框 / 边缘光（方向、柔和还是细线）
• 外部和内部的光晕 / 阴影
• 圆角半径、内边距、元素间距
• 已应用的字体排版（字体系列/字重、字号、行高和字间距）

每个表面的流程（先处理导航栏，再逐张卡片处理）：

1. 裁剪参考图（或在浏览器中并排对照）。
2. 采样像素（填充色、左上/右下边缘、文本、元信息）。
3. 在 index.html 中编写标记，并在 assets/styles.css 中编写类；重复使用的值改为 :root 中的自定义属性。
4. 对照截图重现效果与裁剪图；持续调整直至匹配。

只有分配给阶段 4 的资源继续使用占位符，并预留尺寸。组件的背景和字体都应已完成。各区域实现并对照后 → 检查关卡。

---

阶段 4 — 剩余资源

实现计划安排在此阶段的 [ico:] / [img:] / [av:] 及其他资源。重复使用已获批准的背景资源；不要仅为完成此阶段而重新生成。按以下流程准备本阶段的所有裁剪，并并行生成独立资源；之后对照整个资源集合并提交检查关卡。如果没有待处理项，则按计划省略此阶段。

资源流程（用于阶段 2、3 和 4）

1. 在开始任何生成之前，先从 reference 裁剪所需的所有内容 → assets/crops/{id}.png。
2. 将请求分成多个批次：彼此没有依赖关系且目标文件不同的资源属于同一批次。依赖新生成图像或尚未获批准的合成图的资源，放入下一批次。
3. 通过 OpenRouter (gpt2) 并行使用 GPT Image 2 重新生成每个批次。对于图标或裁剪图层，要求提供透明背景的 PNG；对于完整背景，保留所需背景。根据作品类型调整提示词（照片、纹理、3D 等）；不要强行让所有资源都采用扁平风格。将每条命令置于后台启动，并在拼接任何结果前执行 wait。以下是两个独立图标的示例：

uv run ~/.agents/skills/openrouter-img/scripts/generate_image.py \
  --prompt "Recreate this UI icon/asset exactly. Flat, clean edges. Transparent background. No extra padding, no mockup frame." \
  --input-image design-systems/<slug>/assets/crops/{id}.png \
  --filename design-systems/<slug>/assets/{id}.png \
  --model gpt2 --resolution 1K --aspect-ratio 1:1 &

uv run ~/.agents/skills/openrouter-img/scripts/generate_image.py \
  --prompt "Recreate this UI icon/asset exactly. Flat, clean edges. Transparent background. No extra padding, no mockup frame." \
  --input-image design-systems/<slug>/assets/crops/{id-2}.png \
  --filename design-systems/<slug>/assets/{id-2}.png \
  --model gpt2 --resolution 1K --aspect-ratio 1:1 &

wait

从 skills 仓库的 cwd（或使用绝对路径）运行。单个资源使用相同命令，但不带 & 和 wait。将 --aspect-ratio 调整为裁剪图或目标图层的比例。根据 mock 生成背景时，只要求生成背景图，不要复现叠加在其上的文本、卡片或控件。需要 OPENROUTER_API_KEY（项目的 .env 或 ~/.env）。

4. 执行 wait 后，通过 <img src="assets/{id}.png">（或 background-image）将每个结果嵌入 HTML，并与参考图对照。
5. 如果某项失败：只为受影响的资源准备新批次，并调整提示词；不要重新生成已通过的资源。
6. 在使用这些资源的阶段合成图中评估资源；检查关卡属于该阶段，不必对每个文件额外审批。

Etapa 5 — 综合最终审查

1. 在相同视口下，使用已加载的字体和资源，将完整屏幕的截图与参考图进行比较。
2. 检查线框图／计划的覆盖情况，并修正集成差异：资源添加后出现的图层重叠、裁切、对齐、换行和间距问题。
3. 检查相对路径和已实现的行为（如有）。说明实际存在的近似处理或待办事项。
4. 展示完整屏幕和最终文件 → Gate。 此阶段汇总最终结果；字体和背景已在前序阶段完成。

---

不要这样做

• 跳过 Gate，或在单个回合中“提前”完成多个阶段。
• 在阶段 1 中：测量、裁切、进行 OCR、绘制图像，或超出一次审查的范围细化线框图。
• 将关键背景图推迟到阶段 4，或把字体选择留到最终审查时再做。
• 在无法辨认的线框图中编造文本。
• 绘制没有区域标签的组件框，或将子卡片压平为父级中的散落文本。
• 将导航栏当前项标记为 [lnk:]（请使用 [btn:]／变体）。
• 当计划要求使用根据参考图生成的资源时，不要用 Lucide／“类似”的占位内容代替图标／图像。
• 编写内联 CSS（HTML 中的 <style> 或元素上的 style="…"）——所有样式都放入 assets/styles.css。
• 创建 package.json、打包器、框架，或在 assets/ 目录之外散放文件。