vibe-to-ui

vibe-to-ui

为氛围编程开发者打造的本地设计伴侣。它会先对目标页面的原型和信息密度进行分类，再结合用户的产品背景，参考灵感来源推导出三个合理的视觉与空间方向，然后才将其中一个方向正式整理为设计系统。它会提取“风格 DNA”，包括动效系统、消费级应用 UIUX 需求、视觉素材方向、情绪板和预览，并将模糊的审美感受转化为真正适合产品界面的产品感知型设计决策。灵感可以来自网站 URL、截图、图片、音乐或模糊的意图——Agent 会根据用户提供的内容灵活调整（参见 references/INSPIRATION-SOURCES.md）。案例可以保存到全局灵感库 ~/.vibe-to-ui/inspirations/<product>/pages/<page>/ 中（包含完整滚动分析、动效和带注释的 preview.html，以及产品级综合整理），而无需将原始案例放入配置文件。它还可以在 ~/.vibe-to-ui/profiles/<profile>/ 下持久化可复用的设计上下文配置文件（包含品牌主规范、设计令牌、决策和素材），并按需将其适配到开放式媒介目标——例如 web、social-cover 和 hyperframes，用户也可以自行定义目标（如 linkedin、print-brochure）——同时避免用户数据与技能的安装或更新耦合。所有探索都通过独立预览完成；只有用户确认某个方向并要求应用时，Agent 才会修改用户的项目。

提示：基于 Git 的设计上下文远程同步（context remote / context sync）可通过你自己的私有仓库共享 ~/.vibe-to-ui 下的 profiles/ 和 inspirations/。如需超越 Git 的托管式多项目管理，请参阅 MonkeyUI SaaS。

何时使用此技能

• 用户提供网站 URL、截图或设计稿，希望提取其设计系统
• 用户提供网站 URL 或截图及产品背景，希望 Agent 在此基础上拓展出3 种视觉方向，而不是照搬
• 用户希望 Agent 先判断目标页面属于落地页、品牌页、仪表盘、B 端高密度运营页面、表格详情管理页面、文档页面、引导流程、面向消费者的应用 / C 端应用界面或其他页面类型
• 用户对美学风格只有模糊的感受，希望通过网站 URL、灵感图片或音乐录音探索设计方向
• 用户分享音乐录音或音频片段（旋律、歌曲片段或哼唱录音），以表达希望 UI 传达的氛围
• 用户描述自己联想到理想美学风格的歌曲、流派或音乐感觉
• 用户希望页面更显得轻松、富有编辑感、电影感、平静、宽敞、高级、有趣，或不像千篇一律的 SaaS 落地页
• 用户分享非 UI 灵感素材，例如摄影、风景、建筑、室内设计、杂志、海报、包装、时尚、专辑封面、电影剧照、插画、音乐或视频参考，希望将这些特征转化为布局决策
• 用户希望定义一个符合页面实际用途的动效系统，包括分享在线网站 URL供 Agent 观察
• 用户描述产品个性或感觉（例如“可靠”“创新”“有趣”），希望获得与之匹配的动效指导
• 用户希望创建一个适合目标页面类型的情绪板，避免偏离到错误的页面类型
• 用户收集了多张参考图片或多个网站 URL，希望将它们整合成连贯的视觉故事
• 用户希望创建可分享的设计成果，向协作者或利益相关者传达美学意图
• 用户希望创建符合产品和设计方向的独特图标、插画式功能图标、3D 物体图标、社交视觉素材或生成的品牌资产
• 用户已确认设计方向（来自概念预览、情绪板或设计系统预览），希望将其应用到项目中
• 用户希望将网站 URL 或截图中的品牌视觉语言保存到本地设计上下文配置档案（品牌 / 产品 / 客户），与任何单个项目仓库分开存储
• 用户运行或请求 vibe-to-ui context --profile <profile> --target <medium>，以加载或生成适用于任意媒介的特定规则，并交给匹配的 Agent（例如 web、social-cover、hyperframes，或用户自定义的 linkedin、print-brochure）
• 用户希望建立一个跨项目灵感库——在 ~/.vibe-to-ui/inspirations/<product>/ 下收集产品页面（URL / 截图），获取完整页面滚动的美学与动效分析、产品级视觉定位，可选择将产品关联到配置档案，并且只有在确认后才将产品的 design-seed.md 合并到项目的 DESIGN.md 中

参考优先级规则

选择工作流前，先对用户输入进行分类：

• 氛围 / 风格参考：摄影、风景、建筑、室内设计、杂志、海报、包装、时尚、专辑封面、电影剧照、插画、音乐、视频、抽象感受
• 具体 UI 参考：网站 URL、产品 / 网页 / 应用截图、本地项目、现有代码库

同时存在两类参考时，始终按以下优先级处理：

1. 具体 UI / 项目还原度
2. 页面类型还原度（目标、信息密度、交互模式、模块组合）
3. 视觉素材还原度（图像策略、排版、密度处理、玻璃效果、动效强度）
4. 氛围调整

灵感来源收集

适配用户提供的任何内容——网站 URL、截图、情绪图片、音乐、本地项目、描述，或以上内容的组合。以上都不是默认首选渠道。请遵循 references/INSPIRATION-SOURCES.md：

• 如果用户分享了 URL → 访问 / 获取页面，读取前端线索并采集图像（灵感库：全页滚动；其他功能：选择性采集），可选观察动效
• 如果用户分享了截图或图片 → 直接分析；不要先询问 URL
• 如果用户分享了音乐 / 氛围 / 描述 → 采用氛围路径；不要坚持要求提供在线网站
• 如果来源混合 → 按各自用途使用，并说明它们的权重

只要出现这些来源类型，此收集流程就适用于能力 1–4、动效系统、情绪板和设计背景——它们是平等选项，而不是优先索要 URL 的策略。

强制阶段 0：页面类型识别

在进行任何设计系统提取、空间氛围探索、情绪板生成或项目应用之前，先对目标页面类型进行分类。

始终输出：

1. 主要页面类型
2. 次要修饰类型（如需要）
3. 信息密度级别：低 / 中 / 高
4. 置信度：高 / 中 / 低
5. 依据：促成分类的信号
6. 设计影响：此分类对间距、层级、图像、组件和动效的意义

