antilsabh789-pixel/kabaddi-pro

Design Skill

Design Skill 是設計相關 HTML 成品工作的路由器。

它負責決定：

• 該任務是否與設計相關
• 哪個成品技能應作為主要執行者
• 任務是否應使用 design-system-reference.md
• 任務是否應使用 design-system-generation.md
• 任務是否應使用 export.md
• 在行動前需要多少釐清
• 如何在路由前快速閱讀請求（請參閱「生成前」）
• 如何應用內建的設計品質預設值
• 如何保持生成的 HTML 結構化，以利於未來編輯

Design Skill 應保持輕量。

成品特定的結構規則屬於成品技能檔案。情境的商業判斷存在於該情境技能中。跨領域的工藝規則屬於 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 內容語言必須與使用者的對話語言一致。

規則：

• 如果使用者使用中文書寫，成品中的所有可見文字（標題、正文、標籤、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. 創意定位:      這真正關乎什麼，超越字面上的請求
2. 第一印象:      觀看者在前 3 秒應感受到什麼
3. 反預設:        應避免的通用預設

成品必須明顯反映這一點。

在生成前陳述一行設計解讀

然後承諾一個明確的行，命名你如何解讀請求：

形式：「解讀為：<頁面種類> 給 <受眾>，<性格/氛圍>，傾向於 <設計方向/系統/參考>。」

• 「解讀為：給技術買家的 SaaS 著陸頁，冷靜且精確，傾向於內斂的 Linear 風格系統。」
• 「解讀為：給年輕消費者的國潮茶品牌活動，大膽且喜慶，傾向於大號字體 + 強烈色彩，表現型。」
• 「解讀為：內部管理儀表板，內斂且易讀，傾向於成熟的設計系統基準點。」

可能對使用者顯示。如果某個軸向確實不明確，在此處提出單一聚焦問題，而不是猜測。

設計解讀必須以一個風格來源子句結束——必需的，選一個，永遠不要留空：

• 介面場景（原型、資訊互動、網頁工具、儀表板/管理）：命名一個系統——「傾向於 <style-skill>（從 mood 標籤匹配）」，或 「傾向於 <brand> 來自 brand-inspiration」（如果品牌已命名）。預設使用成熟系統；不要從頭發明 UI。
• 創意場景（著陸頁、作品集、活動、卡片、內容）：可以是 「參考 <系統> 的 <特性>，原創版面」 或 「原創方向：<一句話>」。兩者都有效——「原創」是合法的來源；重點是你考慮了函式庫。
• 任何場景 + 已命名品牌 → 「傾向於 <brand> 來自 brand-inspiration」。

然後分類場景；對於表現型場景，承諾一個具體的視覺計劃

• 表現型（品牌網站、活動/宣傳、作品集、產品著陸頁英雄區、編輯/文化特輯、社群封面）：視覺衝擊是工作的一部分；正確但安全的置中頁面是失敗的。
• 內斂型（儀表板、管理後台、內部工具、表單、政府公告、報表、資料表、規格）：清晰與平靜是工作；保持動畫極簡、版面規則，並跳過下方的視覺承諾。

對於表現型場景，在編碼前靜默地承諾——每個項目是一個具體的元素 + 動作，而不是一個形容詞（「大膽/高級/令人驚訝/動態」是被禁止的，因為它們沒有約束任何東西）：

視覺承諾（僅限表現型場景）
1. 英雄主體:   被放大/主導的 ONE 個元素  (例如產品名稱 '桂花酪酪' 佔據 1/3 視口，金色+朱紅)
2. 入口:       哪些元素以何種方式動畫進入      (例如標題字元交錯進入 + 花瓣從頂部落下)
3. 打破對稱:   版面在何處打破置中/網格      (例如價格標籤在右下角傾斜；印章溢出邊緣)
4. 焦點對比:   什麼讓眼睛首先停留         (尺寸跳躍 / 色塊 / 英雄區周圍的留白)

一個完全置中、對稱、靜態且沒有主導元素的頁面是預設的平庸結果——對於表現型場景，這意味著承諾未被兌現。執行每個承諾的項目。動畫細節 → horizontal-craft/animation-discipline.md。

範例（內聯）

「做一個 GLM-5.1 模型介紹網站」→ 定位：推理/執行基礎設施，而非通用的 AI 頁面；第一印象：冷靜、精確、技術感；反預設：避免通用的 AI-SaaS 英雄區 + 功能卡片範本。場景：表現型 → 英雄主體：「GLM-5.1」過大並帶有單一強調色；入口：標題 + 標語交錯淡入；打破對稱：規格數字偏移到一側；焦點對比：大字型與深邃的負空間形成對比。

初始階段產品假設

假設大多數使用者不提供高階設計脈絡——並非 Figma 檔案/MCP、成熟的設計系統、代碼、組件庫、品牌指南

…[為翻譯而截斷]