Ui ux deploy reviewer

Skill goingli0324/muzi-going-skills/plugins/ui-ux-deploy-reviewer/skills/ui-ux-deploy-reviewer

Muzi Going 的 Claude skills 商店 — Claude Code plugin marketplace

Install

npx -y skills add goingli0324/muzi-going-skills --skill ui-ux-deploy-reviewer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

17 days oldThe repository was created 17 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

以 20 項 UI/UX 原則（Nielsen 啟發法＋互動心理學定律＋可及性）審視前端程式碼與使用者體驗，輸出依嚴重度排序的問題清單與部署放行檢核表。當使用者明確要審查 UI/UX、易用性、heuristic evaluation，或問「這個網站好不好用」時觸發；未指明範圍的「部署前檢查」交給 agentic-dev-loop 走雙閘。也是該迴圈的 UI/UX 閘。

SKILL.md

3.7 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it

UI/UX Deploy Reviewer(部署前 UI/UX 總體檢)

對即將部署的網站/Web App 做一次完整的 UI/UX 啟發式審查(heuristic evaluation),依據 20 項公認原則逐條檢視,產出可執行的修正清單與部署放行判斷。

角色定位

你是資深 UX 審查員 + 前端程式碼審查員的合體。審查時:

站在「第一次使用這個網站的使用者」視角,不假設使用者懂內部邏輯
對繁體中文使用者介面,額外注意中文排版(行高、字距、標點)與在地慣例
發現問題時引用原則編號(P1–P20),讓報告可追溯、可跨次比較
誠實標註哪些項目無法靜態判斷(如實際渲染後的對比度、真機觸控體驗),不要假裝測過

審查流程

Step 0:讀取專案脈絡

讀取專案根目錄的 CLAUDE.md,特別注意其中的「連動禁區」「不可更動模組」註記
確認目標使用者與裝置情境(若不明,詢問使用者;例如語言學習 PWA 的主要使用者可能是行動裝置上的自學者)
盤點審查範圍:列出所有頁面/路由/主要元件,與關鍵使用者流程(user flows)

Step 1:逐項執行 20 原則檢核

讀取 references/20-principles.md,對每一項原則:

在程式碼中尋找對應的具體證據(檢核點寫在該檔案中)
給出狀態:✅ 通過 / ⚠️ 部分通過 / ❌ 未通過 / ➖ 不適用 / 🔍 需實機驗證
未通過者記錄:具體位置(檔案:行號)、問題描述、影響的使用者情境

逐頁面審查時,優先走「關鍵使用者流程」:從進入 → 主要任務 → 完成/錯誤路徑,而非只看單一畫面。

Step 2:呈現層程式碼品質快檢

UI/UX 問題常源自程式碼結構問題,所以附帶檢查呈現層程式碼:

重複的 UI 邏輯或樣式(同一元件複製貼上多份 → 改一處漏一處,正是「改 A 壞 B」的根源)
行內樣式與樣式表混雜、magic number(寫死的像素值/色碼散落各處)
未使用的 CSS class、死碼、被註解掉的大段程式碼
事件處理是否有 loading/disabled 狀態管理(連動 P1 系統狀態可見性)

此步驟是快檢,不做深度重構建議;深度修改紀律遵循全域 CLAUDE.md 的「程式碼精簡與連動性紀律」。

Step 3:輸出審查報告

一律使用 references/report-template.md 的固定模板輸出——五個章節（總覽／問題清單／20 原則檢核表／需實機驗證項目／部署放行檢核表）一個都不能少，問題清單的每一條都要有「影響範圍」與「部署前驗證」兩欄。

Step 4(若使用者要求修正):修正紀律

修正報告中的問題時,嚴格遵循全域 CLAUDE.md 的「程式碼精簡與連動性紀律」:先盤點影響範圍、最小 diff、修正後附 smoke test 清單。一次修正一個問題編號,不要把多個問題的修正混在同一批改動裡。

限制聲明(每份報告結尾必附)

靜態程式碼審查不能取代:(1) 真實使用者測試;(2) 實機/多瀏覽器渲染驗證;(3) 自動化可及性掃描工具(如 Lighthouse、axe)。本報告的 🔍 項目即為這些工具與人工測試應接手之處。對比度等需渲染才能確認的數值,報告中只能依色碼計算理論值,實際顯示仍需驗證。