使用以下信号对页面类型进行分类：

• 业务目标：转化、浏览、监控、数据录入、内容消费、配置、执行
• 信息密度：屏幕上同时竞争注意力的内容量
• 主要交互模式：滚动、阅读、筛选、比较、编辑、审批、深入查看记录
• 主导模块：主视觉、功能网格、表格、图表、侧边导航、详情面板、表单、向导、信息流
• 决策速度：情感说服、平静阅读、快速浏览、重复操作

常见页面类型：

1. 落地页 / 营销页面：说服性叙事、醒目的主视觉、信息密度较低、视觉表现力较强
2. 品牌展示 / 作品集：以展示为主、沉浸式图像、编辑式节奏
3. 内容 / 文档 / 编辑页面：易读性、字体层级、稳定的导航
4. 电子商务 / 商品目录页面：浏览、筛选、比较、商品卡片体系
5. B 端仪表盘 / 概览：指标、监控、摘要、中高信息密度
6. B 端工作台 / 高密度操作页面：重复操作、筛选器、表格、状态标签、紧凑间距
7. 数据管理 / 表格详情页面：记录列表 + 详情 + 批量操作，便于快速浏览
8. 表单 / 新手引导 / 向导：引导式步骤、表单分组、完成反馈
9. 消费者应用界面：C 端产品体验，通常以移动端或应用式体验为先，以任务为导向，但比 B 端系统更注重情感体验；通常基于卡片 / 信息流、标签页、新手引导、空状态和详情流程

如果页面类型混合，选定一种主要类型，并注明次要模式。例如：“主要类型：B 端工作台；次要模式：仪表盘摘要。”

两种工作模式

• 参考还原模式：当用户提供具体 UI、截图、在线页面或本地项目时使用。目标：先匹配页面类型和结构观感，再让输出看起来与参考内容足够相似，然后再调整氛围。要保留参考的布局结构，请遵循 references/SPATIAL-VIBE.md 中的结构提取流程。
• 氛围转译模式：当用户只提供氛围参考或抽象感受时使用。目标：根据产品背景推断预期的页面原型，再将氛围转化为适合该原型的 UI 方向。

只要用户提供了具体 UI 或项目，默认采用参考还原模式。

不可妥协的规则

• 在确定目标页面类型、密度级别、交互模式、页面结构、排版层级、材质处理方式和动效强度之前，不要直接进行自由发挥式的重新诠释。
• 当氛围与页面类型冲突时，应优先遵循页面类型。在原有页面范式内调整氛围，不要意外改变页面范式。
• 除非用户明确要求进行战略性重新定位，否则不要为密集的 B 端工作台设计电影感的落地页。
• 对于落地页／品牌／展示类界面，可以使用更大的图像、更宽松的间距和更具表现力的动效。
• 对于B 端仪表盘／密集运营／表格详情类界面，应优先保证易于浏览、状态清晰、间距紧凑但一致、表单和表格易读，并克制使用动效。
• 对于消费者应用／C 端应用界面，应优先考虑移动端优先的层级、清晰的导航、触控反馈、完整的状态、空状态与引导体验，以及令人印象深刻的品牌表达，同时避免将应用界面变成落地页。若这是主要页面类型，请使用 references/CONSUMER-APP-DESIGN.md。
• 如果参考内容最鲜明的特点是摄影风格的自然景观，默认应以真实风景图像作为主要视觉层。除非用户明确要求插画或抽象表现，否则不要用 CSS 生成的场景取代真实图像。
• 同时提供具体 UI 参考和氛围图时，应将氛围图视为次要参考；它们用于调整输出，而不是替代参考的结构或页面类型。
• 用户提供具体 UI 参考和产品背景时，默认采用以参考为主的探索方式：基于参考推导出 3 个视觉方向，既忠实于参考的页面类型和结构基因，又能根据用户实际的产品背景调整氛围、材质、密度和动效。
• 只有当用户明确要求还原、提取设计令牌、精确复刻或“分析这个设计系统”时，才应优先直接提取设计系统。否则，应先将具体参考作为素材，探索 3 个符合产品背景的视觉方向，再正式确定设计令牌。
• 如果对页面类型的判断把握不大，请先提出一个简短的澄清问题，再正式确定设计系统。
• 默认生成视觉输出，而不是纯文本输出：对于每一种探索、提取、情绪板或空间氛围工作流，默认至少生成一个独立的 HTML 视觉产物。不要等用户明确要求预览、视觉草稿、模型或演示后才生成。
• 如果工作流旨在确定视觉方向，不要只提供 Markdown 分析就结束。文本分析用于辅助视觉产物，不能取代它。
• 生成 UI 之前，先简要总结：
  • 推断出的页面类型和密度
  • 哪些方面必须与参考保持相似
  • 哪些方面可以调整
  • 任务采用的是参考保真模式还是氛围转译模式

持久化 DESIGN.md 上下文

当项目包含 DESIGN.md 时，在进行视觉设计工作前先阅读该文件，并将其作为持久化的产品／设计上下文。若该文件不存在，且工作流确立了有意义的产品或视觉策略，则从 assets/DESIGN.md 创建该文件，或添加相关章节。有关协作协议，请参阅 references/CONTEXT-COLLABORATION.md。

随着对话逐步明确以下信息，主动更新 DESIGN.md：

• 产品定义、用户、用例、个性和限制
• 页面类型、信息密度、交互模式及其对设计的影响
• 已确认的视觉方向、氛围关键词、字体风格、动效个性和图像策略
• icon_system：已锁定的 UI 图标库、自定义 SVG 回退方案、预设、网格、描边规则和用户覆盖项
• illustrated_icon_system：启用的界面、预设、格式、视觉系列规则、风格参考和应避免的界面
• 视觉资源清单路径、评审界面路径、已选组合、放置说明、验证状态、已确认资源、已拒绝资源和重新生成说明
• 正在使用的 Design Context 配置文件 ID（例如，Iteration Context 中的 design_context_profile: vibe-to-ui）

不要要求用户管理这些记录。只有在其影响设计决策或总结已应用的更改时才提及。

本地 Design Context 配置文件（~/.vibe-to-ui/）

