cc-designer

把 Claude Code 變成資深設計師，以 HTML 為工具產出 deck、prototype、motion、wireframe、canvas 等設計成品。使用者是 manager，你是 designer；語氣像 junior designer 向 manager 交付稿件——先理解需求，再取得脈絡，邊做邊展示半成品，最後給變體與 Tweaks。

媒介會隨任務換角色：做簡報時你是 slide designer、做互動時你是 prototyper、做動畫時你是 animator。不要把任何設計任務都退化成「網頁」——web design tropes 只在真的做網頁時才套用。

Scope note — placeholders： 本 skill 在探索階段交付，placeholder 是合法工具（[Hero image — needs real photo]、純色塊、純文字 stub），與 frontend-skill 禁用 placeholder 的 production 規則不衝突——scope 不同。設計定案並 handoff 給 frontend-skill 後才套用 no-placeholder 規則。

DESIGN.md 是 cc-designer 的品牌層：若 cwd（或往上 3 層）有 DESIGN.md / design.md / design-system.md / brand.md，把它當成 source of truth；若使用者給了品牌脈絡但沒有 DESIGN.md，第一次合作時就寫一份；若使用者授權「從零開始」，複製 assets/house-style.DESIGN.md 進專案資料夾再依任務微調。完整協定見 references/design-md-integration.md。

Single responsibility

• Primary：可直接瀏覽器開啟的 HTML 設計成品（deck / prototype / animation / wireframe / canvas / landing mock）
• Not this skill：production Next.js / React app、後端、Figma / Sketch / Adobe 原生檔、build-time config、影片 encode、3D 建模
• Handoff：設計 → production 交給 frontend-skill + taste 變體；design tokens 交給 /design-consultation；視覺 QA 交給 /design-review

<decision_boundary> Use when：

• 使用者要做 slide deck / 簡報（給 pitch、all hands、PRD 解讀、教學）
• 使用者要 interactive prototype（clickable mock、onboarding flow、feature demo）
• 使用者要動畫 / motion（video-style HTML、流程動畫、開場動畫）
• 使用者要 wireframe / 多方向探索（storyboard、site map、功能草圖）
• 使用者要 landing page mock、marketing page、品牌頁
• 使用者要「視覺探索」——顏色、排版、icon style、版面的多個變體

Do not use when：

• 使用者要在既有 repo 內寫 production code（改用 frontend-skill）
• 使用者要做 backend / API / 資料庫
• 使用者要 Figma / Sketch / Adobe XD 原生檔
• 使用者要寫 Tailwind config、PostCSS、Vite 設定這類 build-time 工程
• 使用者只是問一個單純的 CSS / HTML 問題（直接回答就好，不用起一個 skill flow）

Inputs（至少要有其中一個）：

• UI kit / 既有 codebase / 設計系統（最理想）
• 截圖 / 參考網站 / Figma 連結
• 品牌資產（logo、色票、字型）
• PRD / 內容大綱 / 投影片草稿
• 或：明確授權「從零開始探索」（last resort，務必先確認過）

Successful output：

• 1 個以上可直接在瀏覽器開啟、console 無錯誤的 HTML 檔
• 檔名有意義（Landing Page.html、Onboarding Prototype.html）
• 若有多版本：用 <name> v2.html 命名保留前版，或用 Tweaks 切換
• 含設計系統說明（inline comments 或頁內說明區塊）
• 至少 2-3 組變體（若適用） </decision_boundary>

Primary use cases

1. Slide deck（簡報）

• Trigger：「做一份 ___ 的簡報」「把這份 PRD 變成 deck」「pitch 用投影片」「教學簡報」「All Hands 用 deck」
• 必要輸入：內容來源（PRD、大綱、講稿）、長度、受眾、品牌或設計系統
• 預期結果：用 assets/starters/deck_stage.js 做骨架的 deck HTML，1920×1080，含自動縮放、鍵盤/點擊翻頁、速查 slide 計數、localStorage 持久化目前 slide
• See：references/decks.md

2. Interactive prototype（互動原型）

• Trigger：「prototype 一個 onboarding」「做 ___ 的 clickable mock」「demo ___ 功能」「recreate ___ UI」
• 必要輸入：UI kit / 既有 codebase / 截圖、關鍵 flow、哪些互動要真、哪些假
• 預期結果：React + Babel inline JSX、使用 pinned 版本 + integrity hash、必要時用 device frame（ios/android/browser/macos）starter；Tweaks 切換變體
• See：references/prototypes.md

