molten-design

设计系统概要

帮助用户编写一份设计系统文档，让 AI 编码 Agent 在生成 UI 时能够始终如一地应用这套设计。该文件遵循 Google Labs 的 DESIGN.md 规范（YAML 令牌前置元数据 + 按顺序排列的说明章节），并可选择加入动效、图标和无障碍功能扩展章节。

输入路径（标准）： molten-brand 中的 molten-docs/brand/brand.md。较旧项目中，可回退使用项目根目录下的 brand.md 或 /docs/brand.md。

输出路径（标准）： 仓库根目录下的 molten-docs/design/design.md。如果 molten-docs/design/ 目录不存在，请创建该目录。

预览路径（标准）： molten-docs/design/example.html。编写设计概要后，请创建一个独立的 HTML 预览，展示设计系统的实际应用效果。

此技能是 molten-brand 在视觉层面的对应技能。品牌战略位于品牌概要中；视觉识别位于设计概要中。

首先询问：设计界面

每次运行开始时，都要为本次会话确定一个设计界面。不要在同一轮中混合落地页营销 UI 与 Web 应用、移动应用或桌面应用的产品 UI。

只有在用户已经明确指定界面时（例如“落地页设计系统”“移动应用 UI”“SaaS 仪表盘”），才跳过此问题。

使用结构化问题工具：

“这个设计系统用于什么？”

选项：

• 落地页 — 营销 / 转化页面（主视觉区块、页面区块、行动号召）；与 molten-landing 搭配使用
• Web 产品 — 基于浏览器的应用 UI（仪表盘、表单、导航、密集工作流）
• 移动产品 — 手机优先的应用 UI（列表、标签页、拇指操作区、类原生模式）
• 桌面产品 — 桌面应用 UI（窗口框架、菜单、多窗格工作流、以键盘操作为主的使用方式）
• 由我选择 — 根据 brand.md 和上下文推断（id: choose_for_me）

用户选择**“由我选择”**时，请根据 brand.md 和用户的提示进行推断：

• 营销网站、候补名单、发布活动或单页转化 → 落地页
• SaaS、管理后台、开发者工具、内部工具、仪表盘或响应式浏览器应用 → Web 产品
• 消费者应用、现场工具或移动优先的随时随地工作流 → 移动产品
• Electron、原生桌面应用、菜单栏、命令面板、IDE / 工具链或以键盘操作为主的多窗口应用 → 桌面产品

继续之前，请说明所选界面，并用一句话解释原因。

界面参考路由

选定设计界面后，在决定 Pinterest 搜索、令牌、组件或预览方案之前，必须先阅读且只阅读一份界面参考：

选定界面	必须阅读的参考文件
落地页	references/landing-page.md
Web 产品	references/web-app.md
移动产品	references/mobile-app.md
桌面产品	references/desktop-app.md

这些参考文件包含针对特定界面的指导：布局、密度、组件集、Pinterest 搜索锚点、预览范围，以及界面设计的注意事项。将 SKILL.md 保留为通用主干；除非触发条件和输出确实不同，否则不要将整个设计工作流复制到独立技能中。

一次只处理一个界面

• 本次运行中的所有决策——令牌、组件、Pinterest 搜索、example.html 以及注意事项——都必须限定在所选界面内。
• 在 design.md 的概述和假设章节中记录所选界面（例如：Design surface: landing page）。
• 如果用户需要多个界面（例如落地页和 Web 应用），请先完成本次运行所选界面的工作，然后针对下一个界面再次运行 molten-design。不要在会话进行中扩大范围。

首先询问：快速还是详细

大多数使用此技能的用户并非设计师，但他们仍应能控制所需指导的详细程度。

在创建文件之前，询问他们想采用哪种方式，除非他们已在提示中表示“快速”“简要”“详细”“引导式”或类似意思。

如果 设计界面 和 快速还是详细 这两项都尚未确定，请将它们合并到一次结构化提问工具调用中。