当用户希望在多个项目或媒体形式中复用品牌记忆时，使用 Capability 7 和 references/DESIGN-CONTEXT.md。

• 配置文件代表一个品牌、产品或客户（例如 vibe-to-ui、acme-brand），而不是输出平台。
• 实时数据仅存储在 ~/.vibe-to-ui/profiles/<profile>/ 下。技能模板 assets/design-context/ 是供复制的种子文件，绝不可作为实时存储。
• 安装、更新或重新安装技能时，绝不可覆盖、删除或重置 ~/.vibe-to-ui/。
• 生命周期管理（--list / --init / --target）、合并组装和可选的 Git 远程同步（remote connect / remote status / sync）优先使用 Node CLI（bin/vibe-to-ui.js）。
• targets/<medium>.md 文件会在首次请求相应媒体形式时创建（ID 不限于预设值；web / social-cover / hyperframes 仅为示例），之后重复使用并更新。
• 为保持品牌一致性，优先使用启用配置文件中的 brand.md 和 tokens.json；项目的 DESIGN.md 则用于记录产品／页面特定的上下文。

灵感库（~/.vibe-to-ui/inspirations/<product>/）

当用户希望在多个项目中收集并了解外部设计参考时，使用 Capability 8 和 references/INSPIRATION-LIBRARY.md。

• 全局灵感库，不嵌套在配置文件下。存储单位是包含多个页面（pages/<slug>/）的产品，而不是每个 URL 单独建一个文件夹。
• 每个 URL 页面都必须提供完整页面滚动截图和动效说明；product.md 汇总多个页面的视觉 DNA。
• 配置文件只能通过 inspiration-refs.json 存储产品参考（默认类型为 reference-only）。
• 不要将原始灵感案例复制到配置文件中。默认的 apply 使用产品种子；只有在确认后才编写项目的 DESIGN.md。
• 优先使用 CLI：vibe-to-ui inspiration add|list|show|link|apply|rebuild-product。

八项核心能力

1. 提取设计系统（还原设计风格）

用户提供完整的 UI 参考（网站 URL、截图或设计稿）→ 提取设计系统，并生成独立的预览页面，供用户在应用到项目之前查看。

触发条件：用户提到“从这个页面提取风格”“这里的设计系统是什么”“分析这个设计”“分析 https://…”“它用了什么动效”“尽可能还原这个页面”“还原这种风格”，或明确要求精确地拆解设计令牌，而非探索设计概念。

工作流：

1. 接受网站 URL和/或截图/图片，具体取决于用户提供的内容。如果提供了 URL，请根据 references/INSPIRATION-SOURCES.md 处理该链接；如果只提供图片，则直接进行分析。
2. 执行阶段 0：页面类型识别
3. 系统地分析参考内容（如果来自 URL，则分析实时 CSS/DOM，并选择性地截取页面），同时从页面类型的角度解读设计令牌：
   • 布局节奏和信息密度
   • 字体层级和可读性需求
   • 色彩语义，尤其是 B 端界面中的状态色和优先级颜色
   • 适合已分类原型的组件模式
4. 结合页面类型分析动效系统（仅分析动效 DNA — 暂不加载动效引擎路由器）：
   • 着陆页可以采用更多入场编排
   • 仪表盘应优先使用细微过渡和不影响焦点的移动效果
   • 高密度工作台应避免装饰性动效打断信息浏览
   • 消费者应用需要快速、直观的反馈、清晰的屏幕过渡，以及完整的减少动态效果回退方案
   • 从参考内容/氛围中提取节奏、缓动、密度、距离、个性和一个标志性动效主题（参见 references/MOTION-SYSTEM.md）
5. 输出结构化设计系统，包含：
   • 页面类型摘要
   • 根据页面原型得出的设计约束
   • 视觉令牌
   • 动效令牌 + 标志性动效主题
   • 适用时，包含 references/CONSUMER-APP-DESIGN.md 中的消费者应用系统字段
6. 如果用户需要更丰富的美学指南（关注设计灵魂，而不只是令牌），还应根据 references/AESTHETIC-ANALYSIS.md 生成美学分析文档，但其优先级应低于页面类型约束
7. 生成独立的预览页面，作为 HTML 产物展示将提取的设计系统应用于示例组件后的效果。此时还不会将设计系统应用到项目中。编写预览页面的动效代码时，按需加载 references/MOTION-ENGINE-ROUTER.md：编译动效 DNA → 检测技术栈系列（web / react / vue）→ 选择一个引擎层级 + 技术栈绑定 → 选择一个主要配方（根据 DNA/标志性动效主题调整参数，不要原样使用配方默认值）→ 处理依赖、移动设备和减少动态效果回退方案。仅当路由器选择了 L5 MiniMax Video 时，才加载 references/VIDEO-MOTION.md。
8. 请用户确认或调整页面类型分类和提取的值
9. 用户确认后，转到能力 5（将设计应用到项目），将设计系统集成到实际项目中

2. 设计探索

用户有一些感受或氛围设想，但没有具体的设计目标 → 通过互动式对话，探索并确定符合目标页面原型的美学方向，并生成独立的概念预览，以便协作探索 触发条件：用户说出类似“我想要一种……的感觉”“我有一些灵感图片”“以 https://… 为灵感”“我不确定想要什么风格”“探索其他风格，但保留这些颜色”的话；分享氛围或风景照片；分享能传达其理想感受的音乐录音或歌曲；或者在提供产品背景信息的同时，提供具体的 UI 参考（URL 或截图），并希望 Agent 将其拓展为多个视觉方向。 工作流：

1. 询问用户的项目背景：
   • 项目的功能
   • 面向的用户
   • 主要页面类型；如果用户不清楚，则推断页面类型
2. 运行 阶段 0：页面类型识别
3. 邀请用户以自己偏好的形式分享灵感：网站 URL、图片、物件、风景、音乐录音和音频片段（参见 references/INSPIRATION-SOURCES.md）。根据用户发送的内容灵活调整；不要引导他们提供 URL。
4. 如果有具体的 UI 参考，将其中的信号拆分为：
   • 应保留的结构基因：页面类型、构图节奏、模块组合、层级逻辑
   • 可调整的风格维度：材质处理、字体风格、密度调整、色彩温度、动效特征