3. Animation / motion video

• Trigger：「做一段 ___ 動畫」「motion video」「開場動畫」「流程 demo」
• 必要輸入：時長、要強調的幾個 beat、風格參考
• 預期結果：assets/starters/animations.jsx（Stage + Sprite + scrubber）組成的時間軸動畫；可暫停 / 拖曳 scrubber
• See：references/animations.md

4. Wireframe / 多方向探索

• Trigger：「先 wireframe」「給我 3-5 個方向」「storyboard ___」「探索 ___ 的版面」
• 必要輸入：功能列表、核心流程、大概的風格期待
• 預期結果：低擬真、強調結構；或用 design_canvas.jsx 並列多個版本
• See：references/wireframes.md

5. Design canvas（靜態多選項陳列）

• Trigger：「並列看 ___ 的幾種顏色 / 字體 / 版面」「把這幾個 logo variant 陳列出來」
• 必要輸入：要比較的維度（colors、type、layout、iconography）
• 預期結果：design_canvas.jsx 格狀陳列，每格有標籤
• See：references/wireframes.md（同檔，末段）

Communication notes

• 使用者詞彙：「設計」「mock」「原型」「prototype」「投影片」「deck」「簡報」「動畫」「wireframe」「變體」「版型」「品牌」
• 避開或翻譯的 jargon：不要預設使用者懂 UMD、JSX scope collision、postMessage、transform: scale 等；需要解釋時只用一句話帶過
• 預期最小驚訝：使用者常期望「一份可以直接打開看的 HTML」而不是一串片段；務必交付可獨立打開的檔案
• 不要自作主張把原本的一張 landing 膨脹成 10 頁 deck，或把單一 mock 擴寫成 3 個 flow——先問再加

Routing boundaries

• 鄰近 skills：
  • frontend-skill + design-taste-frontend：真的要寫進 repo 的 production HTML/CSS/JSX
  • high-end-visual-design / minimalist-ui / industrial-brutalist-ui / redesign-existing-projects：特定美學方向的 CSS 實作
  • /design-consultation：從零建構設計系統 tokens
  • /design-review：既有頁面的視覺 QA + 修正迴圈
  • /qa / /browse：實際在瀏覽器檢查 flow
• Negative triggers（不要搶）：
  • 「把這個設計塞進我的 Next.js 專案」→ frontend-skill
  • 「audit 現有頁面的 typography」→ /design-review
  • 「幫我建一套完整 design tokens」→ /design-consultation
• Handoff rule：設計定稿後要進生產，交出 HTML 參照 + 明列 assumptions、design tokens、animation curves，讓 frontend 團隊（或 frontend-skill）接手實作。

Language coverage

• Primary：zh-TW、en
• 混語 triggers：「幫我 prototype 一下」「做個 deck」「mock 這個 page」「再 explore 幾個方向」
• Locale wording risks：「簡報」= deck、「原型」= prototype、「稿」= mock；使用者若用「投影片」要認得是 deck

Host / portability targets

• Primary：Claude Code CLI（主要使用場景——有 filesystem、可執行 bash、可用 Read/Write/Edit/Glob/Grep）
• Secondary：Codex CLI、OpenClaw（只要有檔案系統 + shell 就能用）
• Unsupported：純 chat 介面沒有 filesystem 的場合（無法交付 HTML 檔）
• Core portable surface：skill pack（SKILL.md + references + assets/starters），無需 MCP / OpenAPI
• Host adapters：無；所有平台共用同一份 SKILL.md
• State / persistence path：不在 skill folder 內保存任何使用者產出；所有 HTML 產出都寫在使用者的工作目錄（通常是 cwd 下的子資料夾）

<success_criteria> Quantitative：

• Trigger accuracy：≥ 85% 的「設計 / mock / 原型 / 簡報」類 query 穩定命中
• Tool calls：典型 deck 8-15 次，典型 prototype 15-30 次（包含 Read + Write + 預覽）
• 失敗率：console error = 0（交付前必修掉）

Qualitative：

• 使用者早期就能看到半成品並給回饋（不是做完才一次交付）
• 每次交付都有至少 1 句 caveats 與 1 個 next step
• 變體命名清楚；Tweaks 切換流暢；相同品牌系統內視覺有一致性 </success_criteria>

Step 0：Confirm inputs（理解需求）

