better-interface

將介面視為單一系統進行審查

優秀的介面設計並非將六份獨立的審查報告拼湊在一起。請審查整體體驗，讓各個 better-* Skill 負責其專屬領域的規範，最後再將所有證據整合為一份排序後的最終判決。

本 Skill 僅負責「統籌協調（orchestration）」。無障礙規範歸 better-accessibility；版面結構歸 better-layout；文案歸 better-writing；字型排版歸 better-typography；色彩歸 better-colors；視覺精細度與動效歸 better-ui。切勿在此重複或覆蓋各領域 Skill 的規範。

核心原則

1. 先確認審查範圍與模式

根據使用者需求與當前工作區，推導出欲審查的畫面、流程、功能或程式庫範圍。在輸出結果中明確說明確認後的範圍。若未指定模式，預設使用 full 模式。

模式	涵蓋範圍	發現事項上限
quick	主要使用者路徑與最高流量的狀態；僅回報 HIGH 與 MEDIUM 層級的問題	5
full	要求範圍內跨全數六個領域 Skill 的完整檢視，若存在空白（empty）、載入中（loading）、錯誤（error）及窄螢幕（narrow-width）狀態亦需包含	15

若要求的範圍過大而無法進行具可信度的審查，請將範圍縮小至流量最高的完整流程，並明確指出邊界。切勿暗示未經審查的介面已完成審查。

2. 評斷前的偵察

確認專案採用的框架、樣式系統、元件庫、設計 Token、支援的 Viewport，以及可用的預覽或測試指令。請遵循專案既有的 Tailwind、純 CSS、CSS-in-JS、Token 與元件規範。

3. 以領域 Skill 作為唯一真理來源

在開始審查前，請先確認下方六個負責的 Skill 皆可用。載入並套用所有可用的 Skill。在 quick 模式下，需檢視全部六個領域，但僅在主要流程有確切證據之處進行深入分析。在 full 模式下，請先完成各個可用領域的獨立審查，再進行整合。

請依以下順序進行審查，避免基礎性缺陷被視覺修飾所遮蔽：

1. better-accessibility
2. better-layout
3. better-writing
4. better-typography
5. better-colors
6. better-ui

最終的回覆由本 Skill 主導。當子領域 Skill 透過 better-interface 被載入時，請套用其原則與參考資料，但忽略其獨立的 Review Output Format。改為使用本文檔中定義的整合格式、通用嚴重程度等級與發現事項上限。

若某個主導 Skill 不可用，請將該領域標記為 Not reviewed，註明缺失的 Skill 名稱，並繼續審查其餘領域。切勿憑記憶重造其規範、以相鄰的 Skill 替代，或宣稱已達成整體涵蓋。

當兩個 Skill 似乎涵蓋同一個問題時，請將其歸類給持有底層規範的 Skill，並在 Why 欄位中提及次要影響。該問題僅需回報一次。

4. 必須提供證據

每項發現都必須引用 path/to/file:line 並展示目前的實作方式。若審查標的物沒有原始碼檔案，請引用確切的畫面與元件名稱。當執行期行為（runtime behavior）決定最終結果時，切勿單憑視覺外觀回報程式碼層級的問題，或單憑原始碼回報視覺上的問題。

5. 依使用者影響程度排序

使用統一的嚴重程度分級：

• HIGH：阻礙任務進行、誤導使用者、隱藏內容或控制項、造成資料遺失風險，或引發重複出現的系統性失效。
• MEDIUM：顯著損害理解度、操作效率、適應性或一致性。
• LOW：影響有限的局部視覺微調。僅包含於 full 模式中。

在同一嚴重程度內，依涵蓋範圍與槓桿效應（reach and leverage）進行排序。修正設計 Token 或共用元件的優先級，高於修正單一葉節點元件（leaf component）中的相同症狀。

6. 整合系統性發現

單一根本原因即算作一項發現。請將所有已確認的位置列在同一列中，而非為每次出現都產生新的一列。切勿為了湊滿發現事項上限而硬塞內容；簡短的審查報告或無任何發現均為合法且正常的結果。