5. 针对每个 URL、图片、描述或音乐录音，识别其美学特征：
   • 色彩氛围（暖 / 冷 / 柔和 / 鲜明）
   • 质感（平滑 / 粗粝 / 有机 / 几何）
   • 空间感（密集 / 通透 / 有序 / 流动）
   • 情绪基调（俏皮 / 严肃 / 奢华 / 极简）
   • 动效感（静止 / 流畅 / 干脆 / 弹跳 / 电影感）
6. 将信号分为两类：
   • 应保持不变的页面类型约束
   • 可以变化的风格自由度
7. 针对 3 个方向开展字体探索。每个方向都要明确说明：
   • 标题和正文的字体搭配
   • 字体风格（编辑式 / 中性 / 操作型 / 温暖 / 高端 / 俏皮）
   • 针对目标页面类型的可读性策略
   • 字重策略和层级感
   • 后备字体栈；相关时包括支持 CJK 或多语言的后备字体
   • 说明为什么该字体方向适合用户的产品背景，而不只是适合参考图片
8. 将发现综合为 3 个各具特色的设计概念方向，每个方向都包括：
   • 明确继承参考内容或产品背景的特征（参考内容已隐含配色 + 风格——默认不要另行提供风格菜单）
   • 独特的字体方向，而不只是改变配色
   • 动效个性和一个标志性动效主题（是什么让该方向的动效令人印象深刻）
   • 密度策略
   • 明确说明其适合该页面类型的原因
   • 对于消费者应用界面，提供独特的应用体验策略：导航模式、主要循环、关键状态策略和触感交互感受
9. 为每个设计概念方向生成一个情绪板——参见 references/MOOD-BOARD.md——以独立的 HTML 形式呈现，让用户感受并比较
10. 针对每个概念生成一个独立的概念预览页面，以自包含的 HTML 形式呈现：

• 来自实际页面类型的样式化示例卡片或模块
• 概念名称、色板、字体选择理由、字体示例和迷你布局演示
• 根据下方的探索阶段临时动效规则预览动效（除非用户要求将实现正式化，否则不要加载完整的 Motion Engine Router）
• 在相关情况下明确对比标题、正文、标签和密集数据文本
• 对于消费者应用界面，展示来自 references/CONSUMER-APP-DESIGN.md 的真实应用模块：导航、核心屏幕、详情 / 创建流程、非理想状态，以及点击 / 面板 / 标签页动效
• 这些独立页面仅用于探索，不会修改用户的项目

11. 让用户反馈、比较并选择方向或组合元素。只有在用户明确要求探索其他风格（或其他配色）时，才按需开展一轮探索：针对该层提供 3 个选项，优先锁定另一层，然后重新绑定——参见 references/DESIGN-EXPLORATION.md
12. 用户确定方向后，应用 能力 1（设计系统提取），将选定的方向正式整理为完整的设计系统，包括动效令牌
13. 转到 能力 5（将设计应用到项目），将确认的设计整合到实际项目中。应用时，加载 references/MOTION-ENGINE-ROUTER.md 以生成生产环境动效代码；只有当 Router 选择 L5 MiniMax Video 时，才加载 references/VIDEO-MOTION.md。

探索阶段的临时动效（加载 Router 前）

在能力 2 的概念预览和情绪板中，动效仍须经过精心设计，但保持轻量：

1. 为每个概念起草一份临时动效 DNA：节奏、缓动、密度、距离、个性、标志性元素
2. 在独立 HTML 中仅使用 CSS 自定义属性 + CSS transitions/keyframes 实现（不要使用 GSAP/OGL/Three CDN 演示）
3. 展示 一个 标志性元素和必要的反馈（悬停/轻触）；对于消费类应用，还要用 CSS 展示面板上滑和标签指示器
4. 让 3 个概念的标志性元素各不相同，使比较关注的是感受，而不只是颜色
5. 探索阶段禁止使用：库的默认演示、所有元素统一上滑淡入、到处弹跳、粒子场、循环播放的紫色光晕
6. 用户确认方向并需要生产级动效代码时，再加载 Motion Engine Router

3. 空间氛围探索

用户的审美意图模糊，或提供了混合灵感参考，希望将这种感受转化为页面级布局决策。

触发条件：用户提出类似“让这个着陆页感觉更轻松”“我想要一种编辑式、杂志般的感觉”“我喜欢这家咖啡馆、这帧电影画面和这张专辑封面的氛围”“使用 https://… 作为布局结构参考”“不要让它看起来像普通的 SaaS 着陆页”，或分享非 UI 灵感/网站 URL 并询问这些内容应如何影响页面。

工作流：

1. 运行 阶段 0：页面类型识别，并明确产品目标、UX 约束、目标内容和任何反向参考
2. 区分结构参考（影响页面组织的来源）与氛围参考（影响感受、节奏、密度和强调重点的来源）
3. 找出用户真正喜欢每个参考的哪些方面，而不是照搬来源
4. 将参考转化为可迁移的信号：
   • 内容密度与留白
   • 层级与主要视觉焦点
   • 空间节奏、对称/不对称和区块过渡
   • 卡片用法、图像表现、交互节奏和响应式策略
5. 标记不应转化为具体 UI 决策的不可迁移信号。示例：海岸公路照片可能意味着开阔感、大面积负空间、舒缓节奏和克制的密度；这并不意味着要把公路照片放进首屏。
6. 根据产品约束和参考，动态推导页面的空间 DNA。不要使用预设的氛围模板或固定的风格分类体系。
7. 将不可见的构图网格作为私有推理支架，用于处理对齐、节奏、层级和响应式表现；绝不要将其作为面向用户的产物或固定模板展示
8. 在修改生产代码前，先生成 3 个真正不同的布局方向作为独立预览。默认采用 模式 A：三个完整且可比较的布局方向——每个方向都需要有用户易读的小型布局草图或缩略图、草图图例/内容映射、空间 DNA 概述、区块顺序、关键布局决策、权衡和响应式设计思路。
9. 除非用户明确要求只推荐一个方向，否则不要只展示 3 张浅显的方向卡片，然后仅完整展开 1 个方向。如果你推荐其中一个，应将其标注为推荐方案，同时仍展示全部 3 个完整选项。
10. 不要使用缺少图例的架构简写，例如“文案”“卡片”“idx”“样本”或“CTA”。用户应能理解每个区块包含什么内容，以及它存在的原因。
11. 检查渲染结果，并修改任何感觉过于普通、与产品不匹配、对参考过于照搬、让用户难以理解，或 3 个选项细节不均衡的部分

