Communitygithub.com

jamesonedge/資深設計審查

以證據為基礎的資深設計審查,壓力測試 UI 設計提案或現有畫面,產出可實作的精煉規格與「刪除/新增/修改/保留」清單。適用於審查、批評或重新思考任何畫面、流程或設計提案。

資深設計審查 是什麼?

這是一個專為 AI 代理(如 Claude Code、Cursor、Codex)設計的資深設計審查技能。其核心目標是將模糊的「讓它更好」轉化為可檢證的設計決策。技能以結構化審查方式,對 UI 畫面或流程進行壓力測試,產出包含明確引用(檔案路徑、設計 Token、參考模式)的詳細評論,以及工程師可直接實作的精煉規格與「刪除/新增/修改/保留」清單。它特別適用於審查現有畫面、評估計畫書、決定實作前應刪除或保留的內容,以及修正行動流程。實作時,它會先收集設計 Token、既有元件、平台限制等輸入,接著由一個「品質透鏡」角色的審查者獨立進行結構、資訊架構、互動語義、視覺動畫、無障礙與國際化等多面向分析。重要的規則是:每個主張都必須提供具體參考,禁止空泛的「改善視覺層次」說詞,禁止捏造未經計算的數據,且必須涵蓋空狀態、載入、錯誤、離線等多種狀態。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/jamesonedge/design-agent-kit/tree/main/skills/senior-design-review

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

資深設計審查 是做什麼的?

將模糊的「讓它更好」轉化為可檢證的設計決策。產出內容是一份結構化的評論,明確引用真實檔案、Token 與參考模式,緊接著是工程師可以實作的規格。

使用時機

當使用者要求下列事項時,使用此技能:

  • 審查、批評或「壓力測試」現有畫面、流程或元件;
  • 評估他人(例如初階設計師或其他代理)撰寫的提案;
  • 在實作前決定要刪除、新增、修改或保留什麼;
  • 根據截圖修正行動流程。

不應使用時機

  • 小型、局部修正,例如「增加這張卡片的內距」或「將這個標籤改為『儲存』」。請直接修改;完整的審查只是噪音。
  • 建立互動式原型。請使用互動式 Mockup 工作流程;此技能可為其提供輸入。
  • 非 UI 的程式碼審查、效能調校或後端設計。
  • 品牌或行銷策略,沒有具體介面。

輸入

收集儲存庫或使用者可以安全提供的內容。缺少的輸入會列為待釐清問題,絕不臆造。

  1. 設計 Token(顏色、字體、間距、圓角、動畫)——檔案路徑。
  2. 目標應相似的既存元件——標準件。
  3. 先前已核准的類似工作範例(可選,但有幫助)。
  4. 目標實作與/或截圖。
  5. 已知的平台限制(導覽模型、作業系統慣例、最低支援目標)。
  6. 使用者的抱怨,盡可能直接引用原文。

填寫的情境表單位於 templates/context.md。

工作流程

1. 草擬明確的初始提案

在進行任何批評之前,使用 templates/proposal.md 將提案寫下來:問題、引用的痛點、設計原則、資訊架構草稿、行動與待釐清問題。如果使用者已提供提案,則直接以其作為輸入,不做修改。

2. 以全新視角執行審查

審查者按以下順序閱讀:Token、標準元件、先前範例、目標實作/截圖、平台限制,最後才看提案。先閱讀證據可以避免被提案的框架過度影響。

  • 如果你的執行環境可以啟動一個真正獨立的上下文(子代理或沒有共享歷史的新工作階段),請使用它並明確說明。
  • 如果不行,請自行執行一次獨立的掃描,並誠實標記:「單代理獨立掃描——並非真正的同儕審查。」

審查者的角色是「品質透鏡」(一位要求嚴格的資深產品設計師)。切勿代表此角色編造工作經歷、證照或年資。

3. 撰寫審查內容

使用 templates/review.md。章節如下:

  • TL;DR ——三到五行:結論與最重要的變更。
  • A. 結構性評論 ——這是否是正確的畫面/流程?
  • B. 資訊架構與層級
  • C. 操作語義 ——主要、次要、破壞性、復原、命名。
  • D. 機制與手勢 ——點按、滑動、拖曳、鍵盤、可發現性。
  • E. 視覺與動畫 ——Token、節奏、密度、過場。
  • F. 無障礙與國際化
  • G. 未解決的問題 ——目標是五個,但只包含有意義的問題。
  • H. 精煉規格 加上 刪除/新增/修改/保留清單。

每個透鏡的詳細指南在 references/review-lenses.md。無障礙與 i18n 檢查清單在 references/accessibility-i18n.md。

讓審查值得一讀的規則

  • 壓力測試,而非橡皮圖章。 每個主張都需要一個具體的參考:檔案路徑、Token 名稱、元件名稱、截圖區域或具名的參考模式(例如「iOS Mail 滑動封存」)。
  • 不要空話。 「改善視覺層次」不是一個發現。「『到期日』使用了 text.secondary 且大小與標題相同,因此截止日期一眼看去不明顯」才是。
  • 不需要強制刪除。 如果目前的結構是對的,就明確說明並記錄一個有根據的保留。為改變而改變是一種缺陷。
  • 不要虛構數據。 除非你實際計算或測量過,並展示如何計算,否則不要陳述對比度、WCAG 通過/失敗等級或效能數據。否則請寫「未測量——請使用對比度工具驗證」。
  • 涵蓋各種狀態。 空狀態、載入中、錯誤、離線、長內容與極短內容。
  • 非顏色信號。 狀態絕不能只依賴顏色。
  • 鍵盤與螢幕閱讀器 每個動作的路徑,包括自訂手勢。
  • 文字擴展(對許多語言來說,允許字串大約增長 30–40%)以及相關的從右到左佈局。
  • 減少動畫 每個動畫的替代方案。

可選:與先前工作比較

如果存在先前已核准的範例,請在 E 或 H 下方加入一段簡短的「與先前工作的一致性」備註。這是有幫助的,非強制。

輸出

  • proposal.md(如果你有草擬的話)
  • review.md,包含 TL;DR、A–H 與清單
  • 給使用者的一份簡短摘要:結論、前三項變更,以及阻礙實作的待釐清問題

驗收檢查

請參閱 references/review-lenses.md#acceptance-checks。如果清單中的任何一行缺少理由與參考,或將未測量的數字陳述為事實,則審查視為不合格。

授權聲明

以下聲明隨此獨立技能及其支援檔案一同傳遞。

MIT 許可證

版權所有 (c) 2026 jamesonedge

特此無償授予任何取得本軟體及相關文件檔案(「軟體」)的個人,不受限制地處理本軟體的權利,包括但不限於使用、複製、修改、合併、發布、分發、再授權及/或銷售本軟體的副本,並允許接收本軟體的人這樣做,但須符合以下條件:

上述版權聲明及本許可聲明應包含在本軟體的所有副本或重要部分中。

本軟體係按「現狀」提供,不附帶任何明示或默示的擔保,包括但不限於適銷性、特定用途適用性及非侵權的擔保。在任何情況下,作者或版權持有人均不對任何索賠、損害或其他責任負責,無論是因合約、侵權行為或其他原因而產生,且與軟體的使用或其他交易有關或由之引起。

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

相關技能