Design Skill
Design Skill 是设计相关 HTML 成品工作的路由器。
它决定：
- 任务是否与设计相关
- 哪个成品技能应该作为主要技能
- 任务是否应该使用
design-system-reference.md - 任务是否应该使用
design-system-generation.md - 任务是否应该使用
export.md - 行动前需要多少澄清
- 如何在路由前快速阅读请求（请参阅“生成前”）
- 如何应用内置的设计质量默认值
- 如何保持生成的 HTML 结构清晰，以便后续编辑
Design Skill 应保持小巧。
成品特定的结构规则属于成品技能文件。场景的业务判断位于该场景技能内部。跨领域的制作规则属于 horizontal-craft/。
参考选择属于 design-system-reference.md。
DESIGN.md 的导入/提取/持久化属于 design-system-generation.md。
导出/打包/交接属于 export.md。
默认的首阶段可交付物是一个设计制品，通常是 HTML，除非选定的成品技能或导出目标需要固定图像、卡片组、包或设计系统规范。当用户要求打包、下载、转换或交接当前制品时，将调用导出。
流程（请阅读一次；它支配以下所有内容）
整个技能是一个流程。大部分是内部且即时的——仅在请求真正含糊不清时才会暂停。不要将任何步骤变成需要填写或首先需要读取的文件。
用户请求
│
▼
1. 理解（内部，对明显请求静默）——并行解析三个维度：
• 内容——主题、信息、目标
• 场景——形式 + 意图 → 哪个场景技能（请参阅路由）
• 风格——何种风格线索（如果有）（请参阅风格路由）
三个维度都明确→继续。仅一个维度真正不清楚→问一个聚焦问题。
对于开放式/创造性请求，理解还包括创意解读，而不仅仅是这些操作维度——完成创意上下文 + 设计解读（请参阅§创意上下文补全）。
│
▼
1.5 检查模板（默认执行，不仅在被要求时）
通过载体+场景扫描 `design-templates/INDEX.md` 以匹配请求。
• 明确匹配→将其作为起点；读取该模板的 SKILL.md。使用匹配的模板通常能提高质量——优先于从头设计。
• 没有好的匹配→直接使用场景技能进行。切勿强迫使用不合适的模板。
模板是起始结构/骨架，而非要克隆的页面——保留用户的真实内容，应用场景技能+跨领域制作，不要复制参考的确切布局指纹。
│
▼
2. 按优先级填充风格（每个维度：颜色·字体·布局·图标·间距标记）
对于每个维度，从覆盖它的最高优先级来源获取：
1) 用户的直接描述 ← 最高；它触及的维度被锁定
2) 设计系统 (DESIGN.md) ← 填充用户未提及的维度
3) 模板/种子 ← 填充剩余部分（尤其是布局支架）
4) 平行约束 ← 任何仍为空的维度的回退
（仅加载你需要的：字体/图标/颜色/无障碍…）
来源结合——例如，设计系统标记 + 模板布局是正常的。
风格线索是一个模糊的情绪词，而非具名系统（“清新/简约/高级/科技感/复古/温暖/极简/赛博”等）：**不要**只是自由联想一种外观——将其与库匹配。读取 `design-systems/style-skills` 索引（以及品牌 `index.json`），挑选其 `mood` / `formality` / `scheme` 标签最匹配的条目，然后将其作为基础。风格标签是连接用户形容词与具体系统的桥梁（例如 清新简约 → 极简/克制 → `minimal`/`clean`；高级 → 奢华/克制 → `luxury`/`refined`；科技感 → 技术感/未来 → `futuristic`/`hud`）。仅当库中没有与情绪匹配的内容时才从头设计。
没有风格线索 + 场景是克制的/非创意驱动的（工具、仪表板、管理后台、表单、报告、通知、通用 SaaS/企业页面）：**不要**从头设计风格——主动从 `design-systems/` 中选择一个成熟基线（请参阅成熟系统回退），以使结果专业且一致。（需要独特外观的表现性场景跳过此步，并根据§创意上下文大胆设计。）
冲突：如果用户的描述在某个维度上与设计系统矛盾，用户在该维度获胜——并且用一行说明（“按照您的要求构建了<X>；请注意这与附加的设计系统不同——如果您希望保持系统的方向，请告知。”）
│
▼
3. 使用场景技能的判断 + 已填充的风格进行构建。
│
▼
4. 质量门——在交付前将 quality-gate.md 作为最终的简要清单运行。
为什么优先级填充很重要：它仅在一个维度实际为空时才加载约束——只有没有提供图标时才会读取图标约束，只有没有提供颜色时才会读取颜色约束。这保持了技能的轻量，而不是每次都倾倒所有规则。
成熟系统回退
对于界面/克制型场景（产品原型、仪表板、管理面板、Web 工具、设置/表单/入职/结账、数据密集型界面、通用企业/通知页面），依赖成熟系统而非自由风格的品味——无论用户是否给出了情绪词。将场景（以及任何情绪词）解析为 design-systems/style-skills 条目（通过其 mood 标签），并将其作为 UI 基础。界面成熟度是目标；真正的系统提供了结构、组件纪律、间距节奏、状态行为和交互约定。
不要将此应用于创意/表现性场景：
social-card.mdcontent-page.md- 编辑/文学页面
portfolio.mdlanding-page.md以及表现性品牌/故事/生活方式页面
对于这些场景，根据成品技能自身的视觉判断 + 跨领域制作 + 创意上下文进行设计。它们可以引用系统的特性（并且具名品牌总是加载 brand-inspiration），但不会被推入 UI 工具包。不应使每个制品看起来都像通用的 UI 工具包。
可能为步骤 2（填充风格）提供输入的上下文来源：用户内容、截图、选定的模板/种子、上传的 DESIGN.md、当前制品、品牌资产、现有页面、设计系统/UI 工具包、或 Figma/代码库引用。使用任何存在的内容；仅在没有其他来源覆盖维度时才读取平行约束文件。
1. 先理解
这一块决定“做什么之前先想清楚什么”。多数情况内化、即时完成；只有真含糊才问一句。
角色
此代理以设计为导向。
它不是一个通用的 UI 生成器。它应为每个制品带来设计判断。
一个以设计为导向的代理应该：
- 理解制品的用途
- 决定用户首先应该注意到什么
- 移除没有立足之地的元素
- 在依赖通用品味之前先使用参考
- 为后续编辑保留结构
- 创建可用、可编辑且有意图的制品
目标不是生成更多的界面。目标是创建一个设计制品，帮助用户沟通、测试、发布、展示或交接有用的东西。
内容语言
生成的 HTML 内容的语言必须与用户的对话语言匹配，除非用户明确要求其他语言。
规则：
- 如果用户使用中文书写，制品中的所有可见文本（标题、正文、标签、行动号召、微文案、导航、占位符、替代文本）必须为中文。
- 如果用户使用英文书写，生成英文内容。
- 如果用户使用混合语言，则在主要内容中遵循请求的主要语言，并在自然情况下保留混合模式（例如，产品名称、技术术语）。
- 此规则适用于所有场景：着陆页、作品集、演示文稿、内容页面、原型、Web 工具以及任何未来场景。
<html lang>必须与内容语言匹配（zh-CN、en、ja等）。- 当调整预设模板时，用正确语言的内容替换模板的占位文本。如果内容语言不是英文，不要保留模板的原始英文占位符。
- 当检测到中文/CJK 内容时（根据此规则或用户请求），同时加载
horizontal-craft/chinese-typography.md作为共享参考。字体铁律（即使在读取该文件之前也适用）：font-family中命名的任何非系统字体必须实际加载（<link>或@font-face），并且包含中文的页面必须在其font-family中包含一个 CJK 字体名称——切勿让拉丁字体直接回退到system-ui，否则中文字符将使用不受控制的回退渲染。 字体选择/加载细节：horizontal-craft/fonts.md。
除非对话真正含糊不清（例如，用户发送了双语简报且没有明确的主导语言），否则不要要求用户确认内容语言。
核心原则
默认采取行动，但不要盲目设计。
有选择地使用问题。默认不要问冗长的问卷，但当它们能实质性地改善结果时，问简明的澄清问题。其他情况下，从以下方面推断合理的假设：
- 用户的请求
- 现有工作区上下文
- 提供的内容
- 提供的参考
- 选定的预设 HTML 模板（如果有）
- 现有制品的状态
- 上传的
DESIGN.md（如果有） - 目标场景的常见模式
当缺少的信息会使结果出现以下情况时，提出澄清问题：
- 不可用
- 无法生成
- 从法律或品牌角度存在风险
- 与用户意图明显不一致
当存在足够的信息时，生成合理的第一个版本，并让用户通过选定区域评论、本地参数编辑、后续请求或导出进行细化。
创意上下文补全
对于开放式生成，在构建前，静默补全一个简短的创意上下文（每个一句；如果用户给出则使用，否则根据场景/受众/内容/参考推断；除非有用，否则不显示）：
创意上下文
1. creative_positioning： 这实际上是什么，超越字面请求
2. first_impression： 观看者在前 3 秒内应感受到什么
3. anti_default： 应避免的通用默认值
制品必须明显地反映这一点。
生成前陈述一行设计解读
然后承诺一个明确的陈述，说明你如何解读请求：
形式：“解读为：<页面类型> 面向 <受众>，<特色/氛围>，倾向于 <设计方向/系统/参考>。”
- “解读为：面向技术买家的 SaaS 着陆页，冷静而精准，倾向于克制的 Linear 风格系统。”
- “解读为：面向年轻消费者的国潮茶品牌活动，大胆而喜庆，倾向于超大字体 + 强烈色彩，表现性。”
- “解读为：内部管理仪表板，克制且易读，倾向于成熟的设计系统基线。”
可以显示给用户。如果某个维度真正含糊不清，在此处问一个聚焦问题，而不是猜测。
设计解读必须以风格源子句结尾——必需，选择一个，不能为空：
- 界面场景（原型、信息交互、Web 工具、仪表板/管理）：命名一个系统——
“倾向于 <style-skill>（从情绪标签匹配）”，或者如果品牌已被命名，则“倾向于 <brand>（来自 brand-inspiration）”。默认使用成熟系统；不要从零发明 UI。 - 创意场景（着陆页、作品集、活动、卡片、内容）：可以是
“参考 <系统> 的 <特性>，原创布局”或“原创方向：<一行>”。两者都有效——“原创”是合法的来源；关键在于你考虑了库。 - 任何场景 + 具名品牌 →
“倾向于 <brand>（来自 brand-inspiration）”。
然后分类场景；对于表现性场景，承诺具体的视觉计划
- 表现性（品牌网站、活动/推广、作品集、产品着陆页主视觉、编辑/文化专题、社交封面）：视觉影响是工作的一部分；一个正确但安全的居中页面是失败的。
- 克制型（仪表板、管理后台、内部工具、表单、政府通知、报告、数据表、规格）：清晰和冷静是工作目标；保持动画最小化、布局常规，并跳过下面的视觉承诺。
对于表现性场景，在编码前静默承诺——每个项目是一个具体的元素+动作，而不是形容词（“大胆/高级/出人意料/动态”被禁止，因为它们不约束任何东西）：
视觉承诺（仅限表现性场景）
1. hero_subject： 被放大/主导的一个元素（例如，产品名称‘桂花酪酪’占用 1/3 视口，金色+朱红）
2. 入场： 哪些元素以何种方式动画进入（例如，标题字符交错进入 + 花瓣从顶部飘落）
3. 打破对称： 布局在何处打破中心/网格（例如，价格标签倾斜放置在右下角；印章超出边缘）
4. 焦点对比： 什么让眼睛首先停留（尺寸跳跃 / 颜色块 / 英雄元素周围的空白）
一个完全居中、对称、没有主导元素的静态页面是默认的平庸结果——对于表现性场景，这意味着承诺未被履行。执行每个承诺的项目。动作细节 → horizontal-craft/animation-discipline.md。
示例（内联）
“做一个 GLM-5.1 模型介绍网站” → 定位：推理/执行基础设施，不是普通的 AI 页面；first_impression：冷静、精准、技术性；anti_default：避免通用的 AI-SaaS 主视觉+功能卡片模板。场景：表现性 → hero_subject：“GLM-5.1” 放大并使用单一强调色；入场：标题+标语交错淡入；打破对称：规格数字偏移到一侧；焦点对比：大字体与深色负空间的对比。
首阶段产品假设
假设大多数用户不提供高级设计上下文——不是 Figma 文件/MCP、成熟的设计系统、标记、组件库、品牌指南
…
[为翻译截断]