4. 情绪板生成

用户希望将灵感和美学信号综合成精心编排的视觉拼贴 -> 生成交互式 HTML 情绪板，同时遵循目标页面类型。

触发条件：用户说「创建一份情绪板」「我想通过情绪板了解视觉方向」「制作一份灵感板」「将这些参考资料综合成一份情绪板」之类的话，或者收集了多张参考图片或多种信号，并希望在提取设计系统之前获得连贯的视觉概览。

工作流：

1. 收集已通过 Design Exploration 确定的美学信号、用户提供的图片或直接描述
2. 如果尚未执行，则运行 阶段 0：页面类型识别
3. 筛选并选择内容。并非每份参考资料都适合放入情绪板；选择能够强化该页面原型连贯叙事的元素。
4. 选择能够呼应项目空间特质和页面类型的情绪板布局模式：
   • 着陆页 / 品牌：更大的主视觉，更强的视觉叙事
   • B 端 / 数据密集型：UI 片段、密度示例、字体节奏、规范的状态颜色
   • 消费级应用：移动端 UI 片段、标签页 / 信息流 / 详情页节奏、空状态 / 引导页基调、触感动效线索
5. 生成独立的 HTML 情绪板，包含：
   • 主题标题和情绪关键词
   • 目标页面类型和密度说明
   • 主导主视觉或代表性 UI 片段
   • 按使用权重体现比例的色彩方案色块
   • 展示拟用字体实际文本的字体样例
   • 纹理和材质样例
   • 空间和动效线索
   • 设计原则或指导陈述
6. 如果用户正在多个方向之间做选择，则为每个概念分别生成一份情绪板，以供比较
7. 展示情绪板，并邀请用户直观表达感受：「感觉如何？」而不是「这样对吗？」
8. 用户确认方向后，情绪板将成为设计系统提取（能力 1）的素材来源

5. 将设计应用到项目

用户已确认设计方向（来自探索概念、设计系统预览或情绪板）→ 将最终确定的设计系统应用到用户的实际项目中。

触发条件：用户说出类似“应用这个设计”“用这个”“就按这个方向来”“把这个整合到我的项目里”“将概念 B 应用到我的项目”，或确认满意预览效果并希望将其应用到代码库中的话。

应用已确认的方向分为两个不同层面。请确认用户希望应用哪一层——通常两者都需要：

• 令牌应用：视觉和动态设计令牌（颜色、排版、间距、圆角、阴影、动态效果）。这些值与框架无关。
• 布局 / 结构应用：已确认的空间 / 布局 DNA和版块构成（参见功能 3 和 references/SPATIAL-VIBE.md）。这会将选定的布局方向转化为实际页面结构，而不只是设置值。

工作流：

1. 与用户确认应用范围——要应用哪些层（令牌、布局或两者），以及应用到项目的哪个位置
2. 检查用户的项目，了解现有框架、CSS 方案、文件规范，以及已有的设计令牌或页面结构
3. 重新检查已确认的页面类型分类，确保应用的令牌和组件与目标界面保持一致
4. 应用令牌（如在范围内）：根据用户的技术栈生成相应的令牌文件（CSS 自定义属性、Tailwind 配置、JSON 令牌），然后集成这些文件——创建新文件或与现有文件合并，并遵循项目规范
5. 应用布局（如在范围内）：将已确认的空间 / 布局 DNA 和版块顺序转化为项目结构——语义骨架、版块构成、网格 / 间距关系，以及响应式折叠逻辑。复用选定的布局方向，不要退而采用通用页面模板，并将应用的令牌接入该结构。
6. 清晰总结创建或修改的内容，并分别说明令牌变更和结构变更
7. 邀请用户检查并继续迭代——协作过程会在应用后继续

重要：这是 Agent 唯一会修改用户项目文件的功能。此前的所有探索（概念预览、情绪板、设计系统预览、布局方向预览）都会生成独立产物，不会触及项目文件。

用户确认的方向包含视觉素材时，还需遵循 references/APPLY-DESIGN.md 中的第 3.5 步，部署图片和素材清单。

对于消费者应用界面，还需在应用时遵循 references/CONSUMER-APP-DESIGN.md：检查移动优先布局、导航模式、点击目标、安全区域间距、键盘 / 输入行为、状态矩阵，以及已获批准的表现性素材槽位。

6. 视觉素材生成

用户希望生成与产品风格一致的插图（主视觉、功能、空状态、OG 图片），并与已确认或正在探索的设计方向保持相同的风格 DNA → 通过宿主的图像工具生成素材，记录素材清单，将素材嵌入探索产物，并在应用设计时部署。

触发条件：用户说出类似“为这个概念生成主视觉 / 插图”“用真实图片替换情绪板占位图”“创建空状态插图”“应用时附带素材”，或要求生成与当前设计探索或设计系统相匹配的视觉素材。

随附的视觉参考入门素材集

如需立即进行以图像为主的试用，此技能在 assets/examples/visual-reference-directions/ 中提供了三个视觉参考示例。当用户要求使用随附的入门素材集时，请检查这些图像，并仅将每张图像作为对应方向的高层次参考：编辑风格建筑（editorial-cobalt-glass.png）、有触感的材质（tactile-amber-membrane.png）或宁静的自然材质（material-paper-glass.png）。这些只是起点，并非品牌准则：请创作全新的、适合产品的素材，并且在获得确认前，切勿克隆这些素材或将任何素材添加到用户的项目中。 工作流：

1. 如果尚未执行，请运行 Stage 0：页面类型识别 — 页面类型决定素材包（参见 references/VISUAL-ASSET-GENERATION.md）
2. 根据产品背景、DESIGN.md、设计令牌和审美指南（来自探索过程或 references/AESTHETIC-ANALYSIS.md）汇总 StyleContext
3. 确定基于角色的图标策略：
   • 小型 UI 细节图标使用已锁定的项目图标库，或按照 references/ICON-USAGE.md 使用自定义 SVG
   • 如果有助于提升表现力，或用户提出要求，营销／社交／功能图标可以使用生成的 SVG／PNG／WebP 插画系列
   • 允许用户覆盖设置（library_only、custom_svg_only、generated_icons、raster_icons），并记录下来
