04｜前端設計總監（impeccable）
🎯 一句話：23 個設計指令 + 一套可執行的反樣板偵測器，把 Agent 從「會寫 CSS」變成有主見的設計總監。
- Repo：https://github.com/pbakaus/impeccable（Apache 2.0，作者 Paul Bakaus）
- 官網：https://impeccable.style/
- 安裝：
npx impeccable install，然後在 Agent 裡跑/impeccable init
一句話把規模講完：1 個 skill、23 個指令、瀏覽器即時迭代，以及 60 條確定性的偵測規則。最後那個數字是重點——它的設計主張不是只寫給模型看的散文，其中 60 條是程式可以直接判定的。
作者背景
Paul Bakaus 的資歷幾乎就是這個 Skill 的信用來源：
- jQuery UI 作者——巔峰期被超過 14% 的網站使用
- 打造 Aves Engine（史上第一個完整互動的 HTML5 遊戲引擎原型），後來賣給 Zynga
- 在 Google 期間推出 Chrome DevTools 多項功能、AMP 與 Web Stories，之後成為 Google 首任 Head of Creator Relations，創辦 Google for Creators
- 近期任 Spotter 的 EVP of Product & Creator Tools，打造 Spotter Studio 與創作者 AI workflow
換句話說：一個做了二十年前端框架與開發者工具的人，把自己的設計判斷寫成規則交給 Agent 執行。這解釋了為什麼 impeccable 不只是 prompt——它附了 CLI、hook 與可被程式檢查的規則標記。
它在對抗什麼：AI slop
AI 產出的介面有固定味道——紫藍漸層、玻璃擬態、一模一樣的卡片格線、灰得看不清的內文。impeccable 的目標是逼 Agent 做出刻意、獨特、記得住的選擇，而不是安全的預設值。
架構：Setup → Register → Command
每次呼叫都先跑一段強制的 setup：
node scripts/context.mjs讀取專案的PRODUCT.md/DESIGN.md；沒有就視情況導向init（但不會因此擋掉小範圍請求）。- 讀對應子指令的
reference/<command>.md（原生平台則讀.native.md變體，兩者只讀一份）。 - 先讀專案既有的 design system／token／代表性元件——不重新發明輪子。
- 讀 register 參考檔：
reference/brand.md——行銷頁、活動頁、作品集（設計就是產品）reference/product.md——app UI、後台、儀表板（設計服務產品）
PRODUCT.md的 Platform 是ios/android/adaptive時，追加讀 HIG／Material 3 的參考檔。- 全新專案沒有既有色票時，跑
scripts/palette.mjs取得品牌種子色，再用 OKLCH 組出整套 palette。
這六步是它品質穩定的關鍵：先讀你的專案，再談美感。
23 個指令，五個分類
| 分類 | 指令 | 用途 |
|---|---|---|
| Build | init | 建立 PRODUCT.md、DESIGN.md、live 設定與後續建議 |
shape [feature] | 寫程式前先規劃 UX/UI | |
craft [feature] | 先 shape，再端到端把功能做完 | |
document | 從既有程式碼反推生成 DESIGN.md | |
extract [target] | 把可複用的 token 與元件抽進 design system | |
| Evaluate | critique [target] | UX 設計審查，含啟發式評分（會存成快照） |
audit [target] | 技術品質檢查：a11y、效能、RWD | |
| Refine | polish | 上線前的最終品質關（會拿 critique 快照當 backlog） |
bolder / quieter | 太平淡就放大，太吵就收斂 | |
distill | 剝到本質，砍掉複雜度 | |
harden | 生產就緒：錯誤狀態、i18n、邊界情境 | |
onboard | 首次使用流程、空狀態、啟用 | |
| Enhance | animate / colorize / typeset / layout | 動效、配色、字體階層、間距節奏 |
delight | 加入個性與記憶點 | |
overdrive | 推過常規極限 | |
| Fix | clarify | 改 UX 文案、標籤、錯誤訊息 |
adapt | 適配不同裝置與尺寸 | |
optimize | 診斷並修 UI 效能 | |
| Iterate | live | 在瀏覽器裡直接點選元素，即時生成替代版本 |
另有三個管理指令：pin / unpin（釘住常用指令）、hooks（開關編輯前攔截 hook）。
路由規則（不打指令也能用）
- 不帶參數 → 跑
context-signals.mjs，依專案現況推薦 2～3 個最有價值的下一步（例如：有程式碼但沒DESIGN.md→ 建議document；從沒 critique 過 → 建議critique；dev server 有跑 →live可用），再列出完整選單。絕不自動執行。 - 第一個字是指令 → 載入該指令的 reference，其餘全部當 target。
- 語意可對應 →「間距怪怪的」→
layout、「這錯誤訊息看不懂」→clarify、「顏色好扁」→colorize；兩個都像就問一次。 - 對不上 → 當一般設計請求處理，套用通用規則與 register。
硬性規則舉例（SKILL.src.md 內建）
每條規則都帶一個 rule: 標記，可被 CLI 偵測器對應：
- 對比：內文 ≥ 4.5:1，大字 ≥ 3:1，placeholder 同樣要 4.5:1。最常見的失敗是「淺灰內文配帶色近白背景」——為了優雅而用淺灰，是 AI 設計難讀的頭號原因。
- 彩底上的灰字看起來會髒：改用背景同色相的深色，或文字色的透明度。
- 行長 65–75ch。
- 不要配對兩款相似但不相同的字體（兩款幾何無襯線）；要嘛沿對比軸配（襯線＋無襯線），要嘛同一家族用不同字重。
- Hero 標題天花板
clamp()上限 ≤ 6rem；字距下限 ≥ -0.04em，再緊字就黏在一起。 - h1–h3 用
text-wrap: balance，長文用text-wrap: pretty。
不用 AI 也能跑的偵測器
npx impeccable detect src/ # 掃目錄
npx impeccable detect index.html # 掃單檔
npx impeccable detect https://example.com # 掃線上網址
README 標榜 60 條確定性的偵測規則——對應 SKILL.src.md 裡每條規則尾巴的 rule: 標記，因此「這份設計有沒有踩雷」可以被程式判定，而不是只能問模型。
內建的 scripts/detect.mjs 是純本地規則引擎（不連網、不需 npx），Agent 在推薦指令前會先跑它，把命中的 slop 家族折進建議——這是實測訊號，勝過用猜的。注意：live 與 detect 都是 web-only，原生 App 專案不適用。