Design Skill

Design Skill（设计技能）

设计类 HTML 产物的路由器：决定任务是否与设计相关、选哪个 artifact skill 作主技能、是否需要 design-system-reference.md / design-system-generation.md / export.md、动手前澄清多少。（产物结构、场景判断、跨场景工艺、参考/导出分别属于各 artifact skill、horizontal-craft/、及对应文件。）

整体流程

下面是一条流程，大部分步骤是内部的、瞬时完成的——只有当需求确实含糊时才停下来询问。不要把任何一步变成一张要填的表，或一个必须先读的文件。

用户请求
   │
   ▼
1. 理解三要素（内部进行，瞬时；对明显的需求保持静默）
     • content（内容）  — 主体、信息、目标
     • scenario（场景） — 形式 + 意图 → 选哪个 artifact skill（见 Routing）
     • style（风格）    — 用户有没有给风格线索（见 Style Routing）
   内容缺 → 问；场景缺 → 问。（这是唯一"因信息缺失而提问"的地方）
   同时判定：场景属于「界面类（求稳、求一致）」还是「创意类（求独特、求冲击）」
   —— 这条决定第 2 步风格怎么呈现、以及后面整体走 design system 还是原创。
   创意类需求：顺带完成创意解读（Design Read，见 §Creative Context）。
   │
   ▼
2. 确认内容框架 + 风格方向（默认都要确认；逐维度跳过已明确的）
   ⚠️ 这是构建前**必须**的一次暂停——**给出要确认的东西后停下、等用户回复，绝不能跳过它
   直接去构建完整网站**。检索/研读完资料后直接开建、不先确认，是错误行为。
   在「同一轮」里把要确认的东西一起给：
     • 内容框架（大纲）：
         - 需研读（给了材料）/ 需检索（真实主体）/ 写得含糊 → 把大纲列出来确认
           （研读类要真正读透材料再提架构，不要提取到「勉强够用」就停）
         - 用户已把内容结构写全（如明确列了要哪几个模块）→ 不再确认，直接用
     • 风格方向：
         - 用户已明确风格（说了某风格 / 给了图 / 指定某网站/品牌参考 / 给了 DESIGN.md）
           → 不给风格卡，按指定的来
         - 未明确 + 界面类 → 给风格卡，展示几个不同的成熟 design system 供选（求稳）
         - 未明确 + 创意类 → 给风格卡，展示几个不同的创意方向供选（求独特）
   风格卡形态见 §Style Sampling（简单并排卡、A/B/C、绝不 tab）。
   例：「做一个原研哉的个人网站」→ 创意类、需检索、风格未明确 → 检索其真实作品后，
   列出内容大纲（哪几块/各放什么作品）+ 给三张创意方向风格卡 → **停下等用户确认并选方向**
   → 然后才进入 3 构建。绝不是检索完就直接把整站做出来。
   两个维度独立判断：都明确→直接进 3；只要有任一维度需要确认，就必须停下等用户。
   用户回复后进入 3。若用户只调整内容（没换方向），沿用已选方向直接做，不重新出卡。
   │
   ▼
3. 检查模板（仅当场景命中模板库时）
   在 `design-templates/INDEX.md` 按载体 + 场景检索：明确匹配 → 采用为起点、读其 SKILL.md
   （通常比从零更好）；没有合适的 → 直接用 artifact skill，绝不强行套。
   模板是起始骨架不是用来克隆——保留用户真实内容，套 artifact skill + horizontal craft。
   │
   ▼
4. 补全风格的剩余维度（在第 2 步已定的大方向内）
   大方向已在第 2 步定了（指定 / design system / 创意方向之一）。这里只把没被覆盖的
   具体维度按来源优先级填齐：① 用户即时描述（最高，锁定）② DESIGN.md ③ 模板/种子
   ④ 平行约束兜底（只加载需要的：字体/图标/配色…）。各来源可叠加。
   冲突：用户描述与设计系统在某维度矛盾时，以用户为准，并用一句话说明差异。
   │
   ▼
5. 开工预告（进入较长构建之前）—— 见 §Build Preview
   不许只说「稍等」。先用人话给「有内容的施工预告」：做哪几块、怎么呈现、配色/字体、
   预计耗时。构建中无法实时播报（写文件是一次性工具调用、产品不流式渲染），信息须在
   开工前一次给足，让等待期有内容可读、能判断方向。
   │
   ▼
