audit

audit 技能總覽

audit 會做什麼

audit 技能會針對頁面、功能或元件執行一套有結構的技術型 UI 審查，回傳的是帶分數的報告，而不是零散意見。它聚焦於可衡量的實作品質，包括無障礙、效能、主題一致性、響應式表現，以及前端反模式，並依 P0 到 P3 嚴重度排序問題，附上後續行動計畫。

誰適合安裝這個 audit 技能

這個 audit 技能特別適合前端團隊、design engineer、UX engineer，以及想建立可重複執行 UX Audit 流程的產品開發者，不必每次都手動重訂審查標準。當你需要的是能理解程式實作的審查，而不是偏主觀的設計評論時，它尤其有用。

真正要解決的工作需求

多數使用者要的其實不只是「給我一些 feedback」。他們真正想回答的是：這個頁面現在能不能上線？最先壞掉的是哪裡？哪些問題是無障礙阻斷，哪些只是後續整理？下一位 agent 或工程師應該先修什麼？audit 就是為了這種分流與優先排序的工作而設計。

為什麼這個技能和一般 prompt 不一樣

一般 prompt 可能會給出很廣泛的建議；audit 更適合拿來做決策，因為它會：

• 強制執行跨多個面向的診斷掃描
• 在五個維度上使用明確評分
• 把問題發現和問題修復分開處理
• 輸出含 P0-P3 嚴重度的優先順序
• 要求以實作證據為基礎，而不是以個人審美做評論

採用前的重要相依條件

導入 audit 最大的阻礙通常是脈絡不足：這個技能要求你先蒐集設計脈絡。它自己的指示就寫明要先呼叫 /frontend-design，如果目前還沒有任何設計脈絡，則要先跑 /teach-impeccable 再做 audit。若跳過這一步，輸出品質和一致性都會明顯下降。

如何使用 audit 技能

audit 的安裝脈絡

這個 repository 並沒有在 SKILL.md 內提供專用安裝指令，因此請沿用你平常安裝 GitHub 託管 Claude skills 的流程。例如：

npx skills add https://github.com/pbakaus/impeccable --skill audit

安裝後，請確認技能可用名稱是 audit，並注意它被標記為 user-invocable: true，代表你可以直接呼叫它。

先讀這個檔案

先從 .claude/skills/audit/SKILL.md 開始看。在這個 repository 裡，幾乎所有可用邏輯都集中在這個檔案：前置條件、適用範圍、審查維度、評分模型，以及輸出預期都在裡面。這裡沒有額外的 rules/、resources/ 或輔助腳本可依賴，所以能不能用好這個技能，很大程度取決於你是否仔細讀過 skill 檔案。

先理解前置流程

在使用 audit 技能之前，請照這個順序執行：

1. 先用 /frontend-design 蒐集設計與產品脈絡。
2. 如果這些脈絡還不存在，先執行 /teach-impeccable。
3. 之後再對目標頁面、功能或元件執行 audit。

這一步很重要，因為 audit 雖然偏技術導向，仍然需要脈絡才能準確判斷反模式、主題一致性與整體實作品質。

要傳入什麼輸入內容

這個技能提供的參數提示是：

[area (feature, page, component...)]

好的輸入應該是具體的 audit 目標，例如：

• checkout page
• mobile navigation drawer
• pricing cards component
• settings form validation flow

像 the app 或 the UI 這種太籠統的輸入，通常只會得到比較表層的輸出，因為 audit 的範圍會變得過大。

audit 技能會檢查哪些內容

這個 audit 流程會掃描五個維度：

• accessibility
• performance
• theming
• responsive design
• anti-patterns

接著它會為每個維度評 0-4 分，並整理成報告。如果你是為了做 UX Audit 而使用 audit，這套結構特別有幫助，因為它能把廣泛的 UX 品質問題轉成有實作依據的具體發現。

這個技能不會做什麼