使用结构化提问工具，针对工作流只提供以下两个选项：

• 快速草稿： 阅读品牌简介；如有需要，最多提出 3 个通俗易懂的问题；推断 Token 级别的选择，然后创建 design.md 和 example.html。
• 详细引导式流程： 在写入文件前，带用户逐步确定更多事项，同时使用通俗易懂的语言，避免不必要的术语。

如果用户选择 快速草稿，请按以下流程进行：

1. 确认 设计界面（落地页、Web 产品、移动产品或桌面产品）。
2. 从 references/ 中读取对应界面的参考资料。
3. 阅读品牌简介、现有的 design.md（如果有）以及任何现有的 UI 样式。
4. 提供 视觉参考探索（Pinterest），除非用户已跳过或完成此步骤。
5. 仅在无法推断答案时，提出最多 3 个通俗易懂的问题（如果已确认的 Pinterest 参考已涵盖风格和方向，则减少问题）。
6. 自行做出设计决策，并将其限定在所选界面的范围内。
7. 编写或更新 molten-docs/design/design.md。
8. 编写 molten-docs/design/example.html。
9. 列出假设，以便用户可以针对具体草稿作出反馈。

在快速草稿模式下，不要提出以下问题：

• “系统应采用什么强调色策略？”
• “界面应使用什么色温的中性色？”
• “设计简介应指定什么背景策略？”
• “应如何处理语义色？”
• “系统应采用什么字体搭配？”
• “系统应采用什么间距基准？”
• “系统应采用什么层级策略？”
• “系统应采用什么圆角设计理念？”

请根据 molten-docs/brand/brand.md、现有项目样式和稳妥的默认设置来推断这些细节。

只询问用户通俗易懂的问题：

• 需要遵循的现有 Logo、网站或品牌颜色
• 期望的感觉，例如严肃、友好、高级、活力、平和或实用
• 产品类型，例如 SaaS 应用、营销网站、开发者工具、消费类应用或内部工具
• 可选的、符合品牌风格的参考网站或应用
• 需要避免的视觉元素

如果用户说“替我选”“采用最佳实践”“由你决定”，或者选择快速路径后未表达偏好，请自行决定并继续。

详细引导式流程

当用户选择详细选项，或明确要求进行细粒度设计控制、调整 Token、开展设计师级别的研讨，或在看过初稿后进行更深入的第二轮设计时，采用此流程。

即使采用详细路径，也要先用通俗易懂的选项开始，并由你自行将用户的回答转化为 Token 级别的细节。

操作规则

• 在交互式运行开始时，告知用户：“与此技能交互的最佳方式是使用语音模式口述你的反馈。”
• **在做出设计决策前阅读品牌简报：**先阅读 molten-docs/brand/brand.md，再阅读项目根目录下的旧版 brand.md 或 /docs/brand.md。提取所有视觉方面的含义（成熟度、个性、参考项、反向参考项、第一印象线索、强调色指导）。在确定设计界面后（或推断设计界面为 替我选择 时）执行此操作。
• 在做出设计决策前阅读匹配的界面参考：references/landing-page.md、references/web-app.md、references/mobile-app.md 或 references/desktop-app.md。
• 每次运行开始时都询问设计界面，除非用户的提示已明确说明。
• 创建文件前询问采用快速还是详细方案，除非用户已选定方案。
• 整个运行仅针对一个界面（落地页、Web 产品、移动产品或桌面产品）。一次操作中绝不混合多个界面。
• 提出简洁的问题，并分小批次提问，遵守快速草案的问题数量限制，除非用户选择详细路径。
• 在聊天中提出的每个开放式问题都要编号，方便用户按编号回答，尤其是在使用语音模式时。
• 优先推断而非提问。仅当选项使用日常语言表述且确实能减轻用户负担时，才使用结构化提问工具。
• 按 Agent 使用结构化提问工具：
  • Codex： request_user_input
  • Claude Code： AskUserQuestion
  • Cursor： AskQuestion