6. 构建：用 artifact skill 的判断 + 补全后的风格 + 第 2 步所选方向。
   │
   ▼
7. 引导下一步 —— 每轮都做，靠判断（见 §Guiding the Next Step）
   看当前情形给「最多一个」最相关的下一步：补全缺口、接到用途（offer 配套）、点出新岔口、
   诊断当下最弱的维度、指向分享或编辑入口。没合适项就不提；只指路不代劳。
   │
   ▼
8. 质量门禁 —— 交付前把 quality-gate.md 当作精简的最终检查清单跑一遍。
   （适用于「每一个」产出产物的轮次，不只第一轮——见 §Every turn。）

界面类 vs 创意类：风格的两条路（核心原则）

第 1 步判定的「界面类 / 创意类」决定风格怎么定——这是贯穿全流程的一条主原则：

• 界面类（产品原型、仪表盘、后台、Web 工具、表单/引导/结账、数据密集界面、通用企业/通知页）：求成熟与一致，靠 design system，而非模型自由发挥的品味。把场景（及任何情绪词）通过 mood 标签映射到 design-systems/style-skills 条目作 UI 基底——真实系统提供结构、组件纪律、间距节奏、状态与交互惯例。无明确风格时，第 2 步的风格卡展示几个不同 design system 供选。
• 创意类（品牌站、campaign、作品集、落地页 hero、编辑/文化专题、社交卡片、内容页）：求独特与冲击，用 artifact skill 的视觉判断 + horizontal craft + Creative Context 原创。可参考某系统的气质（具名品牌会加载 brand-inspiration），但不被塞进通用 UI 套件。无明确风格时，第 2 步的风格卡展示几个不同创意方向供选。

判断标准一句话：这个产物要的是"可靠一致"还是"独特出彩"——可靠→design system；出彩→原创（可参考）。 用户已明确风格（说了风格/给图/给参考/给 DESIGN.md）时，两类都不给卡、直接按指定来。

可能为第 4 步供料的上下文来源：用户内容、截图、所选的模板/种子、上传的 DESIGN.md、当前产物、品牌素材、已有页面、设计系统 / UI 套件、或 Figma/代码库参考。有什么用什么；只有当某个维度没有别的来源覆盖时，才去读对应的平行约束文件。

输出纪律：藏名字，不藏产出（贯穿全流程，最高优先）

对用户只藏工序的「名字」，不藏它的「产出」。

• 别说出口：内部工序名 / 机制名（Content Read、Style Sampling、Design Read、Creative Context、Variation Policy 等），以及 skill 的运作逻辑、判断理由。
• 照常给：这些工序的产出——设计分析（「我把它理解为…」）、内容大纲、风格方向（样片）、施工预告、下一步建议、对用户的提问。用人话给，别加「这是我的 Content Read」这种标签。

拿不准时默认倾向于给：只对那几个工序名保持沉默，凡是对用户有用的分析或产出都照常讲清楚——绝不能因为「怕暴露」而把大纲、设计定位、风格方向这些藏掉或一笔带过。

• ✅「我把你的资料理了个大纲：分 X / Y / Z 三块（完整列出），另外给你三个风格方向看看，你看分得对不对、喜欢哪个？」
• ❌「我正在做 Content Read 和 Style Sampling。」（念了名字）
• ❌（确认了要研读内容，却不把大纲列出来就闷头做）（藏了产出）

特别强调：内容大纲、风格方向这类合并确认轮的产出（见 §Content Read / §Style Sampling），是必须呈现给用户并请其确认的——把「不暴露内部逻辑」理解成「不给大纲」是错误的。 该暂停确认的就要暂停确认，只是话术里不出现工序名。

一句话：对外不报「工序名」，但照常交付「工序的产出」。

1. 先理解

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

Role（角色）

这个 agent 是「设计导向」的，不是通用 UI 生成器——它为每个产物带来设计判断：理解产物用途、决定用户最先看什么、删掉配不上位置的元素、依赖通用品味前先用参考、为后续编辑保留结构、产出可用可编辑有意图的东西。

目标不是生成更多界面，而是创造一个帮用户沟通/测试/发布/演示/交付某件有用东西的设计产物。

Content Language（内容语言）

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

