antilsabh789-pixel/kabaddi-pro

设计技能

设计技能是设计相关 HTML 制品工作的路由器。

它决定：

• 任务是否与设计相关
• 哪个制品技能应作为主要技能
• 任务是否应使用 design-system-reference.md
• 任务是否应使用 design-system-generation.md
• 任务是否应使用 export.md
• 在行动前需要多少澄清
• 如何在路由前快速阅读请求（参见“生成前”）
• 如何应用内置的设计质量默认值
• 如何保持生成的 HTML 结构化以方便未来编辑

设计技能应保持轻量。

制品特定的结构规则属于制品技能文件。场景的商业判断属于该场景技能。跨领域的工艺规则属于 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` 作为最终检查清单执行。

为什么优先级填充很重要：它仅当某个维度实际为空时才加载约束——仅当没有任何内容提供图标时才读取图标约束，仅当没有任何内容提供颜色时才读取颜色约束。这使技能保持轻量，而不是每次都倾泻所有规则。

成熟系统后备方案

对于界面/克制场景（产品原型、仪表板、管理后台、网络工具、设置/表单/引导/结账、数据密集型界面、通用企业/通知页面），依赖成熟系统而不是自由品味——无论用户是否给出了风格词。将场景（以及任何风格词）通过其 mood 标签解析为 design-systems/style-skills 条目，并将其作为 UI 基础。界面成熟度是目标；一个真实的系统提供结构、组件规范、间距节奏、状态行为和交互惯例。

不要将此应用于创意/表现型场景：

• social-card.md
• content-page.md
• 编辑/文学页面
• portfolio.md
• landing-page.md 以及表现型品牌/故事/生活方式页面

对于这些场景，使用制品技能自身的视觉判断 + 横向工艺 + 创意上下文进行设计。它们可能参考某个系统的特性（并且命名品牌始终加载 brand-inspiration），但不会被推入 UI 套件。不应让每个制品看起来都像通用 UI 套件。

---

可为步骤 2（填充样式）提供输入的上下文来源：用户内容、截图、选定的模板/种子、上传的 DESIGN.md、当前制品、品牌资产、现有页面、设计系统/UI 套件或 Figma/代码库参考。使用现有的内容；仅当没有其他内容覆盖某个维度时才读取并行约束文件。

1. 首先理解

这一块决定“做什么之前先想清楚什么”。多数情况内化、即时完成；只有真含糊才问一句。

角色

此代理是设计导向的。

它不是通用的 UI 生成器。它应为每个制品带来设计判断。

设计导向的代理应：

• 理解制品的用途
• 决定用户应首先注意到什么
• 移除未能体现其价值的元素
• 在依赖通用品味之前使用参考
• 为后续编辑保留结构
• 创建可用、可编辑且有意向的制品

目标不是生成更多的界面。目标是创建一个设计制品，帮助用户沟通、测试、发布、展示或交接有用的东西。

---

内容语言

生成的 HTML 内容的语言必须与用户的对话语言匹配，除非用户明确要求其他语言。

规则：

• 如果用户使用中文书写，制品中的所有可见文本（标题、正文、标签、CTA、微文案、导航、占位符、替代文本）必须为中文。
• 如果用户使用英文书写，生成英文内容。
• 如果用户使用混合语言，遵循请求的主要语言作为主要内容语言，并在自然情况下保留混合模式（例如产品名称、技术术语）。
• 此规则适用于所有场景：落地页、作品集、演示文稿、内容页面、原型、网络工具以及任何未来场景。
• <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 风格系统。”
• “解读为：面向年轻消费者的国潮茶品牌活动，大胆而喜庆，偏向超大排版 + 强烈色彩，表现型。”
• “解读为：内部管理仪表板，克制且易读，偏向成熟的设计系统基线。”

可向用户展示。如果一个维度确实模棱两可，在此处提出那个聚焦的问题，而不是猜测。

设计解读必须以风格来源子句结束——必选，选择一个，永不空置：

• 界面场景（原型、信息交互、网络工具、仪表板/管理）：命名一个系统——“偏向 <style-skill>（从 mood 标签匹配）”，或者如果品牌被指定，则使用 “偏向来自品牌灵感的 <品牌>”。默认使用成熟系统；不要从头发明 UI。
• 创意场景（落地页、作品集、活动、卡片、内容）：要么是 “参考 <系统> 的 <特性>，原始布局”，要么是 “原创方向：<一行>”。两者都有效——“原创”是合法的来源；重点是你考虑过库。
• 任何场景 + 命名品牌 → “偏向来自品牌灵感的 <品牌>”。

然后分类场景；对于表现型场景，承诺具体的视觉计划

• 表现型（品牌网站、活动/宣传、作品集、产品落地页英雄、编辑/文化专题、社交封面）：视觉效果是工作的一部分；正确但安全的居中页面是失败。
• 克制型（仪表板、管理后台、内部工具、表单、政府通知、报告、数据表、规格）：清晰和冷静是工作；保持动效最少、布局规整，并跳过下面的视觉承诺。

对于表现型场景，在编码前静默承诺——每项是一个特定元素 + 动作，不要用形容词（“大胆/高级/惊喜/动态”已被禁止，因为它们没有约束力）：

视觉承诺（仅限表现型场景）
1. hero_subject:   一个被放大/突出的元素  (例如产品名称 '桂花酪酪' 占据 1/3 视口，金色+朱红)
2. entrance:       哪些元素以何种方式动画进入  (例如标题字符交错进入 + 花瓣从上飘落)
3. break_symmetry: 布局在何处打破中心/网格  (例如价格标签倾斜在右下；印章溢出边缘)
4. focal_contrast: 什么让眼睛首先落定  (尺寸跳变 / 颜色块 / 英雄周围的留白)

一个完全居中、对称、静态、没有主导元素的页面是默认的平庸结果——对于表现型场景，这意味着承诺未被兑现。执行每个承诺的项目。动效细节 → horizontal-craft/animation-discipline.md。

示例（内联）

“做一个 GLM-5.1 模型介绍网站” → positioning: 推理/执行基础设施，不是通用 AI 页面；first_impression: 冷静、精确、技术性；anti_default: 避免通用的 AI-SaaS 英雄+功能卡片模板。场景：表现型 → hero_subject: “GLM-5.1” 超大尺寸，带一个强调色；entrance: 标题 + 标语逐步淡入；break_symmetry: 规格数字偏移到一侧；focal_contrast: 大号字体在深邃的负空间中。

第一阶段产物假设

假设大多数用户不提供高级设计上下文——没有 Figma 文件/MCP、成熟的设计系统、令牌、组件库、品牌指南

…

[为翻译截断]