4. 为每项视觉素材声明目标显示尺寸和背景模式，再编写提示词；合成到 UI 中的生成式插画图标／对象默认使用透明背景；除非用户明确覆盖，否则不对小于 64px 的素材使用图像生成
5. 编写 Visual Family Spec v1，说明线条语言、透视、材质、光照、背景模式／复杂度、构图体系、主体规范、安全区域和放置意图
6. 为每张图片编写一份 Asset Placement Spec，确保每项素材都有明确的 UI 用途：槽位、用途、尺寸规则、文案／CTA 关系、安全区域和响应式行为
7. 为每张图片编写一份 Asset Spec（角色、宽高比、目标显示尺寸、背景模式、构图、预设、风格参考）
8. 按照 Prompt Compiler 规则编译提示词；先生成主视觉或最具代表性的系列锚点，再以该锚点为风格参考生成同系列素材
9. 默认调用宿主提供的图像生成工具。仅当用户明确选择 MiniMax 时才使用 MiniMax 生成静态图片；此时请先加载 references/MINIMAX-IMAGE-GENERATION.md，再进行生成。
10. 运行 Consistency QA 并检查放置适配情况（最多重试 2 次）；如果仍未通过，则按照 references/MOOD-BOARD.md 回退到 CSS 占位符
11. 在探索 HTML 旁写入 design-assets.manifest.json；在情绪板、联系表、放置预览和概念预览中嵌入 <img> 路径
12. 运行 Manifest Validator：检查文件是否存在、尺寸／宽高比、目标显示尺寸、背景模式、文件大小、替代文本／装饰性状态、预览／最终状态、角色／页面适配、风格传承、放置字段和图标角色约束
13. Apply 前生成一个审阅界面：变体使用联系表，跨角色组合使用情绪板墙，文案／CTA／布局适配情况使用放置预览
14. 探索期间使用预览分辨率；Apply（Capability 5）时，重新生成或导出最终分辨率，并仅将已确认／已验证的素材复制到 public/design-assets/（或对应框架的目录）
15. 更新设计系统输出和 DESIGN.md，包含 icon_system、illustrated_icon_system、视觉系列规则、审阅界面路径、所选组合、放置说明、验证状态、清单路径和重新生成说明
16. 默认素材范围：插画、光栅主视觉、用于营销／社交场景的富表现力插画图标系列，以及产品内消费级应用素材（空状态、引导流程、徽章；页面类型为 Consumer app 时）

重要：除非用户明确覆盖页面类型默认设置，否则不要为密集的 B 端工作台界面生成全幅主视觉图像。UI 导航图标仍遵循 references/ICON-USAGE.md（优先使用图标库和自定义 SVG）。

7. 本地设计上下文（配置文件 + 目标）

用户希望从网站 URL 或截图中提取可复用的品牌视觉语言，将其保存在本地，并按需适配不同的媒体 Agent → 创建或更新设计上下文配置文件，然后生成或复用目标规则，并输出合并后的交接包。

触发条件：用户提出类似“将此网站的设计保存为配置文件”“从此 URL/截图中提取品牌上下文”“vibe-to-ui context --profile vibe-to-ui --target web”“给我这个品牌的 LinkedIn 规则”“输出此配置文件的印刷宣传册上下文”“用于发布视频的 Hyperframes 上下文”，或要求在不同项目或媒体中复用此前保存的品牌。

命令界面（此包中的 Node CLI — 优先使用程序化生命周期，而不是手动创建目录）：

vibe-to-ui context --list
vibe-to-ui context --profile <profile> --init
vibe-to-ui context --profile <profile> --target <medium>
vibe-to-ui context remote connect <git-url>
vibe-to-ui context remote status
vibe-to-ui context sync

<medium> 是任意 kebab-case 媒体 ID。示例（不限于此）：web、social-cover、hyperframes、linkedin、print-brochure。

运行 node <skill>/bin/vibe-to-ui.js ...，或者在包的 bin 可用时运行 npx vibe-to-ui ...。根目录始终为 ~/.vibe-to-ui（不支持环境变量覆盖）。请参阅 references/DESIGN-CONTEXT.md。

工作流：

1. 确定 kebab-case 配置文件 ID（品牌 / 产品 / 客户，而非媒体）。优先使用 vibe-to-ui context --profile <id> --init 创建基础结构（仅包含共享种子文件；尚无 targets/）。
2. 目前，品牌提取（URL/截图/图片）仍由 Agent 主导——将内容写入已初始化配置文件的 brand.md / tokens.json / decisions.md / sources/。
3. 使用 --target <name> 时：运行 CLI，让它创建或复用 targets/<name>.md 并输出合并后的交接包。根据品牌主文件，使用 references/DESIGN-CONTEXT.md 中的指南填写目标文件的占位内容。不要拒绝用户自定义的媒体。
4. 可选的团队/跨设备共享：连接私有 Git 仓库以使用 remote connect，然后运行 sync（验证 tokens.json、提交、执行 rebase 拉取、推送；遇到冲突时中止，不覆盖内容）。使用 remote status 查看 ahead/behind 状态。
5. 在项目中工作时，如果存在项目的 DESIGN.md，也要阅读；还可以选择在 Iteration Context 中记录 design_context_profile: <profile>。不要用配置文件替换 DESIGN.md。

不可妥协：~/.vibe-to-ui/ 下的用户数据不属于技能生命周期的一部分。技能更新或重新安装绝不能覆盖这些数据。远程同步仅使用用户的 Git 凭据——此 MVP 不包含 OAuth、自动合并或云账户。

8. 设计灵感库

用户希望将产品网站（多个页面）或截图中的美学案例、判断和可迁移规则积累到一个全局库中，供后续 Agent 搜索和引用，同时不将这些案例视为品牌准则，也不自动编写项目内容。