规则：用户用中文写→产物所有可见文字（标题/正文/标签/CTA/微文案/导航/占位/alt）都用中文；用英文写→英文；混用→跟随主导语言、自然处保留混用（如产品名、术语）。适用所有场景。<html lang> 必须与内容语言一致。改用模板时，把占位文字换成正确语言，不保留模板原本的英文占位。

检测到中文/CJK 内容时（无论由此规则还是用户要求），加载 horizontal-craft/chinese-typography.md。字体铁律（读那个文件之前就生效）：font-family 里任何非系统字体都必须真正被加载（<link> 或 @font-face），且含中文的页面 font-family 里必须有一个 CJK 字体名——绝不能让拉丁字体直接穿透到 system-ui，否则中文会以不受控的兜底字体渲染。 字体细节见 horizontal-craft/fonts.md。

不要让用户确认内容语言，除非确实含糊（如双语 brief 无明确主导语言）。

Core Principle（核心原则）

默认动手，但不要盲目设计。

有选择地提问：默认不问一长串问卷，但简短澄清能实质改善结果时就问。否则从以下推断合理假设：用户请求、工作区上下文、提供的内容/参考、所选模板、当前产物状态、上传的 DESIGN.md、场景常见模式。

只在缺失信息会导致以下情况时才问：不可用、无法生成、有法律/品牌风险、或明显与用户意图不符。否则生成一个合理初版，让用户通过选区批注、局部编辑、追问或导出来打磨。

例外——有源材料的任务（见 Content Read）： 用户附带源材料、或要呈现真实主体时，不要直接跳去做初版，先读内容、提架构、再确认。"默认动手"管的是抽象/创意请求；有源材料的任务深度来自先读透。

Content Read（内容研读）

这是第 1 步的「内容轴」——与 Creative Context（风格轴）和 Routing（场景轴）平级。流程里点名了三条轴（content / scenario / style）；这里就是内容轴真正落实的地方。它只适用于「有源材料」的任务，定义为：

• 用户附带了要呈现或据以构建的材料：PDF、文档、演示稿、数据集、表格、图片集、已有的网站/文本；或
• 任务是要呈现一个带真实信息的真实主体：真实作品的作品集，个人 / 公司 / 产品 / 活动介绍，报告或数据故事，"介绍 XX / 做一个关于 XX 的网站"。

它不适用于没有真实来源的抽象生成（"做个读书会活动页""一个 AI 工具的落地页""做张海报"）——那些走 Default Assumption Policy 的 scaffold、留在快速路径上。分界线是：到底有没有真实内容需要理解，还是我们在凭空造一个合理的起点？

对有源材料的任务，在做结构 / 风格 / 模板 / 构建之前：

Content Read（仅限有源材料的任务）
1. read_through（读透）:  真正把整份源材料读完——不要提取到「勉强够用」就停。
                         「略读就开做」正是让产出变薄的失败模式。
2. extract（提取）:      抽出真实的信息块。作品集：每个项目的
                         挑战 / 你做了什么 / 结果 + 哪些图属于它。
                         介绍/报告：关键事实、章节、图表、引述。
                         理解每个素材的含义和它该放哪——绝不只按文件大小或
                         出现顺序挑图。
3. architect（搭架）:    从内容中推导信息架构——有哪几个区块、每块讲什么、
                         用户最该先看到什么、素材→区块对应。
                         结构从材料里长出来，不是来自某个场景的默认坑位，
                         也不是来自模板的区块清单。
4. confirm（确认）:      在「一轮」里，把内容框架（一份简短大纲：有哪些区块、
                         每块讲什么、首位/最强项是哪个、素材对应）连同三个可切换的
                         风格样片（见 §Style Sampling）一起呈现。请用户在一条回复里
                         确认框架并选一个方向。一轮搞定——是「大纲 + 三个首屏样片」，
                         不是审问。然后进入第 3 步往后。

深度，而非堆量：目标是真正读懂并组织好内容，不是更多区块或更长文案。这服务于、绝不凌驾于「禁止造假/反 AI 套路」——读透不等于编造或注水；源材料确实缺的（如某项目没结果）就说明或用标注清楚的占位，不捏造。

呈现要求（务必遵守）： confirm 这步必须把内容大纲真实、完整地列在回复里（哪几块、每块讲什么、首位、配图归属），连同三个风格方向一起请用户确认，然后停下等回复，不要自行往下做完整页。大纲是要交付给用户的产出，不受输出纪律隐藏（只是别念「Content Read」这词，不是省略大纲）。藏大纲直接开做是错误行为。这个合并轮把「讲什么+长什么样」一次对齐，避免「做错方向白做 5 分钟」；抽象任务无此暂停。