• 对于需要自由文本回答的问题（例如参考网站、现有素材、视觉偏好或产品背景），以对话方式提出开放式问题。
• 在聊天文本中，绝不使用字母或项目符号列出多选选项。多选题使用结构化提问工具；开放式问题使用普通文本。
• 同一阶段中相关的结构化问题应合并到一次工具调用中。
• **以顾问的方式工作，而非问卷调查。**在初始启动问题（设计界面和快速或详细方案）之后的每个结构化问题，都必须包含最后一个“替我选择”选项，让用户可以将决定交由你处理。用户选择该选项时，根据 brand.md 和战略背景挑选最合适的选项，并在继续之前说明选择及一句理由。不要默默替用户决定，始终明确说明。
• 对于聊天中的自由文本问题，提供相同的退出选项：以“或者说由你选择，我会根据 brand.md 来决定。”结尾。用户选择交由你决定时，提出一个具体值（精确的十六进制颜色、字体名称或尺寸），并附上一句理由。
• 如果 brand.md 已回答某个问题，就不要再次提问。仅在内容含糊时引用其中的值，请用户确认。
• 对含糊的审美词（如“现代”“简洁”“高级”“极简”）提出质疑，并将其转化为具体的取舍。
• 做出设计决策时，保持系统实用：最多使用两种字体系列，默认设置 8–12 个字体排版层级、4–6 个命名色板，以及一套统一的间距基准。
• 将事实、假设和未决问题分开。
• 此技能处于激活状态时，不要生成应用代码。
• 不要定义品牌个性、语气或信息传达方式。遵循品牌简报。
• 只有在用户提供足够信息，且 Pinterest 参考项已确认或明确跳过后，才创建或更新设计简报。
• 如果可以写入文件，则写入 molten-docs/design/design.md 和 molten-docs/design/example.html（如有需要，创建父目录）。否则，提供这两个文件的完整内容，并告知用户目标路径。

何时使用结构化问题而非聊天

在快速草拟模式下，仅在以下情况下使用结构化问题工具（request_user_input / AskUserQuestion / AskQuestion）：

• 答案是有限选项中的一个或几个。
• 并列展示各种取舍对用户有帮助。
• 选项是通俗易懂的结果，而非设计系统内部细节。

此技能中适合使用结构化问题的提示示例：

• 设计载体：落地页 / Web 产品 / 移动产品 / 桌面产品
• 用通俗语言描述整体感觉，例如严肃 / 友好 / 高端 / 活力 / 平和 / 实用
• 产品类型，例如 SaaS 应用 / 营销网站 / 开发者工具 / 消费级应用 / 内部工具
• 视觉原型，例如 Calm SaaS / Premium Editorial / Developer Tool / Friendly Consumer / Bold Launch Page
• 是仅依据品牌简报继续，还是加入可选的参考网站

以下情况请在聊天中用对话方式提问（不使用结构化问题工具）：

• 答案是自由文本：参考网站、现有品牌颜色、需要避免的内容或产品背景。
• 你正在对模糊的回答提出异议。
• 你正在确认或总结，然后进入下一阶段。

“替我选择”模式（必须遵循）

此技能中的每个问题都必须允许用户将决定交给你。你扮演的是设计顾问，用户应该可以随时说“你来决定”，并相信你会做出合理且符合品牌定位的选择。

对于结构化问题工具

始终追加一个最终选项，包含 id: choose_for_me，并在标签中说明操作及判断依据。示例：

• "替我选择 — 根据 brand.md 提出建议"
• "你来决定 — 选择最符合品牌的方案"
• "替我选择 — 采用最符合当前品牌成熟度的稳妥默认方案"

当用户选择 choose_for_me 时：

