設計技能
Design Skill 是設計相關 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 作為一個精簡的最終檢查清單執行。
為什麼優先填充很重要：它僅在某個維度實際為空時才載入約束條件—— 你只在沒有提供圖示時才讀取圖示約束，只在沒有提供顏色時才讀取顏色約束。 這使得技能保持輕量，而不是每次都傾倒所有規則。
成熟系統備用方案
對於介面 / 受限制的場景（產品原型、儀表板、管理面板、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 內容的語言必須與使用者的對話語言匹配，除非使用者明確要求其他語言。
規則：
- 如果使用者用中文書寫，構件中的所有可見文字（標題、正文、標籤、CTA、微文案、導航、佔位文字、替代文字）必須是中文。
- 如果使用者用英文書寫，生成英文內容。
- 如果使用者用混合語言，遵循請求的主要語言來處理主要內容，並在自然的情況下保留混合模式（例如，產品名稱、技術術語）。
- 此規則適用於所有場景：落地頁、作品集、簡報、內容頁面、原型、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>（從 mood 標籤匹配）」，或者如果命名的品牌，則為「傾向 <brand> 來自 brand-inspiration」。預設使用成熟系統；不要從頭開始發明 UI。 - 創意場景（落地頁、作品集、活動、卡片、內容）：可以是
「參考 <system> 的 <特性>，原創佈局」或「原創方向：<一行>」。兩者都有效 — 「原創」是合法的來源；關鍵是你考慮了庫。 - 任何場景 + 命名品牌 →
「傾向 <brand> 來自 brand-inspiration」。
然後對場景進行分類；對於表現性場景，承諾一個具體的視覺計畫
- 表現性（品牌網站、活動/促銷、作品集、產品落地頁英雄區、編輯/文化特色、社交封面）：視覺衝擊是工作的一部分；一個正確但安全的居中頁面是失敗的。
- 受限制（儀表板、管理後台、內部工具、表單、政府通知、報告、數據表、規格）：清晰和冷靜是工作的重點；保持動畫最小化、佈局規則，並跳過下面的視覺承諾。
對於表現性場景，在編碼前靜默承諾 — 每個項目都是一個具體元素 + 動作，永遠不是形容詞（「大膽/高級/令人驚訝/動態」是被禁止的，它們沒有約束力）：
視覺承諾（僅限表現性場景）
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 英雄區 + 功能卡片模板。Scene：表現性 → hero_subject：「GLM-5.1」超大尺寸並帶有單一強調色；entrance：標題 + 標語交錯淡入；break_symmetry：規格數字偏移到一側；focal_contrast：大號文字與深邃負空間形成對比。
第一階段產品假設
假設大多數使用者不會提供高階設計上下文 — 不是 Figma 檔案/MCP、成熟的設計系統、代碼、元件庫、品牌指南
…
[此處截斷以便翻譯]