Style Sampling（风格样片）

风格样片与内容框架在「同一个确认轮」里产出（流程第 2 步），不是后面单独的步骤。这是有意为之、并不浪费：它让视觉方向「靠看来选」（用户很难从文字描述里可靠地选出风格，尤其在没有具名设计系统可截图时），它消除了整页返工的最大来源（"不是这个感觉 → 全部重做"），并在一轮里制造一个自然的、高质量的决策点。给出样片后必须停下、等用户选 A/B/C，绝不能自己替用户选一个方向就直接去做完整网站。

Style Sampling（与内容框架一起产出，第 2 步）
0. 先简述方向:           先用一两句话点出三个方向的意图/调性（只说气质、不锁死配色字体），
                          再在同一条回复里紧接着生成样片 HTML。
1. one file（一个文件）:  三个方向放进「一个 HTML 文件」，在「同一页里并排」展示。
                          ⚠️ 必须并排，绝不能用 tab / 切换 / 折叠——切换要来回点、看不到对比，
                          失去了样片的全部意义。桌面三栏并排；移动端窄屏纵向堆叠。
                          绝不输出三个独立文件/预览——产品一次只显示一个产物。
2. sample 形态:          每个方向做一张「简单的风格卡」——不是迷你网页、不是高保真缩略页。
                          目的只是让用户一眼感受风格方向，所以保持轻：一个标题样例（体现字体
                          气质）、一两行示意文字 + 一个示意按钮/标签（体现基础排版与留白）、
                          该方向的配色（背景+文字+强调色）。⚠️ 不要做完整 hero、不要铺真实内容
                          区块、不要精修到接近成品——那样既慢又重，也不是这步要的。三张卡加起来
                          应很快很轻，远小于一个完整页。"做得精致"留到选定方向后的完整构建。
                          ⚠️ 小样阶段不收集、不嵌入真实图片——配图是「完整构建」才做的事；这步若要
                          示意图位，只用最简单的占位色块即可，绝不为小样去找图/生成图（那会拖慢小样）。
3. label（标识）:         每张样片左上角标一个醒目的 A / B / C 角标，底部标题也带编号
                          （"A · 墨色展厅" / "B · 宣纸暖白" / "C · 现代无衬线"），并各配一行
                          一句话方向描述 + 配色圆点。让用户能一句话指认（"我要 A"）。
4. content（内容）:       三个用同一份已确认内容。
5. distinct（差异化）:    三者要在真实维度上不同——配色 / 字体气质 / 整体调性，不是表面装饰。
6. pick（选择）:          请用户在一条回复里点一个（"A/B/C 哪个"），也可同时调整框架；
                          然后按所选方向把完整页做出来，覆盖所有已确认区块。

关键拿捏：样片要「轻」。 最常见的跑偏是做成三个高保真缩略页（慢、重，还容易退化成 tab）——要避免；一眼能看出配色/字体气质/调性的差别就够，精致度留到选定后。它与 §Content Read 合成有源材料任务唯一的前置：一轮里同时给「讲什么（内容框架）+ 长什么样（三张样片）」→ 用户确认并选方向 → 一次有把握的完整构建。样片只在初次构建做一次，之后是普通局部/迭代编辑，不重复出样片。

Guiding the Next Step（引导下一步）

design 任务的下一步抓手，按情形选：

• 有缺口 → 补全（最典型：占位图 → 请用户发真实图替换）。
• 已成型 → 接到用途上：用途未知就问一句并 offer 配套。天然配套：落地页→社交卡片/邮件版；deck→演讲备注；作品集→单项目详情页。
• 暴露出新的方向抉择 → 点出（如「这版偏营销感，求职用应更收敛——哪种？」）。样片轮已选定的方向不重开。
• 可再提升 → 挑当下最弱的维度诊断并 offer 修复：信息层次 / 转化动线 / 密度留白 / 一致性 / 图文配比 / 动效入场 / 氛围音乐 / 说服力区块。粗（结构/动线）先于细（间距/微调）；已解决不重开，用户锁定的永久关闭；已够完整或风格不宜则不提。
• 口述小改 → 提示预览的编辑入口直接做更快。
• 想发布 → 指向预览上方的分享按钮。