audit 是拿來做診斷，不是拿來直接修復。它的設計目標很明確：記錄問題，而不是幫你把問題改掉。如果你想要的是一套可重複執行的品質審查流程，可以安裝它；但如果你期待同一步驟內就自動改程式、重構，或提出完整的視覺重設計方案，那它就不適合。

把模糊需求寫成高品質的 audit prompt

一個比較弱的 prompt：

• Run audit on my homepage

一個更強的 prompt：

• Run audit on the homepage hero and signup flow. Focus on keyboard access, semantic structure, responsive layout between 320px and 1440px, theme token consistency, and obvious performance risks. Return scores by dimension plus P0-P3 findings and a fix order.

為什麼這樣更好：

• 有明確界定範圍
• 有點出使用者路徑
• 有標示高風險區域
• 有要求技能使用原生輸出格式

audit 技能的最佳使用流程

一個實務上好用的 audit 流程是：

1. 先選定單一頁面或元件
2. 先提供產品與設計脈絡
3. 執行 audit
4. 檢視分數與嚴重度
5. 把 P0/P1 發現轉成實作任務
6. 修正後再重新執行 audit

這樣可以讓這個技能成為 QA、release review 或 design system 清理工作中的一道品質關卡。

好的 audit 輸出應該長什麼樣子

一份有用的 audit 結果應該包含：

• 各維度分數
• 具體的實作層級發現
• P0 到 P3 的嚴重度排序
• 可執行的下一步
• 能對應到程式或 UI 行為的證據

如果輸出大多只是泛泛而談的最佳實務，幾乎沒有優先順序，通常代表不是脈絡太弱，就是範圍設得太大。

給評估安裝者的 repository 閱讀路徑

如果你現在是在評估要不要安裝這個 audit 技能，最快的閱讀順序是：

1. SKILL.md 的 frontmatter，先看呼叫方式與用途
2. MANDATORY PREPARATION
3. Diagnostic Scan
4. 每個評分區塊
5. 最後的報告輸出結構

照這條路徑讀，很快就能判斷這個技能是否比一般 audit prompt 更符合你的工作流程。

能提升 audit 品質的實用技巧

• 一次只 audit 一個範圍
• 指定重要的裝置尺寸區間或版面狀態
• 說明 UI 是否使用 design system 或 theme tokens
• 指出關鍵流程，例如 sign-in、checkout 或 forms
• 要求只回報有證據支撐的發現
• 如果你只想做分流，請明確要求不要提供修法；若需要修復建議，改成下一步另外處理

audit 技能 FAQ

audit 適合拿來做 UX Audit 嗎？

適合，前提是你的 UX Audit 需要實作層級的證據。audit for UX Audit 在你特別關心無障礙缺口、響應式斷裂、主題不一致，以及會影響使用者體驗的前端品質問題時最強；但如果你要的是品牌策略、資訊架構，或質性可用性研究，它就相對沒那麼適合。

它和直接叫 AI 幫我 review 頁面有什麼不同？

一般的 review 很容易把個人口味、產品建議和對程式的猜測混在一起。audit 技能的範圍更窄，但在技術品質審查上也更可靠，因為它有既定維度、評分與嚴重度。這種結構也讓輸出更容易直接交接給工程團隊。

這個 audit 技能對新手友善嗎？

算中等。流程本身不複雜，但前置脈絡這一步很容易被忽略。新手也能使用，不過如果你對 WCAG 問題、semantic HTML、responsive behavior 和 design tokens 這些前端基本概念有一定理解，結果通常會更好。

什麼情況下不該用 audit？

當你需要以下內容時，不建議使用 audit：

• user research synthesis
• visual brand critique
• conversion-copy review
• 同一步驟內直接修程式
• 在沒有明確目標的情況下審查整個 app

這些情境通常更適合其他技能，或更聚焦的 prompt。

audit 一定要能讀到程式碼嗎？

如果 agent 能檢視實作內容，效果會最好，因為這個技能本來就是以 code-level audit 為定位。它仍然可以根據已渲染的 UI 描述進行推論，但信心程度與具體性都會比較低。