7. 展現節制與克制

記錄經過考量但最終主動排除的候選項目。當權責 Skill 允許當前實作、證據不足、專案慣例屬故意為之，或是建議的修改會增加複雜度卻無法帶來使用者效益時，該候選項目即應予以排除。

8. 驗證所有可驗證的項目

執行專案中可用且安全、相關的檢查。當執行期行為或視覺判斷至關重要時，請檢視渲染後的介面。回報確切的指令或操作流程以及觀察到的結果。若某項檢查無法執行，請標記為 Not verified 並說明剩餘疑慮；切勿將驗證缺口直接轉化為問題發現。

9. 預設僅進行審查而不變更程式碼

請將審查請求視為唯讀（read-only）。除非使用者明確要求實作修改建議，否則請勿編輯原始碼。當收到實作要求時，請將整合後的報告作為變更範圍，並在實作後重新執行相關的驗證。

常見錯誤

錯誤	修正方式
六份相互割裂的領域報告	整合為單一依優先順序排列的發現事項表格
同一問題被多個 Skill 重複回報	歸類給持有底層規範的 Skill
發現事項未標註確切位置	引用 path/to/file:line 並附上當前實作
僅憑原始碼推論視覺問題	檢視渲染狀態或標記為未驗證（not verified）
無限制地回報低影響度的修飾細節	遵循模式的數量上限；在 quick 模式中忽略 LOW 事項
隱瞞未涵蓋的審查死角	清楚標示實際審查了哪些領域與狀態
遺失的主導 Skill 被默認為已涵蓋	將該領域標記為 Not reviewed 並註明不可用的 Skill 名稱
未包含排除的候選項目	包含要求的「經過考量但予以排除」表格
審查過程中默默編輯了程式碼	保持唯讀，除非使用者明確要求實作
存在待處理的待修正事項卻給予「通過」	使用 Needs changes 或 Block

審查輸出格式

務必使用以下章節。

Scope and Coverage

說明使用的模式、確切範圍、技術棧與樣式規範，以及任何審查邊界。接著展示涵蓋度：

Domain	Evidence inspected	Result
Accessibility	檔案、元件、狀態或檢查項目	發現事項數量或 Clear

需包含全部六個領域。Clear 表示已檢視且無需採取的發現事項；Not reviewed 則必須說明原因。

Findings

使用單一表格，依嚴重程度排序，其次依影響範圍與槓桿效應排序：

#	Severity	Domain	Location	Before	After	Why
1	HIGH	Accessibility	src/Dialog.tsx:42	<button><XIcon /></button>	新增 aria-label="Close" 並在無障礙樹中隱藏該圖示	僅有圖示的控制項缺少可存取的名稱（accessible name）

每列代表一個根本原因。Domain 欄位的值為去除 better- 前綴的主導 Skill 名稱。請遵守該模式的發現事項上限。若無任何發現事項，請省略表格並註明「No actionable interface findings.」。

Considered but Rejected

在 quick 模式下包含 1–3 個候選項目，在 full 模式下包含 2–5 個：

Location	Candidate	Rejected because
src/Card.tsx:28	加深陰影	現有深度符合共用的 surface Token；僅修改單一卡片會降低一致性

這些必須是審查過程中實際檢視過的真實候選項目，而非虛構的填充內容。若審查範圍內可疑的候選項目確實較少，請列出實際存在的項目並如實說明。

Verification

列出每項檢查或操作流程、確切的指令或步驟，以及觀察到的結果。請將通過的檢查與標記為 Not verified 的檢查分開列出。

Verdict

結尾必須精確包含以下其中之一：

• Block — 仍存在一項或多項 HIGH 級別的發現事項。
• Needs changes — 僅剩 MEDIUM 或 LOW 級別的發現事項。
• Approve — 無需採取的發現事項，且宣稱的涵蓋範圍均已完成驗證。