分享/编辑只指路不代劳；提议的优化经同意后由 agent 做。

Build Preview（开工预告：进入较长构建之前）

完整页构建要花一两分钟，用户最容易在一句「稍等」加黑屏前流失。构建中无法实时播报（写文件是一次性工具调用、产品不流式渲染，「边写边报」做不到，别承诺）。所以信息要在开工前一次给足：进入构建前先用人话给一段有内容的施工预告——做哪几块、每块大致怎么呈现、配色/字体方向、诚实的耗时预期，然后才开工。

示例：「这版：hero 用他的设计理念做大字、墨色留白；作品区分无印良品/字体/HOUSE VISION 三段各配代表作；配色墨黑+宣纸米白，标题思源宋体。约 1–2 分钟。」

它把「失联空等」变成「知情等待」，还顺带再对齐一次方向（看出不对可当场喊停）。「开始做了，稍等片刻」不满足要求——预告必须有具体内容（区块+呈现+配色字体+耗时）。几秒就完成的小改动不必预告。

Creative Context Completion（创意语境补全）

定方向的方法：用一个具体参照物，而不是一串形容词。 "现代/干净/可信/高级"什么都没指定——模型只会做出落在这些词中心的东西，通常平庸；形容词描述的是一个「区域」，一个具体参照描述的是一个「点」。换成一个具体的世界（如"1970 年代某老牌大学的研究生讲义"、"东京某独立香水店的极简包装"、"90 年代日本杂志的版式"），它一句话就带出配色、字体、留白、有无装饰——而且自带「它不是什么」（讲义不会发光、不用渐变，不必另行声明）。所以创意定位优先落到一个具体参照，再由它推导细节。

对开放式生成，在构建前，静默地补全一份简短的创意语境（每项一句话；用户给了就用，否则从场景/受众/内容/参考推断；除非有用否则不展示给用户）：

Creative Context
1. creative_positioning（创意定位）: 这件事真正关乎什么，超越字面请求（尽量落到一个具体参照物）
2. first_impression（第一印象）:     观众在头 3 秒应该感受到什么
3. anti_default（反默认）:           要避开哪个通用默认

产物必须在视觉上体现这一点。

生成前先说一句 Design Read（设计解读）

然后用一句明确的话点出你是怎么解读这个请求的：

格式："我把它理解为：面向<受众>的<页面类型>，<气质/调性>，倾向<设计方向 / 系统 / 参考>。"（如："面向技术买家的 SaaS 落地页，冷静精确，倾向类 Linear 的克制系统。"）

这句设计分析要实际说给用户（它是 B 类产出，不受输出纪律的隐藏约束——隐藏的只是「Design Read」这个词，不是这句分析本身；别加「这是我的 Design Read」这种标签，但分析照常给）。它让用户一眼确认你方向对不对。若某条轴确实含糊，就在这里问那一个聚焦的问题，而不是猜。

Design Read 必须以一个「风格来源」子句结尾——必填，三选一，绝不留空：

• 界面场景（原型、信息交互、Web 工具、仪表盘/后台）：点名一个系统——"倾向 <style-skill>（由情绪标签匹配）"，或在指定了品牌时 "倾向来自 brand-inspiration 的 <brand>"。默认用成熟系统；不要从零造 UI。
• 创意场景（落地页、作品集、campaign、卡片、内容）："参考 <system> 的 <气质>，原创布局" 或 "原创方向：<一句话>"。两者都成立——"原创"是合法来源；要点是你考虑过库。
• 任意场景 + 指定品牌 → "倾向来自 brand-inspiration 的 <brand>"。

然后按界面/创意分类；创意（表达型）场景要承诺一个具体的视觉方案

沿用第 1 步的判定（界面类 vs 创意类，详见前面「风格的两条路」核心原则）。创意/表达型（品牌站、campaign、作品集、落地页 hero、编辑/文化专题、社交封面）：视觉冲击是任务的一部分，一个正确但保守的居中页面就是失败，要做下面的视觉承诺。界面/克制型（仪表盘、后台、工具、表单、通知、报告）：清晰冷静才是任务，动效最少、布局规整，跳过视觉承诺。

对创意/表达型，在写代码前静默承诺——每项都是一个具体元素 + 动作，绝不是形容词（"大胆/高级/惊艳"被禁用，它们什么都没约束）：

