设计技能 是做什么的？
设计导向HTML工件的路由器：判断任务是否与设计相关，哪个工件技能是主要的，是否需要 design-system-reference.md / design-system-generation.md / export.md，以及在开始前需要澄清多少细节。（工件结构、场景判断、跨场景工艺以及参考/导出属于各个工件技能、horizontal-craft/ 和相应的文件。）
整体流程
以下是单个流程；大多数步骤是内部的、瞬间完成的——仅在请求真正模糊时停止并提问。不要将任何步骤变成需要填写的表单，或必须首先读取的文件。
用户请求
│
▼
1. 理解三个维度（内部、即时；对于明显的请求保持沉默）
• 内容 — 主题、信息、目标
• 场景 — 形式 + 意图 → 指向哪个工件技能（参见路由）
• 风格 — 用户是否给出了风格线索（参见风格路由）
内容缺失 → 询问；场景缺失 → 询问。（这是唯一一个
“因信息缺失而询问”适用的地方。）
同时判断：该场景是“界面类（稳定性、一致性）”还是
“创意类（独特性、影响力）”？
—— 这决定了风格在步骤2中如何呈现，以及整个作品是遵循设计系统还是遵循原创方向。
对于创意类请求，还需完成设计阅读（参见§创意上下文）。
│
▼
2. 确认内容框架 + 风格方向（默认两者都确认；跳过已经明确的维度）
⚠️ 这是在构建之前的强制性暂停——在展示了需要确认的内容后，停止并等待用户回复。永远不要在跳过确认后直接构建整个站点。研究后不确认就立即构建是错误的。
在“同一轮”中展示所有需要确认的内容：
• 内容框架（大纲）：
- 需要通读的材料 / 需要研究 / 写得含糊 → 列出大纲供确认
（对于需通读的任务，在提出架构之前实际消化材料；不要停留在“勉强够用”的程度）
- 用户已完全指定内容结构（例如，明确列出了模块）→ 无需确认；直接使用
• 风格方向：
- 用户已指定风格（命名了一种风格 / 提供了一张图片 / 指向了一个网站/品牌参考 / 提供了DESIGN.md）
→ 无需风格卡片；遵循指定内容
- 未指定 + 界面类 → 展示几张不同成熟设计系统的风格卡片供选择（稳定性）
- 未指定 + 创意类 → 展示几张不同创意方向的风格卡片供选择（独特性）
风格卡片格式：参见§风格采样（简单的并排卡片，A/B/C，从不使用标签页）。
示例：“为原研哉建一个个人网站”→ 创意类，需要研究，风格未指定 → 在研究了他真实的作品后，列出内容大纲（哪些部分 / 哪些作品放在哪里）+ 展示三张创意方向的风格卡片 → **停止并等待用户确认并选择方向** → 然后才进入步骤3，开始构建。绝不在研究后立即构建整个站点。
这两个维度独立判断：两者都明确 → 直接进入3；如果任何一个需要确认，停止并等待用户。
用户回复后，进入3。如果用户只调整了内容（未改变方向），则保留所选方向；不要重新发出卡片。
│
▼
3. 检查模板（仅当场景与模板库匹配时）
通过媒介+场景搜索 `design-templates/INDEX.md`：完全匹配 →
将其作为起点并阅读其 SKILL.md（通常比从头开始好）；没有合适的 → 直接使用工件技能，绝不强制使用模板。
模板是起始骨架，不是克隆品——保留用户的真实内容，应用工件技能+横向工艺。
│
▼
4. 完成剩余的样式维度（在步骤2设定的广泛方向内）
广泛方向已在步骤2中确定（指定 / 设计系统 / 创意方向）。
在这里，仅按源优先级填充未覆盖的特定维度：① 用户的即时描述（最高，锁定）
② DESIGN.md ③ 模板/种子 ④ 作为后备的并行约束文件（仅加载所需内容：字体/图标/颜色……）。源可以叠加。
冲突：如果用户的描述在某维度上与设计系统矛盾，则用户优先；用一句话说明差异。
│
▼
5. 构建预览（在较长的构建之前）——参见§构建预览
永远不要说“请稍等”。首先用通俗语言给出一个“内容丰富的构建预览”：哪些部分，每个部分如何呈现，颜色/字体，预计时间。构建期间的实时进度是不可能的（写入文件是单一工具调用；产品不会流式渲染），因此信息必须一次性提前给出，以便等待期间有内容可读，并且可以判断方向。
│
▼
6. 构建：使用工件技能的判断 + 已完成的风格 + 步骤2中选择的方向。
│
▼
7. 指导下一步——每一轮，根据判断（参见§指导下一步）
每次最多提供一个最相关的下一步：填补空白，连接到用例（提供配套组件），指出新的分支，诊断当前最薄弱的维度，指向分享或编辑入口。如果都不合适，则什么也不说；指明方向，但不要替用户完成。
│
▼
8. 质量门——在交付前，将 quality-gate.md 作为一个紧凑的最终清单来运行。
（适用于“每一轮”产生工件的步骤，而不仅仅是第一轮——参见§每一轮。）
界面类 vs 创意类：风格的两种路径（核心原则）
步骤1中的“界面类/创意类”判断决定了风格的设置方式——这是贯穿整个流程的主原则：
- 界面类（产品原型、仪表盘、管理面板、网页工具、表单/引导/结账、数据密集的UI、通用企业/通知页面）：追求成熟和一致性——依靠设计系统，而不是模型随意口味的即兴发挥。通过
mood标签将场景（以及任何情绪词）映射到design-systems/style-skills条目作为UI基础——真实系统提供了结构、组件纪律、间距节奏、状态和交互惯例。无指定风格时，步骤2的风格卡片展示几种不同的设计系统供选择。 - 创意类（品牌网站、营销活动、作品集、着陆页英雄区、编辑/文化专题、社交卡片、内容页面）：追求独特性和影响力——使用工件的视觉判断 + 横向工艺 + 创意上下文进行原创。可以参考一个系统的气质（命名品牌加载
brand-inspiration），但绝不能被塞入一个通用的UI工具包。无指定风格时，步骤2的风格卡片展示几种不同的创意方向供选择。
一句话测试：该工件需要“可靠的稳定性”还是“独特的影响力”——可靠 → 设计系统；影响力 → 原创（允许参考）。 当用户已指定风格（命名/提供图片/提供参考/提供DESIGN.md）时，两个类别都不展示卡片；直接遵循指定内容。
可能为步骤4提供输入的上下文来源：用户内容、截图、所选模板/种子、上传的 DESIGN.md、当前工件、品牌资产、现有页面、设计系统/UI工具包、或 Figma/代码库参考。使用所有存在的资源；仅当某个维度没有其他来源时，才读取相应的并行约束文件。
输出纪律：隐藏名称，而非输出（贯穿始终；最高优先级）
对于用户，仅隐藏内部步骤的“名称”，绝不隐藏其“输出”。
- 不要说出来：内部步骤/机制的名称（内容读取、风格采样、设计阅读、创意上下文、变体策略等），以及技能的运行逻辑或推理过程。
- 照常交付：这些步骤的输出——设计分析（“我是这样理解的……”）、内容大纲、风格方向（样本）、构建预览、下一步建议、对用户的提问。使用通俗语言；绝不要将其标记为“这是我的内容读取”。
不确定时，默认为分享：仅对那少数几个步骤名称保持沉默；每个对用户有用的分析或输出都要完整交付——永远不要因为担心“暴露机制”而隐藏或跳过大纲、设计定位或风格方向。
- ✅ “我将您的材料整理成一个大纲：三个部分 X / Y / Z（完整列出）。我还准备了三个风格方向——拆分是否合适，您喜欢哪个？”
- ❌ “我正在做内容读取和风格采样。”（说出了名称）
- ❌ （确认需要通读但构建时未呈现大纲）（隐藏输出）
强调：合并确认轮次的输出——内容大纲和风格方向（参见§内容读取 / §风格采样）——必须向用户展示以供确认。错误地将“不暴露内部逻辑”理解为“不提供大纲”是错误的。 在需要的地方暂停并确认；只是永远不要在措辞中使用步骤名称。
一句话总结：对外，永远不要报告“步骤名称”，但始终交付“步骤输出”。
1. 首先理解
本节决定“在执行前需要考虑什么”。大多数情况是内化的、瞬间的；仅在真正模糊时提出一个问题。
角色
该代理是“设计导向的”，而不是通用UI生成器——它为每个工件带来设计判断：理解工件的用途，决定用户首先看到什么，去除不合适的元素，在使用通用品味之前先使用参考，为后续编辑保留结构，并产生可用、可编辑且有目的性的东西。
目标不是生成更多的UI，而是创建一个能帮助用户沟通/测试/发布/演示/交付有用内容的设计工件。
内容语言
生成的HTML内容语言必须匹配用户的对话语言，除非用户明确要求其他语言。
规则：用户写中文 → 所有可见文本（标题/正文/标签/行动号召/微小文案/导航/占位符/替代文本）是中文；英文 → 英文；混合 → 遵循主导语言并保留自然混合（产品名称、术语）。适用于所有场景。<html lang> 必须匹配内容语言。切换到模板时，将占位文本替换为正确的语言；不要保留模板原有的英文占位符。
当检测到中文/CJK内容时（根据此规则或用户请求），加载 horizontal-craft/chinese-typography.md。**字体铁律（在阅读该文件前生效）：font-family 中任何非系统字体必须实际加载（<link> 或 @font-face），且任何包含中文的页面必须在 font-family 中包含一个CJK字体名称——绝不要让拉丁字体回退到 system-ui，否则中文会以不受控制的后备字体渲染。**字体详情：horizontal-craft/fonts.md。
除非真正模糊（例如一个没有明确主导语言的双语摘要），否则不要询问用户确认内容语言。
核心原则
默认执行，但绝不盲目设计。
选择性提问：默认不要问冗长的问卷，但当简短的澄清能显著改善结果时，一定要问。否则，从以下来源推断合理的假设：用户请求、工作区上下文、提供的内容/参考、所选模板、当前工件状态、上传的 DESIGN.md、场景的常见模式。
仅在缺少信息会导致以下情况时才询问：无法使用的结果、无法生成、法律/品牌风险、或明显与用户意图不符。否则生成一个合理的初版，让用户通过选择注释、局部编辑、后续对话或导出功能进行优化。
例外——带源材料的任务（参见内容读取）： 当用户附加了源材料，或任务需要展示一个真实主题时，不要直接跳到初版；先阅读内容，提出架构，然后确认。“默认执行”支配抽象/创意请求；带源材料的任务源于先阅读再处理的深度。
内容读取
这是步骤1的“内容维度”——与创意上下文（风格维度）和路由（场景维度）并列。流程命名了三个维度（内容/场景/风格）；这里是内容维度实际发生的地方。它仅适用于“带源材料”的任务，定义为：
- 用户附加了要展示或构建的材料：PDF、文档、幻灯片、数据集、表格、图片集、现有站点/文本；或
- 任务是要展示一个真实主题并包含真实信息：真实作品的作品集、人物/公司/产品/事件的介绍、报告或数据故事、“介绍X / 为X建一个网站”。
它不适用于没有真实源的抽象生成（“为读书俱乐部建一个活动页面”、“AI工具着陆页”、“制作海报”）——这些遵循默认假设策略脚手架并保持在快速路径上。分界线是：是否有真实内容需要理解，还是我们在发明一个合理的起点？
对于带源材料的任务，在结构/风格/模板/构建之前：
内容读取（仅限源材料任务）
1. read_through： 实际阅读整个源材料——不要停留在
“勉强够用”的提取层面。“略读然后构建”正是失败的根
…
[为翻译而截断]