polish

polish skill 概覽

polish 的用途

polish skill 是一套用於 UI 最後一輪檢視的工作流程，專門抓出那些會讓成品看起來「快好了」，卻還不到真正可上線水準的細節問題。它聚焦在對齊、間距、一致性、token 使用、視覺節奏、互動細節，以及一般泛用 prompt 常會漏掉的小幅實作偏移。

polish skill 適合哪些人

如果你已經有可運作的介面，想在送審、上線或交接前再把品質往上拉一個層級，就適合使用這個 polish skill。它特別適合設計師、前端工程師，以及使用 AI 協作打造產品的人，尤其是正在處理畫面、流程或元件，明明覺得「差不多了」，卻總覺得哪裡不太對的情況。當你手上有 design system 或既有產品規範可作為收尾依據時，效果會更好。

安裝前要先知道的重點

採用 polish 前最重要的一點是：它不是拿來從零發想設計方向的。它預設你已經有東西可以檢查、可以優化。另外，它也依賴 $impeccable：這個 skill 明確要求先執行那個較完整的 skill，用來蒐集脈絡、建立原則，並檢查反模式。如果目前還沒有任何設計脈絡，流程會要求你先執行 $impeccable teach，再來使用 polish。

為什麼不直接用一般 prompt 就好

單純丟一句「把這個做得更好看」的 prompt，通常只會得到模糊建議，或是偏隨機的重設計。polish 真正有價值的地方，在於它會針對現有系統做有條理的檢查：先辨識設計慣例，再找出 token、元件、pattern 的偏移，最後在不必要變動產品的前提下做精準修正。對於上線前整理，以及 UI 設計一致性的收尾工作來說，這種方式實際得多。

如何使用 polish skill

安裝脈絡與第一批該看的檔案

請從 pbakaus/impeccable repository 安裝這個 skill，並先閱讀 SKILL.md，因為真正的操作規則都寫在那個檔案裡。最關鍵的一條指示是強制性的：必須先呼叫 $impeccable。因此，若你正在評估 polish install，要知道這個 skill 最適合放在更完整的 impeccable workflow 裡使用，而不是拿來當成一次性的獨立 prompt。

polish 需要哪些輸入，效果才會好

要讓 polish skill 發揮得好，最好提供：

• 目標畫面、流程或元件
• 目前的實作內容或 screenshots
• design system、component library，或 token 慣例（若有）
• 品質目標：MVP 或 flagship
• 已知痛點，例如「spacing 看起來不平均」或「buttons 不夠一致」

比較弱的請求會像這樣：Polish this settings page.
比較強的 polish usage prompt 則會像這樣：Use polish on the settings page. Quality bar: flagship. Match our existing design system. Check spacing scale, token usage, component consistency, alignment, and interaction details. Avoid redesigning layout unless needed.

一套實用的 polish workflow

一個可靠的流程如下：

1. 先執行 $impeccable，蒐集脈絡與設計原則。
2. 辨識 design system；如果沒有正式系統，就從相鄰的產品區域推導出慣例。
3. 檢查目前 UI 是否有偏移：硬編碼數值、不一致的間距、重複的自訂 pattern、不平均的層級，或視覺雜訊。
4. 先做小幅、把握度高的調整。
5. 再把整個畫面重新檢查一次，避免局部修正反而造成新的不一致。

這才是最佳的 polish guide 思路：不要一上來就直接改。repository 強調的是，在動細節之前，先理解在這個產品裡，「polished」到底代表什麼。

polish for UI Design 的 prompt 建議

在使用 polish for UI Design 時，建議要求它輸出結構化結果。實用的 prompt 補充包括：

• List issues by severity before proposing changes.
• Prefer system alignment over novelty.
• Call out where tokens or shared components should replace custom styling.
• Separate must-fix launch blockers from nice-to-have refinements.

這樣能提升輸出品質，因為這個 skill 最強的是系統化檢視，而不是大範圍的創意探索。如果你要的是探索方向，應該先用偏 concepting 或 redesign 的 skill，最後再用 polish 做收尾。

polish skill 常見問題

polish 適合新手嗎？

適合，前提是你手上已經有一個具體可優化的 UI。對新手來說，polish skill 會比泛用 prompt 提供更好的檢查清單，特別是在 spacing、一致性，以及 design-system 對齊這幾個面向。不過，如果你還不清楚自己產品的設計慣例，它對新手就沒那麼友善，因為這套 workflow 預設脈絡已經存在，或必須透過 $impeccable 教進去。

什麼情況下不該用 polish？

如果真正的問題是策略、資訊架構，或 UX 方向本身缺失，就不該使用 polish。它也不適合拿來做白紙起稿的設計工作。若畫面從根本上就有問題，polish 不能取代完整 redesign；它是拿來做收尾與品質提升的，不是用來發明產品核心方向的。

polish 和 code review 有什麼不同？

code review 可能會抓出可維護性或正確性問題；polish skill 更聚焦在最終交付的使用體驗：視覺一致性、系統偏移、微觀細節品質，以及整個介面是否有整體感。兩者確實可能有重疊，但 polish usage 的核心仍是 UI 品質，而不是工程架構。

polish 一定要有 design system 嗎？

不一定，但有的話會更好用。就算沒有正式系統，這個 skill 仍會要求你朝著產品中看得見的既有慣例去 polish。也就是說，就算產品做法還很土法煉鋼，它依然能幫上忙；只是當你有可重用的 tokens、components 或既定 patterns 可對齊時，輸出通常會更強。

如何提升 polish skill 的效果

給 polish 更明確的目標

想讓 polish 結果快速變好，最有效的方法就是把目標講清楚：是 MVP 還是 flagship、要檢查哪個介面，以及目標是提高一致性、做出更高級的質感、達到上線水準，還是符合 design-system 規範。沒有這些前提時，skill 可能會過度修正小問題，或把精力花在其實沒那麼重要的地方。

提供更強的證據，不只給主觀意見

更好的輸入，才會有更好的 polish 結果。請提供 screenshots、component code、相鄰畫面、token 檔案，或能代表「我們想要這種水準」的範例。這能幫助 skill 分辨哪些是真的不一致，哪些其實是刻意的變化。若你只說「讓它更好看一點」，它就只能自己猜標準。

留意常見失敗模式

主要的失敗模式包括：

• 過度 redesign，而不是精修
• 修了局部細節，卻破壞整頁節奏
• 新增更多自訂樣式，而不是回頭對齊共用元件
• 把每一個不一致都當成 bug，忽略有些差異其實是刻意設計

你可以明確要求 skill 保留產品既有的 established patterns，除非某個偏離真的已經明顯傷害品質。

在第一輪之後再迭代一次

實務上要把 polish skill 用好，最佳方式通常是先跑一輪，再依據結果做第二輪。第一版輸出之後，你可以直接補充具體回饋，例如 too aggressive、keep layout unchanged、focus only on spacing and typography，或 prioritize design-token cleanup。這樣就能把原本偏廣泛的精修，收斂到你團隊真正期待的標準。