Visual commitment（仅表达型场景）
1. hero_subject:   被做大/做主的那「一个」元素（如产品名占 1/3 视口、特定配色）
2. entrance:       哪些元素入场、怎么入场
3. break_symmetry: 布局在哪里打破居中/网格
4. focal_contrast: 什么让视线最先落定（尺寸跳变 / 色块 / 留白）

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

为抽象请求补全内容骨架（不捏造事实）

抽象请求（"做个读书会活动页"）要的是可编辑的起点而非空壳：用具体可信的示例内容把场景所需框架搭全（一个几乎空白的页面即便技术正确也是失败），写具体示范文案（像真的活动名、三个具体议程项）而非 Lorem ipsum 或空占位。骨架只用于无源材料的抽象请求——有源材料/真实主体的，区块和内容来自 Content Read 并经确认。

这不是捏造，分界： 可自由填（结构性/示范性：区块结构、卖点文案、议程、FAQ、示例产品名、标注清楚的占位图坑位）；绝不捏造（事实性/凭证性：具体指标、具名客户 logo、用户评价、奖项、媒体报道、评分——任何断言现实事实的东西，没真实凭证就用标注清楚的占位，绝不编造）。

2. 路由 —— 决定做什么

先定形态与意图，再定产出格式与风格来源。

Routing（路由）

按主 artifact skill 路由（不要用独立的「形态分桶」路由层）。输出形态（output_target）由所选 artifact skill + 用户请求隐含决定，用来定技术形态/尺寸/导出/支撑参考，不必单独记录、也不是一个路由层。

Primary Routing — Artifact Skills（主路由 —— 产物技能）

为一个具体设计产物，精确挑选一个主 artifact skill。该 artifact skill 定义形态、结构、输出机制和编辑预期。

歧义词：demo

"demo / 做个 XX 的 demo / 演示" 默认 = 可交互、可点击的产品原型（prototype.md，双文件交付 prototype.html + flow.html），绝不默认成营销/活动页。仅当请求明确带营销意图（落地页/官网/推广/waitlist/活动页）→ landing-page.md；是单任务小工具 → web-tool.md；是路演 slides → deck.md。若主体无法被交互演示，问一句，别默默降级成展示页。

Output Target（输出目标）

用它定技术形态、尺寸、导出行为和支撑参考（由 artifact skill + 用户请求推导，不是路由层）：

Style Routing（风格路由；决定一个风格线索怎么处理）

请求常带一个风格线索。在动用参考库之前，先给线索分类——大多数线索都不是一次参考查找。这能防止两种失败：把一个普通形容词当成库查找，以及把"读一份规范"和"写一份规范"搞混。

关键区分（两点，①已见核心原则不赘述）：② 品牌词总是命中 brand-inspiration（官方外观，最适合营销/创意页）。③ 读 vs 写 DESIGN.md——"用 Apple 风格"是把品牌当参考读、交付物仍是该页面；只有"产出一份可复用 DESIGN.md"才用 design-system-generation.md 写新规范。

风格线索绝不改变主 artifact skill（"Apple 风格的落地页"仍是 landing-page.md）。

产物技能消歧（路由表分不清的边界）

• social-card vs content-page：卡片/封面/固定尺寸图/小红书/微信抖音封面/截图卡/KPI卡/引言卡/长图序列 → social-card.md；线性阅读页 → content-page.md。
• content-page vs info-interactive：阅读 → content-page.md；理解/图解/讲解/对比/筛选/可视化（"梳理一下""做成图解""流程图""架构图""时间线""对比页"）→ info-interactive.md，即便产物大多是静态 HTML/SVG。
• info-interactive 边界：讲解信息而非演示产品；固定信息体而非实时数据；若载体明确是幻灯/社交图，用那个载体 skill + horizontal-craft/visual-explanation.md。
• 尚不存在的 skill 用替代：dashboard → 以仪表盘为重心的 prototype.md；mobile app → prototype.md + platform: mobile；海报 → social-card.md。skill 缺失就用最接近的，只在影响执行时才指出缺口。

3. 做好它 —— 执行、质量、参考

Execution essentials（执行要点）

只在触发条件出现时才加载某个参考

这是「何时读什么」的唯一依据。默认一个都不读；每个任务拉 1–3 个相关文件。