1. 选择最符合 brand.md 所体现的信号、战略背景和 DESIGN.md 最佳实践的选项。
2. 明确说明你的选择："选择 X，因为 [与 brand.md 或研究相关的一句话理由]。"
3. 继续进入下一阶段，无需再次确认；如果该选择需要付出较大代价才能撤销（例如主色、字体系列），则需再次确认。

对于聊天中的自由文本问题

在问题末尾明确提供跳过选项：

“……或者说 由你决定，我会根据 brand.md 提出一个值。”

用户选择跳过时，提出一个具体的值，并用一句话说明理由。不要提出范围或“约 X”之类的说法——要给出令牌实际采用的确切值。

示例流程

问题（结构化问题工具）：“你希望产品给人什么感觉？” 选项：严肃 / 友好 / 高端 / 活力 / 平和 / 实用 / 替我选择 — 根据 brand.md 提出建议

用户选择“替我选择”。

Agent 回复：“选择 calm SaaS，因为 brand.md 要求传达沉稳的信心，并提供清晰、可信的界面。我会据此推断具体令牌。”

何时不应让用户决定

如果用户已在 brand.md 或之前的对话中明确提出约束，就不要再次询问。直接应用该约束，并告知用户你已应用。

导入品牌简报

选择（或推断）设计载体后、开始 Pinterest 或令牌相关工作前：

1. 检查 molten-docs/brand/brand.md（规范位置）。如果不存在，则回退到项目根目录下的 brand.md，或旧项目中的 /docs/brand.md。
2. 如果文件存在，读取并提取：
   • 品牌成熟度、个性特征、成对的语气描述
   • 第一印象关键词
   • 视觉参考和反向参考
   • 风险态度和品类立场
   • 由用户画像推断的信息密度和情绪状态
3. 直接使用提取出的视觉信号。只有存在真实的歧义或矛盾时，才请用户确认或更正。
4. 如果 brand.md 不存在，询问用户是先运行 molten-brand（推荐），还是不依赖该文件继续。

现有设计简报与界面层

使用一个规范的设计简报：molten-docs/design/design.md。除非用户明确要求建立独立品牌，否则不要为落地页、Web、移动端和桌面端创建彼此无关的设计系统。

请按以下结构组织输出：

• **共享核心：**颜色、语义颜色、字体系列、基础字号比例、圆角理念、基础间距、动效原则、图标、无障碍默认设置。
• **界面层：**所选界面的布局、密度、组件集、导航模式、区块模式、交互状态和预览切片。

如果 molten-docs/design/design.md 已存在：

1. 在制定新的设计令牌之前，先阅读该文件。
2. 将共享核心令牌视为固定内容，除非用户明确要求重新设计品牌系统。
3. 仅添加或更新所选的界面层。
4. 在假设中记录继承关系：Shared core inherited from existing design.md; updated surface layer: [surface]。

如果这是首次设计，请为所选界面创建完整的 design.md，并标明哪些决策属于共享核心、哪些属于界面层，以便后续界面设计沿用共享核心。

视觉参考探索（Pinterest）

阅读 brand.md 后，在确定设计令牌或编写 design.md 之前，先整理 Pinterest 灵感。这能为非设计师提供具体的视觉方向，无需他们使用设计系统术语描述偏好。

在此阶段完成（确认参考）或明确跳过之前，不要编写 design.md。

生成 5 个 Pinterest 搜索词

根据 brand.md、所选的设计界面、用户已提供的任何通俗风格偏好，以及所选界面参考中的 Pinterest 搜索角度，准确推导出 5 个搜索词。在向用户展示此阶段之前完成这项工作。

规则：

