色彩調色盤
將基礎顏色擴展為感知均勻的色階，並組合成調色盤。所有數學運算委託給內建生成器；此技能的判斷在於配置和驗證。
原理（為何選擇 OKLCH）
- 絕不在 HSL/RGB 中生成色階。 HSL 亮度會誤導（相同數值 ≠ 相同感知亮度），且色相在調淺/調暗時會偏移。相等 HSL 亮度使黃色看起來太亮，藍色看起來太暗。
- OKLCH 是工作空間：L（亮度）、C（色度）、H（色相）— 相等數值看起來相等，且原生 CSS 支援。
- 色度必須按步驟進行色域裁切。 高色度在極亮/極暗步驟物理上不可能；生成器會降低色度，而不是讓瀏覽器裁切。
- 一個對比錨點：白色文字從 L ≈ 0.55 向下通過 WCAG AA，黑色文字從 L ≈ 0.60 向上。中間步驟放置於這些目標周圍。
完整理論與來源：references/theory.md
工作流程
1. 釐清目標
與使用者確認（已知道的則跳過）：基礎顏色或品牌顏色；步驟數量（11 為標準，9 較精簡，12 適用於 Radix 風格角色）；調色盤需要哪些色相（品牌 + 語意：成功/警告/危險/資訊 + 中性）；是否需要暗色模式？
2. 生成色階
cd "{skill_dir}/scripts" && python3 generate_ramp.py "#3b82f6" --steps 11 --chroma 90
# 多色相調色盤：單次調用，以逗號分隔名稱
python3 generate_ramp.py "#3b82f6" "#e11d48" "#22c55e" --names blue,red,green --format css
重要標誌：--chroma N（每個步驟色域最大值的百分比；通常 80-95，越高越鮮豔），--hue-drift D（從亮到暗刻意偏移色相，例如暗黃色轉向橙色；僅在要求時使用），--cvd（模擬色盲的十六進位碼），--format table|css|json。
多色相規則：在單次調用中生成所有色相，使它們在每個步驟共用相同的亮度和色度百分比 — 這正是讓 blue-500 和 red-500 感覺像兄弟的原因。切勿用不同邊界重新生成任何色相。
3. 驗證
閱讀表格輸出並檢查：
- 亮度單調遞增，相鄰步驟的 ΔE 大致恆定（均勻性欄位）
- 預期前景/背景步驟組合通過 WCAG AA（白色文字需要步驟的
vs-white ≥ 4.5；黑色文字需要vs-black ≥ 4.5） - 跨色相 ΔE 警告不存在（相同步驟色相之間的 Oklab ΔE ≥ 0.05）
- 使用
--cvd：模擬色盲的步驟顏色在用於傳達意義的 UI 步驟中仍然可區分
如果使用者提供了要審計的現有調色盤，將每個步驟轉換為 OKLCH（透過重建使用 --format json，或手動轉換）並檢查相同的四點。
4. 組合調色盤
- 為步驟分配角色（Radix 慣例）：1-2 應用程式背景 · 3-5 元件背景（一般/懸停/啟用） · 6-8 邊框/焦點 · 9-10 純色背景與懸停（步驟 9 = 最純、最高色度） · 11-12 文字（低/高對比度）。
- 語意別名化：當色階服務於單一意義時，使用
--danger-500而非--red-500。一個色階可以支援多個別名。 - 暗色模式 = 重新映射，而非重新生成：保留色階，翻轉語意分配（最亮步驟變成最暗表面，文字顏色交換方向）。OKLCH 的感知均勻性使反向映射同樣可讀。
5. 交付
將 --format css 輸出寫入檔案（在 @supports 內包含十六進位降級的自訂屬性），並在聊天中提供驗證報告。如果最終目標是設計系統，建議標記命名（基本色階 + 語意別名層級）。
常見修正
| 問題 | 修正 |
|---|---|
| 步驟 50/100 看起來褪色 | 預期行為 — 接近白色時色度物理上受限；不要透過裁切來「修正」 |
| 色相看起來鮮豔度不均 | 所有色相使用同一次調用；嘗試 --chroma 80 |
| 某 500 步驟對白色文字對比度不足 | 接受用於大字型/圖形，或降低中間亮度（--hue-drift 無用；移動錨點） |
| 暗黃色看起來像橄欖色 | 刻意使用 --hue-drift 10-15 向橙色偏移，或接受作為品牌風格 |