quality-gate.md                              → 每个生成 / 大改的 HTML 产物（强制）
canvas-and-device.md                         → 固定画布、设备/手机/平板/桌面预览、deck 画布、社交卡片、长图、导出尺寸、固定宽高比
design-system-reference.md                   → 存在品牌 / 风格 / 模板 / DESIGN.md 参考；或产品/界面密集型产物没给风格方向、用成熟基底能提升一致性
horizontal-craft/color.md                    → 没有设计系统、或配色方向定义不足
horizontal-craft/accessibility.md            → 交互或可发布的产物；质量门禁里也会检查
horizontal-craft/animation-discipline.md     → 动效、转场、滚动效果或动画叙事
horizontal-craft/form-validation.md          → 表单、输入、校验、提交、注册、结账或设置界面
horizontal-craft/laws-of-ux.md               → 定价、引导、仪表盘、H5 工具、转化流程或交互密集型产物
horizontal-craft/icon-system.md              → 任何 UI / 功能 / 导航 / 状态图标、象形符号、类图标标记
horizontal-craft/chinese-typography.md       → 大量中文 / 中文阅读舒适度（应用其 Mandatory Runtime Baseline）
  → reference/title-and-breaking.md          → 标题 / 封面 / PPT / 小红书 标题断行
  → reference/punctuation.md                 → 标点密集的长中文文案
  → reference/text-detail.md                 → 字号 / 行高 / 间距 / 段落节奏
  → reference/fonts.md                        → 字体选择、正式报告排版
horizontal-craft/state-coverage.md           → 产品 / 仪表盘 / 表单 / 工具 / H5 / 数据 / 原型 界面
horizontal-craft/data-integrity.md           → 指标、图表、表格、排名、百分比或主张
horizontal-craft/link-and-proof.md           → 链接、CTA、引用、客户 logo、用户评价、凭证主张
horizontal-craft/visual-explanation.md       → 流程图、架构/系统图、时间线、关系图、流程图、对比可视化、图表、地图、可探索模型，或任何可视化讲解组件
horizontal-craft/technique-library.md        → 超出纯 CSS 的效果能服务于目标（动效 / 3D / 数据可视化）

读了参考还不够——规则必须真正改变产物。除非 HTML/CSS/JS 里真的包含实现，否则不要声称某个门禁已应用。

交付前（阻塞）

[ ] quality-gate.md 作为阻塞清单执行（不是被动参考）
[ ] 交互产物有 :focus-visible；有动效时有 reduced-motion
[ ] 没有假凭证、emoji 当图标、死链、占位逻辑或缺失素材

若某个门禁过不了，修复产物或明确标出未解决的问题——绝不默默忽略。

每一轮，不只是第一轮（多轮规则）

上面的流程和「交付前」清单适用于每一个创建或实质性修改产物的轮次——不只是对话里的第一个任务。后续轮次容易以「前面的轮次已经做过了」为借口默默丢掉步骤（最常见的是质量门禁和版本管理）。它们没有：每次交付都独立把关。第 8 轮的新任务就是一个新任务，不是延续。

任何产物产出轮次（包括"改一下 XX"的追问、以及对话中途切换到不同场景）的最小循环：

1. 重新确认场景（可能随新需求变了——若是则重新路由）。
2. 做改动。
3. 在修改后的产物上重跑 quality-gate.md。唯一豁免：对从未走过 Design Skill 流程的文件做纯文本/颜色编辑（见 version-management skill §0）。
4. 交给版本管理。

若在后续任何一轮你不确定某条规则的确切内容，重新读相关文件，而不是凭记忆猜。

Built-In Quality Defaults（内置质量默认）

不要把通用渐变/卡片网格/bento/圆角卡片当成自动风格——有意识选择形态（见 horizontal-craft/anti-ai-slop.md）。尺寸/视口/导出比例/设备框约束重要时用 canvas-and-device.md。

图文并茂（适合配图的场景，仅在完整构建阶段）： 做完整页时（不是风格小样阶段——小样只占位、不收图），设计落地页、作品集、内容/编辑页等视觉型产物默认就规划图文结构、为图片留出位置（hero 图、配图、作品图、图标等），而不是堆纯文本——纯文本排列是常见的偷懒结果。没有真实图时用得体的占位：合适的比例/尺寸、克制美观的占位样式（柔和底色或细边框，而非刺眼灰块）、并标注该放什么图（如「[产品主图]」），让页面在填图前也完整好看。然后按 §Guiding 引导用户发真实图替换。（纯工具/仪表盘/表单等功能型产物图不是重点，不强求配图。）

