設計 UAT
針對網站視覺實作，與其設計參考資料進行比對。預設產出英文、以問題為優先的 HTML 報告；若指定語言或報告格式，則依要求處理。此技能可在不同專案間重複使用。專案網址、框架對應、可接受偏差、憑證與執行證據等內容，不應存放在此技能資料夾中。
從使用者的範圍開始
使用提供的網站與 Figma 連結作為初始範圍。如果已有合適的專案設定檔，則重複使用；否則，直接在不必要求預先準備的路由清單或組態下開始探索。當 Figma 頁面代表某個版本交接時，清查整個頁面，並發現每個模組自身的測試路徑。提供的網站網址是進入點，而非路由限制。對於明確的完整頁面範圍，應予以尊重；記錄排除項目與封鎖狀態，而非默默以範例取代。對於未指定的較大範圍，應說明一個有用的審查邊界。取樣一個畫面不代表接受整個模組。
將專案資料保存在目前專案的可寫入工作空間中，並遵守儲存庫指示。一個有用的預設值是 design-uat/<project>/project.json 與 runs/<run-id>/，但應保留已建立的位置。在建立對應、建構報告輸入或記錄重新執行時，請參閱 project-data.md。
探索實際可用的工具。偏好使用 Figma 連接器取得設計結構與尺寸，並使用瀏覽器控制工具取得即時 UI。必要時，使用相關的工具指示與先備技能；此技能本身不提供這些工具。盡可能重複使用現有的授權登入。如果存取被阻擋，則繼續進行有用的獨立工作，並精確回報哪些狀態無法審查。
發現設計到頁面的對應
在比較圖片之前，先檢查設計階層與即時導覽。畫布可能包含模組容器、畫面框架、本地狀態範例、註記、說明與替代提案。先識別結構中的視覺目標，而非將整個文件版作為一個畫面匯出。
閱讀相關的註記與本地狀態範例。它們可能指定回應式行為、輸入維度、截斷或主框架未顯示的元件細節。使用可見/有效的節點內容；隱藏的元件輔助文字/錯誤文字，僅因存在於樹狀結構中，並不構成主動需求。
區分實際的頁面規格與一般互動的示意圖。一個一般的抽屜範例可能揭露現有模組中的差異，但並不建立每個類別的必填欄位。保留有用的跨模組發現，並附上其實際路由、導覽脈絡與基準限制；除非已知其歷史，否則標記為未確認的疑似舊版狀態。
使用模組脈絡、路由、可見頁面標題、欄位標籤、UI 結構與呈現外觀的綜合證據進行比對。在專案資料中記錄框架 ID、頁面/狀態、比較區域、信心度與對應狀態。一個網址可能有多種視覺狀態。不要將一個清單、一個開啟的抽屜、一個聚焦的輸入欄位與一個空白狀態混為一談。
對於理由充分的比對，在未經人工確認前，應標記為推斷。將真正模稜兩可的選擇批次標記給使用者，同時繼續處理不受阻擋的案例。將替代/備用設計記錄為在所選範圍之外，並附上理由；僅憑命名並不能確立已接受的版本。在重複使用前，應驗證先前儲存的對應關係與當前設計和即時頁面是否相符。
對於大型 Figma 檔案，應在本地保留原始元數據，並將簡潔的摘要回傳到上下文。在提取詳細子樹或螢幕截圖之前，先透過已知的祖先節點縮小範圍。避免重複載入整個檔案。
捕獲可比較的證據
在首次捕獲或診斷比較問題之前，請先閱讀 evidence-workflow.md。該文件涵蓋了工作區溢位、狀態比對、註解排除、動態內容、局部裁切與螢幕截圖接受標準。
透過導覽、聚焦與可逆的輸入變更，來暴露所需的視覺狀態。未經授權，不得為了取得螢幕截圖而提交業務變更。如果某個狀態需要無法取得的資料或寫入動作，應記錄該限制，而非憑空捏造。
在相容的視窗大小、縮放比例與主題下，精確捕獲設計區域與瀏覽器狀態。檢查字型/內容是否已載入，且目標是否穩定。拒絕載入中的暫態捕獲，除非載入狀態本身就是被審查的狀態。在將螢幕截圖用於報告之前，應先檢查它們。保留原始捕獲結果，以及任何裁切、疊加層與標記。
將差異同時基於兩張圖片，並在有用時，基於 Figma 幾何與瀏覽器元素邊界。將測量值歸因於其來源。當 Pillow 可用時，可使用 scripts/compare_regions.py 來進行選用的原生比例成對裁切與標記。報告渲染器本身僅需 Python 標準函式庫。
不僅要檢查單一維度，還要檢查整個控制行的關係：相鄰間距、對齊、剩餘操作空間，以及當啟用篩選控制項時所發生的變化。若證據支援或審查者明確回饋，則將共同的佈局修正及其視覺後果歸類為一個穩定的問題。區分這種歸類與程式碼層級的根因診斷。
區分脈絡與缺陷：範例資料、帳號身分、展開的導覽、全域公告與較新版本的元件都可能改變螢幕截圖。記錄它們，不要默默忽略其佈局效果。文字值可能被排除在文字比對之外，但其換行、溢位與對齊方式仍應接受審查。絕不拉伸螢幕截圖以隱藏差異，或憑空捏造一個全頁面的相似度分數。
製作可採取行動的發現
根據每個發現所支援的證據進行分類：
visual-defect：一個可重現的視覺故障，例如裁剪、重疊或已確認的實作違規。說明條件與期望的來源。baseline-mismatch：與所提供的參考資料存在明顯差異，其目前可接受的設計/版本可能需要確認。design-clarification：觀察到的條件，但缺乏足夠或互相矛盾的設計指導，無法決定是否接受。
將觀察信心度、建議優先級與後續追蹤狀態分開。不要因為差異明顯，就將一個高信心的螢幕截圖差異稱為已接受的缺陷。使用專案的優先級方案；標記為建議，並在決策未定時將優先級留空。不要憑空指派負責人、目標版本、已核准的偏差、實作完成或成功重新測試。
每個發現都需要一個穩定的 ID、頁面/狀態、簡潔的標題、實際結果、預期結果或明確的不確定性、證據基礎、建議的動作與重現步驟。附上目標比較證據與完整的當前狀態捕獲。包含相關的 Figma 參考。沒有視覺證據的發現是限制或問題，而非已確認的視覺缺陷。
將已檢查的項目與被封鎖/未審查的狀態分開記錄。在重新執行時，保留相同的问题 ID。僅當有新證據匹配時，才能關閉或將發現標記為已解決；保留先前的觀察結果，並說明變更的接受標準。
納入設計審查
預設為審查草稿，然後在產出開發人員交接文件前，納入設計師的決策。在接收回饋、修訂設計基準或準備正式報告時，請閱讀 review-workflow.md。如果對話中已提供明確的審查與核准，則足夠；無需再次要求相同的確認。
將保留、排除、接受、合併、延後與設計更新決策記錄在專案資料中，並附上其來源與範圍。設計參考的更正並非實作修正。審查者關於設計變更的回饋，本身並未授權編輯 Figma。保留草稿與決策歷史；開發人員交接文件僅包含保留的待辦事項，包括任何明確保留的釐清事項或現有模組的後續追蹤。不要將未指派的優先級、所有權、版本或重新測試欄位轉變為已確認的值。
交付報告
在撰寫報告時，請閱讀 report-format.md。保留已驗證的閱讀順序：範圍脈絡 → 簡潔的問題清單 → 選定問題的實際/預期視覺證據 → 涵蓋範圍與審查註記。讓視覺證據成為報告的核心內容，而非附加的附錄。避免為每個問題和每個通過的檢查重複顯示大張的螢幕截圖。
寫入 project-data.md 中描述的結構化執行資料，然後渲染：
python3 <skill-dir>/scripts/render_report.py <run-dir>/report.json
這會產出獨立的 report.html、issue-register.csv，以及在提供標準時產出的 acceptance-checklist.csv。在開發人員交接文件中，每個保留的項目都需要一個直接的測試 URL、導覽/脈絡、開發人員動作與可觀察的驗收標準。渲染器直接支援這些欄位；請勿透過修補產生的 HTML 來新增它們。渲染器需要 Python 3.9+ 且無需第三方套件。它會驗證輸入/證據，但不會推斷審查決策、存取外部系統或將報告發送給開發人員。
檢查渲染後的報告、其問題切換/篩選、圖片展開以及任何比較控制項。使用可用的本地預覽工具開啟結果，並遵循其瀏覽器規則。必要時，使用無衝突的本地預覽，並綁定至 loopback；除非被要求，否則不要發佈或寫入外部系統。在可行時，恢復暫時的瀏覽器視窗大小覆蓋與測試輸入，並回報任何仍處於變更狀態的內容。
以對話所使用的語言交付報告連結、簡潔的涵蓋範圍與關鍵結果。說明重要的限制。僅為了產出已要求的報告，無需要求核准。一個討論方法的請求，並非執行 UAT 執行的請求。