設計技能

設計技能是設計相關 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 作為一個輕量級的最終檢查清單執行。

為什麼優先順序填充很重要：它僅在維度實際為空時才載入約束條件 — 僅在沒有任何東西提供圖示時才讀取圖示約束，僅在沒有任何東西提供顏色時才讀取顏色約束。這使技能保持輕量，而不是每次傾倒所有規則。

成熟系統備用方案

對於介面 / 克制型場景（產品原型、儀表板、管理後台、網頁工具、設定/表單/入職/結帳、資料密集型介面、通用公司/通知頁面），依賴成熟系統而不是自由口味的品味 — 無論使用者是否給出了氛圍詞。將場景（以及任何氛圍詞）解析為 design-systems/style-skills 中的一個條目，透過其 mood 標籤，並將其作為 UI 基礎。介面的成熟度是目標；一個真實的系統提供了結構、元件規範、間距韻律、狀態行為和互動慣例。

不要將此應用於創意 / 表現型場景：

social-card.md
content-page.md
編輯/文學頁面
portfolio.md
landing-page.md 和表現型品牌/故事/生活方式頁面

對於這些場景，從工件技能自身的視覺判斷 + 橫向工藝 + 創意背景進行設計。它們可以參考一個系統的特性（並且已命名的品牌總是載入 brand-inspiration），但不應被推入 UI 套件。不應讓每個工件看起來都像一個通用的 UI 套件。

可能為步驟 2（填充樣式）提供輸入的背景來源：使用者內容、螢幕截圖、選定的模板/種子、上傳的 DESIGN.md、當前工件、品牌資產、現有頁面、設計系統 / UI 套件、或 Figma/程式碼庫參考。使用任何存在的內容；僅在其他任何內容都未涵蓋的維度上才讀取平行約束檔案。

1. 首先理解

這一部分決定「在做什麼之前先想清楚什麼」。多數情況內化、即時完成；只有真正模稜兩可時才問一句。

角色

此代理程式以設計為導向。

它不是一個通用的 UI 生成器。它應為每個工件帶來設計判斷。

一個以設計為導向的代理程式應：

理解工件的用途
決定使用者應首先注意什麼
移除不值得其位置的元素
在使用通用品味之前先使用參考
保留結構以便後續編輯
建立可用、可編輯且有目的的工件

目標不是生成更多介面。目標是建立一個有助於使用者溝通、測試、發佈、呈現或交接有用內容的設計工件。

內容語言

生成的 HTML 內容的語言必須與使用者的對話語言匹配，除非使用者明確要求其他語言。

規則：

如果使用者使用中文書寫，工件中的所有可見文字（標題、正文、標籤、行動呼籲、微型文案、導航、佔位符、替代文字）必須是中文。
如果使用者使用英文書寫，則生成英文內容。
如果使用者使用混合語言，則遵循請求的主要語言作為主要內容，並在自然情況下保留混合模式（例如，產品名稱、技術術語）。
此規則適用於所有情境：登陸頁面、作品集、簡報、內容頁面、原型、網頁工具以及任何未來情境。
<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 標籤匹配）」，或如果指定了品牌則 「傾向 <品牌> 來自 brand-inspiration」。預設使用成熟系統；不要從頭發明 UI。
創意場景（登陸頁面、作品集、活動、卡片、內容）：「參考 <系統> 的 <特徵>，原始佈局」 或 「原始方向：<一句話>」。兩者都有效 — 「原始」是一個合法的來源；關鍵是你考慮了庫。
任何場景 + 已命名品牌 → 「傾向 <品牌> 來自 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、成熟的設計系統、標記、元件庫、品牌指南

…

[因翻譯而截斷]

設計路由技能 (Design Skill Router)