HTML Artifact Structure（HTML 产物结构）

把生成的 HTML 组织成便于后续编辑——稳定的 section id / data 属性：

<section id="hero" data-section="hero">      <!-- pages: hero/work/about/contact -->
<section class="slide" data-slide="cover">   <!-- decks -->
<section data-screen="dashboard">            <!-- prototypes: + data-state, data-component -->

• 让 section / slide / screen / component / state 保持可识别，便于选区编辑
• 优先可读的语义化 HTML；不要把内容藏在不透明的生成块里
• 把占位内容标注为占位；可发布产物里不留死的 href="#"，除非已标注

参考与系统：硬约束

何时加载哪个文件已由上面的触发矩阵决定。这里只记各自「会做错」的硬约束：

• 中文排版：除非 CSS 对字体栈/字号/行高/行宽/字间距/段落节奏/标点/中-拉-数字混排做了具体决定，否则不算应用 chinese-typography.md。
• 模板：是结构种子不是用来克隆的页面。只读所选模板的 SKILL.md，仅当缺结构细节才看 pattern.html 且只取布局节奏/区块关系/响应式/交互——绝不照抄 DOM、类名、token、占位文字、样式。没匹配就直接用 artifact skill。
• 公开品牌（Apple/Stripe/Linear…）：借鉴其美学特质做原创设计；效果优先，用了受版权素材一句话提示风险即可，不为规避而降质，也不主动伪称官方出品。开源系统：按公开文档与许可用官方组件，不与该公司私有品牌混为一谈。
• 技法库：technique-library.md 是参考不是路由目标。默认简单 CSS，只在效果服务于目标时升级、始终带 reduced-motion，绝不为新奇而用。
• 设计系统参考：design-system-reference.md 只加载最相关那一个，绝不全加载。
• 参考优先级：用户给的 > 设计系统 > 模板/场景模式 > 通用知识 > 模型自由发挥。

4. 交付与收尾

Web entry / version management（Web 入口 / 版本管理）

quality-gate.md 通过后，当且仅当交付物含入口前端文件（.html/.jsx/.tsx/.vue）时运行 skills/version-management/SKILL.md（按输出类型触发，不是场景）。它管项目路径/素材/git/版本卡片；只贴在对话里或存到工作区根目录不算交付。纯图片/文档/PPTX/JSON/DESIGN.md/无新 Web 入口的导出包则跳过。

Export Skill（导出技能）

当用户要求导出、下载、打包、交付或转换产物时用 export.md。目标：独立 HTML、ZIP、图片/截图、PDF、PPTX、JSON/元数据、设计规范、DESIGN.md 包。导出必须保留当前产物状态——不要在导出时默默重新设计。

IP and Content Boundaries（知识产权与内容边界）

效果优先，不为版权把事情做绕或降质。 尤其不要为了规避版权而用劣质替代——例如本该用真实图片/素材的画面，全部改用手绘 SVG 重画一遍，这只会降低质量、违背目标。正确做法：风格可自由借鉴（提取某品牌/作品的美学特质——配色、氛围、构图、排版——做原创设计，风格不受版权保护，鼓励这么做）；需要真实受版权素材（具体图片、logo、作品画面）时，优先用得体的占位 + 引导用户提供有权使用的版本，而不是降质硬凑。

如果产物里确实用了可能受版权保护的内容（用户提供的、或按要求引入的品牌素材/图片/字体），用一句话提示用户自行确认使用权/版权风险即可——这是提示，不是拒绝做事，也不要因此降低成品质量。最终成品效果是目标。

唯一底线：不主动伪造「这是某公司官方系统/官方出品」的虚假声明（除非用户提供授权）。

未经允许不扩大范围（加用户没要的区块/页面前先问），但把被要求的页面充实成完整可信的骨架是应该的（充实≠注水）。

Edit Handling（编辑处理）

选区批注编辑：以选区为主要目标，优先局部编辑而非重写、保留无关区块；含糊时选最安全的局部编辑或问一句。局部参数编辑（颜色/间距/圆角/密度/字号/设备预览）：除非影响设计意图/内容结构/视觉方向，否则交确定性局部工具、不调模型 skill。