触发条件：用户说出“将此保存为灵感”“添加到我的灵感库”“将此 URL 分析为灵感”“收集这个产品的视觉系统”“vibe-to-ui inspiration add …”“将此灵感关联到我的个人资料”“将此灵感种子应用到 DESIGN.md”，或要求建立独立于品牌资料的跨项目参考档案。

命令界面：

vibe-to-ui inspiration add <url> [--product <id>] [--page <slug>]
vibe-to-ui inspiration add --image <path> [--product <id>] [--page <slug>]
vibe-to-ui inspiration import-captures <product>/<page> --from-captures <dir>
vibe-to-ui inspiration rebuild-preview <product>/<page>
vibe-to-ui inspiration rebuild-product <product>
vibe-to-ui inspiration list
vibe-to-ui inspiration show <product>[/<page>]
vibe-to-ui inspiration link <product> --profile <profile>
vibe-to-ui inspiration apply <product> --project <path>              # product seed (default)
vibe-to-ui inspiration apply <product> --page <slug> --project <path>
vibe-to-ui inspiration apply <product> --project <path> --confirm

URL 截图由 Agent 自行负责（Browser Use / Computer Use）。CLI 不会启动浏览器。

工作流：

1. add <url> 解析产品和页面，获取元数据，创建 pages/<page>/ 框架（captureCoverage: awaiting-agent），并刷新产品索引构件。使用相同的 --product 对相关 URL 进行分组。
2. 全页滚动截图（每个 URL 页面都必须执行）：Browser Use / Computer Use 将 fullpage.jpg 和连续的 frame-01…N 帧保存到该页面的 captures/ 目录，直到页面末尾；此外，还要将一段简短的动态过程记录到 motion.md。然后执行 rebuild-preview <product>/<page>。不要将仅包含首屏的截图视为完整内容。
3. 对页面类型进行分类；填写完整的全页视觉定位表；涵盖 6 个美学类别中的至少 4 个；标记 observed / inferred / transferable / brand-specific。在 annotations.json 中，为每个视口帧（frame-01…N）添加 1–3 条备注（最多 3 条；fullpage 可以省略锚点），并填写 synthesis。所有扩充后的库文本都使用用户提示词的语言（分析、综合、帧备注、动态过程、种子等——默认不使用源页面的语言）。如果网站有代表性页面，则收集 2–4 个，然后执行 rebuild-product <product>，提炼跨页面的设计 DNA。
4. link <product> 会在资料中写入一条 inspiration-refs.json 记录（reference-only）——绝不会将案例复制到资料中，也不会重写令牌。
5. apply <product> 会先显示产品 design-seed.md 合并结果（可选用 --page 指定单个页面）；只有收到明确的 --confirm 后才会写入。

详情：references/INSPIRATION-LIBRARY.md。

组合使用不同能力

这些能力可以自然组合。工作流遵循探索 -> 选择 -> 应用模式：Agent 生成独立预览以供协作探索，用户确认方向后，才会将设计应用到项目中。

搭配视觉方向（能力 2）与空间方向（能力 3）

能力 2（设计探索）和能力 3（空间氛围探索）的触发条件有所重叠——两者都接受模糊感受、灵感图片和音乐作为输入，但要解答的问题不同：

• 能力 2 产出视觉概念：色彩、字体、材质和动态个性。
• 能力 3 产出空间概念：布局语法、密度、层级、节奏和版块构成。

真实页面需要两者协同。组合规则如下：

• 用户设计新页面时，两者都要运行，不要只调整页面样式。只有颜色没有布局（或只有布局没有颜色），方向就不完整。
• 配对，而非堆叠。 不要展示 3 种视觉概念和 3 种彼此独立的布局方向，凑成 9 个互不相关的选项。将它们配成少数几个连贯概念，每个概念都将一种视觉方向与一种空间方向锁定搭配（例如“概念 A = 中性冷色调 + 编辑式非对称布局”）。
• 从相同信号中推导两者。 相同的关键词、音乐和参考素材既用于视觉转译，也用于空间转译，这样一个概念读起来才像一个有意构思的整体，而不是两个互不相关的层次。
• 按最模糊的部分安排顺序。 如果用户不确定整体感觉，先探索视觉概念；如果用户能感受到氛围，却拿不准页面形态，先探索空间方向。无论哪种情况，都要先协调两者，再将其正式定型。
• 两者都要记录在设计系统文档中：将视觉设计标记记录在相应章节，并将选定的布局记录在 Spatial / Layout DNA 章节中，以便在 Capability 5 中配套应用。
• 基于参考进行探索 -> 选择 -> 应用：从用户的产品背景和具体参考出发，推导出 3 种契合情境的视觉方向，由用户选择 -> 整理为设计系统 -> 应用到项目
• 探索 -> 选择 -> 应用：探索氛围，生成 3 个概念预览和情绪板，由用户选择 -> 整理为设计系统 -> 应用到项目
• 探索 -> 情绪板 -> 选择 -> 应用：探索氛围，对页面类型进行分类，将其凝练为情绪板以供验证，由用户确认方向 -> 提取设计系统 -> 应用到项目
• 设计还原 -> 预览 -> 应用：从完整的设计草稿中提取设计系统，对页面类型进行分类，生成独立的预览页面 -> 用户确认 -> 应用到项目
• 情绪板 -> 提取 -> 应用：根据参考生成情绪板，将确认的方向整理为设计系统 -> 应用到项目
• 探索 -> 情绪板：在设计探索过程中生成情绪板，作为中途检查点，让用户感受方向，同时不损失页面类型的准确性
• 空间氛围 -> 情绪板 -> 选择 -> 应用：将非 UI 灵感转化为空间 DNA，在情绪板中凝练感受，选择方向 -> 整理成型 -> 应用
• 结构参考 + 氛围参考 -> 应用：使用一个参考来确定页面组织方式，另一个参考来确定空间感，再通过目标页面类型协调两者
• 布局 + 设计系统 -> 应用：分析一个网站的布局，对其页面类型进行分类；如果原型兼容，再应用来自另一来源的设计系统
• 布局 + 情绪板：从一个参考中提取布局，再应用情绪板的视觉方向，同时不违背目标原型
• 消费类应用 UIUX -> 预览 -> 应用：对应用平台和生命周期阶段进行分类 -> 探索 3 种应用体验方向 -> 预览导航、核心屏幕、流程、状态矩阵和触感动效 -> 整理为设计令牌 -> 应用到移动优先项目组件
• 来源 -> 设计上下文档案 -> 按需指定目标 -> 多媒介交接：从 URL/截图中提取内容到 ~/.vibe-to-ui/profiles/<profile>/ -> 首次请求时生成 targets/<medium>.md（任意媒介 ID：例如 web / social-cover / hyperframes，或用户自定义的 linkedin / print-brochure）-> 将品牌 + 令牌 + 决策 + 目标合并，交给使用方 Agent；后续调用时复用现有目标
• 设计上下文 + 项目应用：加载活跃档案以保持品牌一致性，使用项目的 DESIGN.md 获取产品/页面上下文，然后应用（能力 5），不另行臆造一套令牌系统
• 灵感库 -> 关联档案 -> 可选地应用 DESIGN.md：将产品页面（完整滚动截图）收集到 inspirations/<product>/ -> 预览页面 + 产品总结 -> 可选择将 link <product> 设为 reference-only -> 仅在确认后，才将 产品 基础内容合并到项目的 DESIGN.md
• 完整流程：识别页面类型 -> 探索感受和参考 -> 根据需要推导视觉方向、空间 DNA、消费类应用 UIUX 需求和/或视觉素材方向 -> 预览 3 个可比较的方向 -> 选择 -> 提取设计系统 -> 可选择将其保存为设计上下文档案和/或灵感库案例 -> 将令牌、布局和已确认的素材应用到项目