• 所有 5 个搜索词都必须属于所选界面。不要将搜索扩展到无关概念（仅调色板、通用字体、抽象情绪板、编辑类印刷品、Logo 标记等）。
• 使用所选界面参考中的锚点词和示例模式。
• 在自然的情况下，从 brand.md 中添加一个品牌或背景修饰词（类别、风格、B2B/B2C、深色/浅色），但每个搜索词都必须包含界面锚点词。
• 搜索词长度保持在 3–6 个词，应直观且适合 Pinterest 搜索，不要使用抽象的策略词（例如单独使用“现代”“高端”“美感”）。
• 排除反面参考和用户表示要避免的内容。
• 不要重复相同的模式；应在所选界面的模式范围内进行变化。
• 如果 5 个搜索词并非都明确属于所选界面，请在向用户展示前重写。

提供此阶段选项

如果用户已附上参考图片或明确表示跳过参考，则跳过本小节。

不要询问用户是否想浏览 Pinterest。展示已准备好的内容，然后提供打开搜索结果的选项。

在聊天中，可以这样说：

我在 Pinterest 上为你整理了一些符合品牌风格的视觉灵感。你可以打开它们浏览，并挑选一个最喜欢的示例，帮助确定设计方向。

以下是我整理的五个搜索词：

1. …
2. …
3. …
4. …
5. …

然后使用结构化提问工具：

“要我为你打开这些 Pinterest 搜索结果吗？”

选项：

• 是 — 打开搜索结果，我来挑选一个最喜欢的
• 跳过 — 仅根据 brand.md 推断
• 替我决定 — 根据 brand.md 给出建议（id: choose_for_me）

如果用户选择替我决定：当 brand.md 已包含明确的视觉参考或清晰的成熟度/个性信号时，建议选择跳过；当品牌简报缺乏视觉线索或用户选择了详细路径时，建议选择是。用一句话说明建议，然后按建议执行。

只有在用户要求更换搜索角度时才生成新的搜索词；不要再次询问是否使用 Pinterest。

打开 5 个 Pinterest 标签页

为每个词条构建一个 URL：

https://www.pinterest.com/search/pins/?q={url_encoded_term}

（将空格进行 URL 编码，使用 + 或 %20。）

在用户的默认浏览器中分别打开这 5 个 URL，每个 URL 使用单独的标签页。优先使用当前环境中第一个可行的方法；如果打开失败，不要阻塞工作流。

1. Shell（macOS）： open "url1" "url2" "url3" "url4" "url5"
2. Shell（Linux）： xdg-open "url1" "url2" ...（如果支持，使用一次调用打开多个 URL）
3. Shell（Windows）： 对每个 URL 分别执行 start "" "url1"
4. cursor-app-control open_resource： 如果可用，对每个 URL 调用一次
5. 备用方案： 将 5 个链接作为 Markdown 粘贴出来，供用户手动打开

打开后（或使用备用方案时），告诉用户：

看看这 5 个标签页。选出 一张你最喜欢的图钉——也就是最符合你期望方向的示例。请在这里粘贴或附上这张图片（截图、保存的图片或拖放均可）。在确定设计系统之前，我会先描述我从中看到了什么。

等待图片。只有在用户提交一张参考图片或表示跳过（例如“跳过”“不需要参考”“不参考，继续”）后，才继续讨论设计令牌。

解读参考图片

用户附上一张图片后，请分析图片，并使用以下标题以通俗语言进行总结：

• 颜色——主色调、强调色的使用、明暗、冷暖、饱和度
• 字体感受——无衬线／衬线／等宽倾向、字重对比、标题与正文的层级（仅在字体名称一目了然时才写出）
• 布局与密度——留白、网格布局还是编辑式布局、信息密度
• 形状与层次——圆角半径、边框与阴影的使用、扁平还是分层
• 氛围——结合图片中实际所见，列出 2–3 个具体形容词，避免空泛的审美词汇
• 纳入设计令牌——说明对 design.md 的具体影响（例如：“12px 圆角”“约为 #FAF8F5 的暖白色表面”“中性色基底上使用单一高饱和强调色”）
• 避免——任何与 brand.md 中的反面示例冲突或会损害可用性的内容（对比度、触控目标）