只靠 audit 就足夠做 release sign-off 嗎？

通常不夠。它是一層很強的技術審查，但不能取代 runtime testing、瀏覽器／裝置檢查、analytics review 或人工 QA。比較好的定位是把它當作一輪有結構的 audit，而不是唯一的品質關卡。

如何改善 audit 技能的使用效果

縮小範圍，讓 audit 結果更好

最常見的失敗模式就是範圍設得太大。要求 audit 整個產品，往往會讓優先順序被攤平，也會降低證據品質。更好的做法是：一次只 audit 一個流程、一個頁面，或一組元件。

在執行 audit 之前先補足脈絡

因為這個技能需要先跑 /frontend-design，有時還要 /teach-impeccable，所以想提升結果品質，最直接的方法就是把這些相依條件補齊。請提供：

• 目標使用者
• 頁面的主要任務
• 預期的 responsive breakpoints
• design system 規則
• 已知限制或刻意取捨

要求證據，不要只要意見

如果第一輪輸出感覺太空泛，下一個 prompt 可以收得更緊：

• Cite the element or pattern causing each issue
• Separate verified implementation issues from inferred risks
• Do not include subjective visual preferences

這樣能讓 audit 更貼近事實，也更值得信任。

改善嚴重度排序

不是所有發現都值得同等關注。若想讓 P0-P3 更有用，請先告訴技能在你的情境裡什麼算嚴重，例如：

• 法規或 WCAG 風險
• 阻礙任務完成的問題
• 只在 mobile 發生的破版
• 共用元件中的回歸問題
• 影響 checkout 或 auth flow 的問題

使用兩階段 audit 工作流

一個高品質的做法是：

1. 第一輪：先做廣泛的診斷掃描
2. 第二輪：深入追查分數最低的維度

例如，如果 accessibility 分數最差，就重新執行 audit，只聚焦在 keyboard flow、semantics、forms 與 contrast。這通常比一次做一個超大型審查，更能產出可行的修復規劃。

把 audit 和後續修復步驟串起來

因為 audit 本身不會修問題，所以很多時候要透過串接流程才能真正發揮價值：

• 執行 audit
• 萃取 P0/P1 問題
• 將每個問題分派給修復 prompt、工程師，或 code-editing agent
• 修改後重新執行 audit

這樣可以把 audit 技能從單純的報告工具，變成一個完整的品質循環。

強化 responsive 與 theming 檢查的輸入

如果你很在意 responsive 或 theming 品質，就要明確寫進 prompt。好的補充方式包括：

• Check behavior at 320px, 768px, and 1440px
• Check dark mode and token consistency
• Flag hard-coded colors, spacing drift, and component state inconsistencies

少了這種明確性，audit 可能仍會提到這些面向，但不會查得很深入。

讓 audit 輸出更適合交接

如果這份報告是要交給工程團隊，建議要求輸出包含：

• 問題標題
• 嚴重度
• 受影響範圍
• 為什麼重要
• 建議修正方向
• 修正後的驗證方式

這種格式更容易被採納，因為 audit 的輸出會更像可以直接放進 backlog 的內容，而不只是參考資訊。

第一輪 audit 很弱時的常見徵兆

如果你看到以下情況，建議直接重跑 audit：

• 只有高層次建議，沒有例子
• 沒有按維度評分
• 沒有 P0-P3 優先排序
• 內容讀起來比較像設計評論，而不是技術審查
• 沒有提到你指定的目標範圍

這通常是 prompt 或脈絡設定出了問題，不代表這個技能本身不好。

第一份報告之後，最好的迭代方式

拿到第一輪 audit 後，不要只是問 anything else?。改成以下這類要求會更有效：

• Expand only the P0 and P1 issues
• Re-audit the form flow for accessibility only
• Convert findings into an engineering checklist
• Challenge the performance score with stronger evidence
• Rerun audit after fixes and compare score changes

這種迭代方式，比重複丟同樣籠統的請求，更能把 audit 技能的價值榨出來。