UIUX 原型設計
圍繞實際任務設計產品介面。在實作應用程式之前，交付可供審查的 HTML。以使用者使用的語言進行；預設使用中文說明，並在必要時保留英文術語。此技能是自包含的：上游技能和付費參考服務是選用的，而非必要的相依項目。
1. 確定產品並保留其基準
首先閱讀適用的 AGENTS.md、HANDOFF.md、現有的 DESIGN.md 和目前的原型檔案。識別使用者、情境、進入點、主要任務、結果、商業價值、要求的畫面以及此版本範圍之外的內容。保留現有的品牌決策和其他人的編輯。自行解決常規細節；僅針對會實質改變設計的遺漏資訊提問。
根據簡報商定有邊界的畫面/流程清單，而不是任意數量的頁面。涵蓋每個要求的畫面（Web、小程式、行動裝置、桌面）；不要憑空發明不相關的應用程式。如果畫面範圍未知且專案無法確定，在繼續之前先問一次。繼承的 UI 應進行審計並建立不覆蓋現有內容的版本，而不是未經要求的重新設計。
閱讀 source-synthesis.md 中相關的決策規則章節（§1–7）；當需要解釋權衡取捨時，使用其來源地圖（§8–10）。它整合了所有七個來源儲存庫。產品任務清晰度、現有的設計合約和使用者選擇優先於登陸頁面慣例、風格禁令和隨機主題。
2. 研究參考資料，然後暫停以進行風格決策
閱讀 reference-research.md。從 Dribbble 開始；使用即時設計和 Behance 作為備用或補充。搜尋產品類別、使用者的任務和相關平台，而不僅僅是「漂亮的 UI」。使用可用的瀏覽器/搜尋工具；記錄實際檢查了哪些頁面和圖片。不要將搜尋摘要當作視覺審查。遵守存取限制；如果無法查看實際案例，請回報情況並要求提供參考資料或明確免除研究。
在 docs/prototype/versions/vX.Y.Z/（或專案既定的原型根目錄）下建立新版本。使用下面的 CLI 安全地開始。首先編寫 style-reference.html：通常是 2–3 個有區別且適合任務的方向、實際案例連結/創作者、觀察到的證據與您的解釋、標記範例以及一個用於比較的相同任務的原創小型 UI 研究。包含平台適用性、限制和您的建議。保留已知的品牌選擇；當使用者已經提供一個方向時，驗證它而不是強迫提供替代方案。
交付實際的 style-reference.html 並要求使用者選擇或修改它。在此處停止。 在使用者明確批准某個命名的方向（或在目前任務中委派該確切選擇）之前，不要建立完整的應用程式畫面、design-system.html 或最終的 DESIGN.md。本機選取的單選按鈕/卡片、推薦偏好、經過的時間或 CLI 記錄不是使用者授權。保留批准證據以及已批准的 HTML 的 SHA-256；對該版面的重大變更需要一個新的決策。不要將此閘門視為就無關、已授權的工作再次提問的許可。
3. 批准後建立完整的 HTML 原型
閱讀 prototype-contract.md 以及 platforms-and-quality.md 的相關章節。記錄使用者的實際決策；輔助工具記錄證據，但無法驗證誰提供了它。然後準備並用設計好的、可運作的成品替換生成的骨架：
index.html：原型首頁/導覽，包含版本、畫面入口、核心流程、風格參考和視覺規格連結。每個應用程式也應有自己的任務導向首頁。將實作/狀態細節保留在此審查中心，而不是產品 chrome 中。design-system.html：此版本中使用的元件的完整視覺規格：語意顏色、字體排印、間距、版面/密度、圖示、畫面、適用的元件狀態、互動/動畫以及回應式/平台差異。顯示實際渲染的範例，而不僅僅是名稱表格。DESIGN.md：規範性決策、Token 值、畫面/流程清單、互動、平台覆寫、無障礙性、出處和已知的原型限制。每個畫面的 DESIGN.md 僅說明相關的變化。- 每個要求畫面的 HTML 畫面：完整的協定關鍵路徑、合理的標籤化合成資料、導覽和有意義的狀態變更。共享語意 Token；符合平台特性的互動，而不是縮小的桌面截圖。
預設使用語意 HTML、CSS 變數和小的本機腳本。重用現有的框架/元件以降低複雜性；沒有強制要求的 React、Tailwind、shadcn 或網路依賴。靜態 HTML 原型必須能透過本機 HTTP 伺服器開啟，並在可行時應能透過檔案 URL 進行導覽。審查原型所需的素材應是本機的且已獲授權。保持原型與應用程式原始碼分離。
4. 驗證、版本化和交接
使用 platforms-and-quality.md 在窄和寬的視窗、鍵盤焦點、縮放和減少動畫模式下審查渲染結果；檢查適用的裝置/平台行為。測試實際的主要路徑以及重要的空/載入/錯誤/成功和極端內容狀態。不要從瀏覽器模擬中斷言裝置或原生 SDK 的接受度。修復觀察到的問題並重新檢查受影響的路徑。
執行結構驗證，然後將瀏覽器證據、視窗大小、測試過的流程和未解決的問題記錄在 QA.md 中。結構驗證無法證明視覺品質、業務完整性、權限強制執行、外部整合或生產準備就緒。明確回報未測試的項目。對於部署工作，測量相關的載入/執行時間/資源成本，而不僅僅報告功能檢查；一般的本機原型不需要生產基準測試套件。
保持先前的版本完整。閱讀 versioning.md 以了解批准失效、修訂、封存快照、變更日誌和最新版本導覽。不要靜默編輯已批准的版面或覆寫較舊的原型。交付實際檔案的連結、如何開啟它們、驗證了什麼以及哪些仍是模擬的。
輔助工具（Python 3，標準函式庫）
將 <skill-dir> 解析為此已安裝技能的目錄。命令僅作用於指定的專案；它們不會發布或更改應用程式原始碼。
python3 <skill-dir>/scripts/prototype.py init --project <project> --version v0.1.0 --surfaces web miniapp mobile desktop
# 使用實際研究編輯 style-reference.html；取得使用者的決策。
python3 <skill-dir>/scripts/prototype.py record-approval --project <project> --version v0.1.0 --direction "B" --evidence "來自此對話的確切使用者決策"
python3 <skill-dir>/scripts/prototype.py prepare --project <project> --version v0.1.0
# 替換每個待處理的骨架，實作商定的流程，並渲染/審查。
python3 <skill-dir>/scripts/prototype.py validate --project <project> --version v0.1.0 --complete
python3 <skill-dir>/scripts/prototype.py seal --project <project> --version v0.1.0 --summary "已審查範圍和重大變更"
record-approval 儲存一個工作流程記錄，而非身份或安全邊界。切勿偽造其證據。prepare 產生骨架，而非完成的原型。seal 記錄檔案雜湊；它不是視覺簽核或不可變的儲存。請同時使用 manifest 和 QA 證據。