如果图片不清晰、分辨率低或与主题无关，请说明情况，并请用户提供另一张图钉，或允许跳过。

确认关卡（必须执行）

在将参考图片应用到设计令牌之前，必须获得用户的明确同意。若有结构化提问工具，请使用：

“这符合你喜欢的参考图风格吗？”

选项：

• 是——将这个方向确定为设计系统的一部分
• 调整——我会描述需要修改的地方
• 换一张参考图——我会再贴一张图片
• 跳过参考图——仅使用 brand.md

然后：

• **是：**将采用的视觉特征映射为具体的 YAML 令牌和 design.md 中的说明。在 Assumptions 中记录：Visual reference: user-selected pin → [one-line summary of adopted signals]。
• **调整：**根据用户的反馈修改解读，并再次询问，直到用户确认或跳过。
• **换一张参考图：**仅针对新图片重复“解读＋确认”流程（仍然一次只处理一张参考图）。
• **跳过：**不要让被舍弃的参考图影响设计令牌；仅根据 brand.md 继续。

绝不能在未告知用户的情况下应用参考图。必须先获得用户确认（或选择跳过），才能编写 design.md。

详细的第二轮

仅当用户在第一版 design.md 和 example.html 草稿完成后明确要求更深入的控制时，才进行第二轮。

在第二轮中，你可以调整颜色、字体、间距、布局、层次、形状、组件、动效、图标、图像和无障碍设计。先询问用户当前预览中哪些地方不合适，再进行有针对性的修改。避免从头重新进行整个访谈。

即使在详细的第二轮中，也应优先先用通俗语言提问。尽可能自行将用户的回答转换为令牌级别的细节。

生成 molten-docs/design/design.md

收集到足够的信息后，按以下结构写入 molten-docs/design/design.md。YAML front matter 是规范性内容；正文用于说明设计依据。

文件应明确区分：

• **共享核心：**可复用的品牌系统令牌与原则，这些内容在落地页、Web、移动端和桌面端界面中应保持稳定。
• **界面层：**所选界面的布局、信息密度、组件优先级和预览指南。

---
version: alpha
name: [Design System Name]
description: [One sentence describing the system]
colors:
  primary: "#RRGGBB"
  secondary: "#RRGGBB"
  tertiary: "#RRGGBB"
  neutral: "#RRGGBB"
  surface: "#RRGGBB"
  on-surface: "#RRGGBB"
  error: "#RRGGBB"
typography:
  headline-display:
    fontFamily: [Family]
    fontSize: [Size]
    fontWeight: [Weight]
    lineHeight: [Line height]
    letterSpacing: [Tracking]
  headline-lg:
    fontFamily: [Family]
    fontSize: [Size]
    fontWeight: [Weight]
    lineHeight: [Line height]
  body-md:
    fontFamily: [Family]
    fontSize: 16px
    fontWeight: 400
    lineHeight: 1.6
  label-md:
    fontFamily: [Family]
    fontSize: 14px
    fontWeight: 600
    lineHeight: 1
    letterSpacing: 0.02em
  label-sm:
    fontFamily: [Family]
    fontSize: 12px
    fontWeight: 500
    lineHeight: 1
    letterSpacing: 0.05em
rounded:
  none: 0px
  sm: 4px
  md: 8px
  lg: 12px
  full: 9999px
spacing:
  base: 8px
  xs: 4px
  sm: 8px
  md: 16px
  lg: 32px
  xl: 64px
  gutter: 24px
  margin: 32px
components:
  button-primary:
    backgroundColor: "{colors.primary}"
    textColor: "{colors.on-surface}"
    typography: "{typography.label-md}"
    rounded: "{rounded.md}"
    padding: 12px
  button-primary-hover:
    backgroundColor: "{colors.tertiary}"
---

# [Design System Name]

Visual identity for [product name]. Pairs with `molten-docs/brand/brand.md` for brand strategy and voice.