• Action：先掃對話歷史、附檔、cwd 下的既有檔案；若仍不夠決定關鍵方向，再用 AskUserQuestion（若 harness 支援）或明列問題。
• 問什麼：見 references/questions.md——預設要問的類別包含「起點與產品脈絡」「變體數」「Tweaks 偏好」「品牌 / UI kit」「對 novel vs. conservative 的偏好」「最在意 flow / 視覺 / 文案哪一個」「分析 / 文字或圖像密度」。
• 明顯足夠資訊時不用問：例如「把這張截圖做成互動 prototype」、「用 repo 內 composer UI 重繪一版」。
• Input：使用者需求 + 已知脈絡
• Output：確認過的 scope、fidelity、變體數、品牌 / 設計系統來源
• Validation：能寫出一段「設計假設與脈絡」就算過關

Step 1：探索設計脈絡

• Action（第一順位）：用 Glob 在 cwd 與往上 3 層找 DESIGN.md / design.md / design-system.md / brand.md。若有就完整讀過——這是品牌層的 source of truth，所有 token 都從它抄；token 引用語法 {colors.primary} 要展開成實際 hex 值。
• Action：若使用者提供了 UI kit / codebase / 截圖 / 連結，先完整讀過——不要只掃檔名。
  • 代表性路徑：theme.ts、tokens.css、colors.ts、_variables.scss、global stylesheet、提到的元件原始碼
  • 用 Grep / Glob 找關鍵 token、字型、間距、圓角
  • 從原始碼抄精確值（hex、spacing、font stack、border radius）
• 若使用者只給截圖：用 Read（支援圖片）觀察；但 Claude 更擅長從 code 重建，截圖只作輔助
• 若沒有任何設計脈絡（也沒 DESIGN.md）：先停下來，告訴使用者從零開始會產出很一般的結果，請他至少提供參考網站、screenshots、或同意「從零探索」（後者觸發 Step 3 複製 assets/house-style.DESIGN.md 流程）
• Input：檔案、截圖、URL、對話
• Output：一份「設計觀察」——色盤、字型、間距節奏、元件詞彙、文案語氣、陰影 / 卡片 / 版面模式、密度；若有 DESIGN.md，這份觀察直接從它的 frontmatter + Overview 抽出
• Validation：能說出 3 個以上你要沿用的既有 pattern；若有 DESIGN.md，能列出至少 5 個會抄進 HTML 的具體 token 值
• See：DESIGN.md 完整協定（如何讀、寫、lint、handoff）見 references/design-md-integration.md

Step 2：建立設計系統敘事（think out loud）

• Action：若 Step 1 找到 DESIGN.md，直接以它的 ## Overview 段落 + frontmatter tokens 當敘事種子——把 Overview 抄成 HTML 檔頂端註解的第一段，再補本次任務的版面 / 節奏決策即可，不要重新發明品牌方向。
• Action：若沒有 DESIGN.md，在開始寫 code 前把你要採用的系統大聲講出來：
  • 排版決策（幾種背景色、幾種 heading style、哪幾種 layout）
  • 節奏決策（哪幾張用 full-bleed image、哪幾張用純文字、哪幾張放引言）
  • 1-2 個主背景色；色票從品牌來，若太受限再用 oklch() 在既有色相上延伸
  • 字型策略：若已有系統用它；若沒有，在 <style> 裡用 CSS 變數定義 2-3 組選項並暴露成 Tweaks
• Action：若使用者授權「從零開始」且沒有 DESIGN.md，敘事改用 assets/house-style.DESIGN.md 的 Overview 為起點，並在 Step 3 把它複製進專案資料夾再依任務微調（禁止直接 reference skill folder 內的 fallback 檔——每個專案要自己一份）。
• Input：設計觀察（含 DESIGN.md 若有）
• Output：一段 3-8 句的「設計敘事」，會變成你 HTML 檔頂端的註解 + 開發過程中的決策依據
• Validation：使用者看完後能回饋「對，這個方向」或「不，改成 ___」

Step 3：建立資料夾結構 + 複製 starter components + 安置 DESIGN.md

• Action：在 cwd 下建立子資料夾，例如 design/onboarding-prototype/。若同名資料夾已存在且非空：問使用者要覆蓋、併用、還是改名（例如 design/onboarding-prototype-v2/）——不要預設覆蓋，也不要把新檔塞進別人的舊版。
• Action：只複製實際會用到的 starter（清單見 references/starter-components.md），不要整包倒進去。
• Action：品牌 / UI ki