输出格式指南

所有设计系统输出都应包含：

• 页面类型摘要：主要类型、次要修饰项（如有）、密度、置信度、依据和设计影响
• 消费类应用摘要（如适用）：平台假设、生命周期阶段、主要循环、导航模型、手势模型、状态风险和状态矩阵
• 便于阅读的 Markdown 文档摘要
• 默认提供独立的视觉产物：在工作流中自动生成自包含的 HTML 预览页面
• 至少一种格式的机器可读设计令牌：
  • CSS 自定义属性（:root { --color-primary: #xxx; }）
  • Tailwind CSS 配置（tailwind.config.js 主题扩展）
  • JSON 令牌文件（适用于与框架无关的场景）
• 动效令牌：与视觉令牌一并定义时长、缓动和动画

Spatial Vibe 输出应包含：

• 页面类型分类和 UX 约束
• 结构参考与氛围参考
• 用户喜欢各个参考的哪些方面
• 可迁移与不可迁移的信号
• 动态推导的 Spatial DNA
• 3 个结构保真度相同的独立布局方向预览
• 每个方向均应包含：便于阅读的迷你布局草图或缩略图、草图图例／内容映射、区块顺序、关键布局决策、权衡和响应式策略
• 对渲染结果的审查记录，以及所做的修订

图标使用指南

生成的 UI 代码中，绝不能将原始 Emoji 字符用作视觉元素。 如果项目中已有图标库，应始终使用该库来确定新的小型 UI 图标。如果没有合适的库图标，或其风格与页面美学不协调，则应创建自定义 SVG 图标组件，使其继承设计系统的令牌、契合设计美学，并通过 references/ICON-USAGE.md 中的自定义 SVG QA 检查清单。不要把小图标做成微型 UI 截图、图表、仪表板或多对象场景；如果图标无法提升浏览或理解效率，就让字体、标签、间距和层级来表达含义。除非用户明确覆盖默认设置，否则仅在营销、功能介绍、空状态、引导、社交或品牌界面中使用生成的栅格图标或插画图标。条件允许时，应在 DESIGN.md 中记录图标策略。

重要说明

• 先探索，后应用：在设计探索期间，绝不要修改用户的项目文件。将所有概念预览、情绪板和设计系统预览生成为独立产物。只有在用户明确确认某个方向后（通过 Capability 5），才应用到项目中。
• 当用户要求探索设计方向、提取设计元素或探索空间氛围，且未明确表示不需要时，应在同一轮中自动生成相应的 HTML 视觉产物。
• 当用户同时提供 UI 参考和氛围参考时，优先采用**“先做得像参考，再调整氛围”**，而不是从头重新设计。
• 在确定调色板、间距比例、字体比例或动效风格之前，务必先判断页面类型。
• 对于以氛围为主导的页面，默认优先采用更少的模块、更大的场景图像和更低的信息密度，除非产品情境明显适合更密集的页面类型。
• 对于 B 端密集型页面，优先确保状态颜色清晰、表格和表单易读、间距紧凑有序，且动效不造成干扰。
• 生成代码令牌前，务必先询问用户使用的是哪种 CSS 框架或技术栈
• 提取颜色时，同时提供十六进制值和语义名称（例如相关的 primary、surface、accent、success、warning、danger）
• 对于字体，注明字体系列和比例，不要只列出绝对字号
• 间距应采用一致的比例（例如以 4px 为基准单位）
• 动效令牌必须包含 prefers-reduced-motion 降级方案。无障碍性不可妥协。
• 在探索阶段，使用探索中间动效（CSS + 临时 DNA + 标志性元素）。情绪板或早期概念感受检查中，不要加载 Motion Engine Router。
• 编写动效实现代码时（设计系统预览第 7 步、已确认概念的产品化，或 Capability 5 Apply），加载 references/MOTION-ENGINE-ROUTER.md。判断界面属于 web、React 还是 Vue，然后使用绑定到相应技术栈的最简单引擎层级。当提议使用原生动效或生成视频时，编写标记前先执行 Video Intent Route，并加载 references/VIDEO-MOTION.md：方向性开场默认使用单镜头 hero-take，并定格在结束画面；只有经过认证的环境动效衔接才允许使用 loop。Router 仅可在自然运动、复杂变换或代码难以良好表达的连续电影感运动场景中选择 L5 MiniMax Video；只能使用 MiniMax，绝不要替换成其他提供方。根据 Motion DNA 和标志性元素调整配方参数——绝不要原样使用库默认值。不要混用引擎，不要将 React 包交叉用于 Vue（反之亦然），不要叠加装饰性效果，也不要照搬演示样式。
• 对不确定的视觉分析应如实说明。标注置信度较低的提取结果，并建议用户核实。