## Overview

[Holistic description of look and feel. Personality, target audience, emotional response. Reference brand.md. State the design surface — landing page, web product, mobile product, or desktop product — and what this system optimizes for.]

## Shared Core

[Describe the stable cross-surface choices: color philosophy, type family pairing, radius philosophy, spacing base, motion posture, iconography posture, and accessibility defaults. If this file inherited an existing shared core, say so.]

## Colors

[Shared core. Prose describing each key palette with its role. One bullet per palette, named with descriptive language (e.g. "Midnight Forest Green") and the hex from tokens.]

- **Primary (#RRGGBB):** [Role and when to use]
- **Secondary (#RRGGBB):** [Role and when to use]
- **Tertiary (#RRGGBB):** [Role and when to use]
- **Neutral (#RRGGBB):** [Role and when to use]

## Typography

[Shared core. Prose describing the type strategy. Family choices and their roles.]

- **Headlines:** [Family, weight, voice it creates]
- **Body:** [Family, size, readability decisions]
- **Labels:** [Family, treatment, where it appears]

## Layout

[Surface layer. Grid model, max width, spacing rhythm, containment strategy for the chosen surface. Use the selected `references/*.md` file.]

## Elevation & Depth

[How visual hierarchy is conveyed. Shadows, borders, tonal layers, or flat.]

## Shapes

[Corner radius philosophy and where deviations occur.]

## Components

[Surface layer. Per-component prose: anatomy, variants, states, accessibility notes. Token specifics live in front matter. Include only components relevant to the chosen surface from the selected reference — e.g. hero/CTA/proof for landing page; nav/forms/tables for web product; tab bar/list rows/FAB for mobile product; window chrome/menus/panes for desktop product.]

### Buttons

- Anatomy: [parts]
- Variants: [primary, secondary, ...]
- States: default, hover, focus, active, disabled
- Accessibility: [target size, focus ring, ARIA]

### Input Fields

[Same structure]

### Cards

[Same structure]

## Do's and Don'ts

- Do [specific rule]
- Do [specific rule]
- Don't [specific rule]
- Don't [specific rule]
- Don't [specific rule]

## Motion & Animation

[Optional. Only if defined.]

## Iconography

[Optional. Only if defined.]

## Accessibility

[Optional. Minimum contrast, focus rings, target sizes, reduced-motion.]

## Open Questions And Assumptions

### Open Questions
- [Question that still needs a user decision]

### Assumptions
- [Assumption made due to missing information]
- [Design surface: chosen surface]
- [Shared core: newly created or inherited from existing design.md]

### Next Step
Reference `molten-docs/design/design.md` from your agent config (CLAUDE.md, AGENTS.md, `.cursor/rules/`) so it loads every session. Validate with `npx @google/design.md lint molten-docs/design/design.md`.

生成 molten-docs/design/example.html

写入 molten-docs/design/design.md 后，创建 molten-docs/design/example.html，作为设计系统的易读预览。

用途：

• 让非设计人员也能直观感受抽象的设计令牌。
• 提供可立即在浏览器中打开的内容。
• 通过视觉示例，帮助未来的 Agent 理解预期的外观与风格。

规则：

• 保持文件自包含：只使用一个带内联 CSS 的 HTML 文件。不得依赖框架、构建步骤、软件包安装、CDN 或外部资源。
• 使用从 design.md 中最终确定的令牌派生而来的 CSS 自定义属性。
• 不要创建生产环境的应用代码。这仅用于文档和预览。
• 示例应精致，但也要足够精简，便于快速浏览。
• 如果某个令牌缺失或含义不明确，使用 design.md 中记录的假设；不要仅为预览再提问。

预览应包含：

• 简短标题和一句设计理念，并注明设计界面。
• 带令牌名称和十六进制值的色块。
• 展示字体样式的示例：展示／标题、正文、标签和说明文字。
• 按钮示例：主要、次要、危险、禁用和焦点可见状态。
• 输入框示例：默认、聚焦、错误和禁用状态（Web 和移动端产品界面）。
• 展示间距、圆角、边框、阴影和内容层级的卡片示例。
• 一个符合所选界面的真实组合 UI 区块：
  • **落地页：**主视觉区 + CTA + 一个证明／功能区块
  • **Web 产品：**包含卡片、表单或表格的导航栏／侧边栏切片
  • **移动端产品：**手机宽度的框架（约 390px）、状态栏／标题区、列表或标签栏、便于拇指操作的控件
  • **桌面端产品：**桌面宽度的应用窗口，包含标题／菜单区、侧边栏或分栏面板，以及面向键盘操作的控件区

使用以下结构：

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>[Design System Name] Preview</title>
    <style>
      :root {
        --color-primary: [value from design.md];
        --color-secondary: [value from design.md];
        --color-tertiary: [value from design.md];
        --color-neutral: [value from design.md];
        --color-surface: [value from design.md];
        --color-on-surface: [value from design.md];
        --color-error: [value from design.md];
        --font-body: [font stack from design.md];
        --radius-sm: [value from design.md];
        --radius-md: [value from design.md];
        --space-sm: [value from design.md];
        --space-md: [value from design.md];
        --space-lg: [value from design.md];
      }
    </style>
  </head>
  <body>
    
  </body>
</html>

尽量使用贴近真实场景的标签，而不是占位文本。例如，“开始项目”“预约演示”“电子邮件地址”和“启动准备情况”都比“按钮”或“卡片标题”更合适。

质量检查

在最终确定 molten-docs/design/design.md 之前，请核实：

• YAML front matter 有效（--- 分隔符成对匹配，且没有重复键）。
• 各部分按规范顺序排列（Overview、Shared Core、Colors、Typography、Layout、Elevation & Depth、Shapes、Components、Do's and Don'ts），扩展内容置于其后。
• 已定义 primary 颜色（否则 linter 会发出警告）。
• 所有 {token.path} 引用都对应已定义的 token。
• 组件使用的每组文本/背景颜色对都符合 WCAG AA 对比度要求。
• 字体系列不超过两种。
• 默认包含 8-12 个排版层级，且每个层级都有明确用途。
• 组件变体使用同级键（button-primary-hover），而不是嵌套结构。
• Do's and Don'ts 包含五条规则，且每条都具体明确（不使用含糊的审美用词）。
• 此处不定义品牌策略、用户角色和语气；这些内容位于 molten-docs/brand/brand.md。
• 在 Overview 和 Assumptions 中说明所选设计载体（落地页、Web 产品、移动产品或桌面产品）；当前版本不应试图同时适用于多个载体。
• 扩展现有 design.md 时，Shared Core 决策应标记清楚并予以保留。
• 载体层决策应与选定的参考文件一致。
• 用户通过“Choose for me”委托的每项决策，都应出现在 Assumptions 部分，并附上当时给出的单句理由。
• 如果确认采用了 Pinterest 参考图，Assumptions 部分应以一行记录所采用的视觉元素。
• 明确列出其余假设。
• molten-docs/design/example.html 存在且内容自成一体。
• 预览使用的 CSS 变量与最终 design.md 中的 token 一致。
• 预览包含色板、字体样例、按钮、输入框、卡片，以及一个贴近实际的组合式 UI 区块。
• 明确表明该预览是文档，而非生产应用代码。

如果可以使用 npx @google/design.md，请建议用户运行：

npx @google/design.md lint molten-docs/design/design.md

如果发现 linter 问题，应先与用户逐项检查，再将文件视为最终版本。

参考

如需深入了解规范、token 架构、linter 规则和编写原则，请参阅项目中的 design-md-research.md（如果存在），或查看规范原文 https://github.com/google-labs-code/design.md。