ultrahand: review
以專家檢查員的方式審查 UI 設計。逐一檢查所有流程、互動介面與控制項，對照平台原則、尼爾森 10 項啟發式評估法與 WCAG 2.2 AA 標準，並確認設計在不同尺寸下是否依然合理。輸出結果為一份按嚴重性排序的發現清單。每一項發現都會指出元件名稱、違反的原則及其來源，並提供具體的修正方法。
所有的檢查項目都列在 references/checklist.md 中，每個檢查項目都會引用 references/sources.md。若需深入了解平台規則，請參閱設計技能的專屬原則：行動裝置、平板 與 桌面。對於有主題的專案，請使用 theme-review 技能來檢查設計是否符合主題；代碼使用、元件重用以及跨畫面的一致性由該技能負責，而非本技能。
1. 取得設計並瞭解其可顯示的內容
使用使用者能提供的最豐富證據。說明你擁有哪一種證據，因為這會限制你能夠確認的範圍。
- ultrahand 畫布成品（一個 claude.ai 的成品連結）：讀取其 HTML。它包含標記、標籤、顏色以及每個畫面與狀態。如果瀏覽器工具可用，請開啟該成品。透過
window.ultrahandCanvas（參閱shared/canvas/中的畫布 README）設定每個視圖：usePreset(id)、setSize(w, h)、setScheme('dark')、setTextScale(2)、setState('error')、navigate(id)。開啟 顯示觸控目標 並讀取其結果（#uh-targets-result），該結果會計算低於平台最小尺寸的觸控目標數量。在開啟浮動面板或選單後呼叫refresh()，以便計數包含這些項目。畫布 README 列出了工具列的元素 ID。原型中的暫存功能（沒有真實網路、沒有螢幕鍵盤）應歸類為 未檢查，而非列在發現中。硬體鍵盤是真實的：用它來驅動每個流程。 - 本地建置畫布（來自
build.mjs的index.html）或任何你可以開啟的頁面：將其視為畫布成品，並搭配輸入驅動器使用（步驟 4）。 - 程式碼（HTML、SwiftUI、Compose、Flutter 等）：你可以檢查標籤、角色、焦點順序、顏色與斷點，但無法檢查外觀，除非你能執行它。
- 螢幕截圖或模型圖： 你可以判斷佈局、層級、用詞以及近似的對比度與尺寸。但無法確認標籤、焦點順序或行為；請將這些發現標記為 可能 或列在 未檢查 之下。
為每個發現標記證據：已確認（在程式碼中看到或在畫布上測量到）或 可能（從圖片推斷）。切勿將關於隱藏行為的猜測當作事實呈現。
2. 建立脈絡
在判斷任何項目之前，先記錄以下資訊；一項發現只有在對照這些脈絡時才有意義。
- 平台： iOS、iPadOS、Android、macOS、Windows 或網頁。從畫布（
size.platform）、程式碼或視覺風格中讀取。如果不明確，詢問一次。 - 當前尺寸： 寬度 × 高度，以及寬度尺寸類別：緊湊 < 600、中等 600–839、展開 840–1199、大 1200–1599、特大 1600+。高度緊湊 < 480、中等 480–899、展開 900+。注意方向與任何分割狀態。
- 輸入方式： 觸控、指標、鍵盤或混合。平板電腦或觸控筆記型電腦可能同時具備這三種。
- 使用者與主要任務： 每個畫面給誰使用，以及該畫面的主要用途。如果你無法推斷，請詢問；沒有任務的審查只會變成一份意見清單。
- 產品或工具： 為最終使用者設計的產品，或是為擁有者（畫布本身、編輯器、檢視器）建置的工具。工具是在任何尺寸的瀏覽器視窗中使用的桌面應用程式：請使用桌面規則進行審查，並通過第 8 階段。其外框（chrome）會套用第 8 階段列出的第 7 階段檢查（視窗大小、瀏覽器縮放、其自身主題），而不是設計的預設值，其構成審查則與任何畫面相同。
根據 視窗尺寸類別與輸入方式（而非裝置名稱）來選擇平台規則：緊湊觸控 → 行動裝置原則；中等與展開觸控，或任何分割狀態 → 平板；指標與鍵盤視窗 → 桌面。響應式設計會涵蓋其尺寸所及的所有規則集。
3. 盤點設計
列出每個畫面與狀態、畫面之間的每個流程、每個畫面的區塊（工具列及其群組、窗格、窗格標題、表單群組、卡片、列表、欄位），以及每個區塊中的每個互動控制項（按鈕、連結、欄位、切換開關、分頁、選單、手勢、拖曳目標）。這份盤點清單就是審查的範圍：你沒有列出的區塊或控制項，就是你沒有檢查到的部分。
從三個層級進行審查： 整個畫面、每個區塊，以及每個元件。一個所有控制項都通過檢查的畫面，仍然可能顯得雜亂、無序且令人困惑；這本身就是一個發現，而不是潤飾的細節。
4. 按階段檢查
依照 references/checklist.md 中的階段順序進行。將設計檢查兩次：一次是熟悉它，一次是找出問題。
使用真實輸入，在多種尺寸下操作每個控制項。 讀取標記，或呼叫 el.click()、dispatchEvent 或 setter，會跳過命中測試、焦點、預設動作與捲動鏈結，因此一個被遮擋的按鈕或一個卡住的滾輪仍然看起來正常。請像真人一樣使用頁面：使用來自 node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" 的可信賴滑鼠、滾輪、鍵盤與觸控事件（其 README 包含步驟與範例），或使用瀏覽器工具的真實點擊與按鍵。腳本僅用於設定視圖以及在之後讀取狀態。
- 在三個或更多尺寸上進行：最大的尺寸、中間尺寸以及支援的最小尺寸（對於設計，使用其預設值；對於工具，使用瀏覽器視窗，例如 1440×900、1024×700 與 640×480）。
- 在每個尺寸下，列出控制項（
controls），然後按照其類型應有的方式使用每一個：點擊或輕觸、輸入文字、拖曳並按 Esc 取消、按右鍵、使用鍵盤開啟與關閉，以及在每個可滾動區域上滾動或滑動，直到超過其邊界。 - 少數原生控制項無法在無頭模式下使用可信輸入驅動：例如選擇（select）的彈出選單、檔案選擇器，以及顏色與日期選擇器。使用驅動器的
choose步驟來選擇選項，並將其他項目列在 未檢查 之下。 - 讀取每個結果：一個被標記為
covered、不在視野中且無法到達、或在某個尺寸下遺失的控制項；一個scrolled顯示滾輪被卡住；焦點丟失到body；頁面錯誤。每個問題都是該尺寸下的一個發現。
- 任務演練： 對於每個流程，在每個步驟詢問四個認知演練問題。
- 構成： 先審查每個畫面的整體，再審查每個區塊，對照構成規則（shared/composition/principles.md）。在最大和最小尺寸下執行其審核，並先閱讀模糊的螢幕截圖，然後再查看任何單一控制項。審查修訂版本時，也要與先前的版本進行比較：這一輪新增了什麼？畫面是否因此變得更雜亂？
- 逐一控制項： 清單中的每個控制項都對照控制項檢查。
- 啟發式評估： 每個畫面對照尼爾森 10 項原則。
- 無障礙： WCAG 2.2 AA。計算對比度；不要憑目測。
- 平台： 步驟 2 中該平台與尺寸類別的規則。
- 縮放與變體： 每個預設值、分割寬度、320 寬度重新流動、200% 文字、深色模式、每個資料狀態，以及在觸控裝置上的兩種方向與鍵盤彈出狀態（桌面視窗不會旋轉：請檢查最小、最大與窄視窗）。
- 工具： 對於為擁有者建置的工具，工作內容在任何視窗尺寸下都應保持可見、舞台可平移超過其邊界、縮放有限制，並且捷徑與拖曳行為正常。
發現問題時立即記錄，並註明在哪裡發現（畫面 › 元件，以及尺寸、配色方案與狀態）。一個在多處出現的問題，就是一個有多個位置的發現。
5. 評定嚴重性
使用尼爾森 0–4 級評分。考量有多少使用者會遇到此問題、對他們的影響有多大，以及他們在了解問題後是否仍會持續受影響。請參閱檢查清單中的嚴重性指南。
| 評分 | 意義 |
|---|---|
| 4 災難 | 導致使用者無法完成任務，或遺失資料。發行前必須修正。 |
| 3 重大 | 減慢或混淆許多使用者，或在主要流程上未通過 WCAG AA 標準。應儘快修正。 |
| 2 輕微 | 減慢部分使用者，或存在明顯的解決方法。 |
| 1 外觀 | 潤飾細節。有時間再修正。 |
不要報告 0 級。WCAG AA 失敗的項目永遠不會低於 2 級。
6. 報告
以一段總結開頭：平台、審查的尺寸、你擁有的證據、第一印象（模糊畫面顯示的內容，以及畫面看起來是有組織還是雜亂）、按嚴重性分級的數量統計，以及最嚴重的問題。將雜亂無章的主要介面與錯誤同等看待：它會減慢每一次使用，而不僅僅是某一條路徑。然後列出發現，按嚴重性從高到低排列，在同一嚴重性內按流程順序排列，使用檢查清單中的範本：
- ID 與嚴重性，例如
R3 · 3 重大 - 元件： 畫面 › 區塊 › 元件（或畫面 › 區塊，或整個畫面，適用於構成發現），以及問題出現時的尺寸、配色方案或狀態
- 證據： 已確認 或 可能
- 問題： 對使用者來說出了什麼問題，用一兩句話說明
- 原則： 它違反的規則，及其來源鍵（
WCAG 1.4.3、NNG-H4、tablet:AND-T2） - 修正： 具體的變更與數值（例如「將標籤顏色提升至 #595959 以達到 7.0:1 的對比度」，而不是「改善對比度」）
結尾處說明哪些部分運作良好（簡短說明）、你無法檢查哪些項目及其原因（螢幕閱讀器輸出、真實裝置、動態效果），並備註一位審查員可能會遺漏其他審查員能發現的問題，因此值得進行第二位審查員或可用性測試。
如果報告要提交給其他人，請主動提出將其發布為成品。並提議使用對應的 ultrahand 設計技能來套用修正。