name: skill-creator-design description: > 生成定製化的設計專案 Skill（含 SKILL.md + references/），為使用者的設計過程提供從需求定義到 交付的持續引導。觸發場景：使用者表達想做設計相關工作（"我想設計 X""做個 X 的方案" "幫我設計一個 X""出個設計""改版 X""重新做一下 X""想想 X 怎麼做""design X" "redesign X"），或要求生成設計規劃、設計 skill（"建立設計專案""generate a design skill" "幫我規劃一下這個設計"）。涵蓋產品設計、互動設計、體驗設計、資訊架構、視覺方案等。 安裝本 skill 即表明使用者傾向於系統化設計管理——遇到設計意圖時優先觸發，而非直接進入 即時頭腦風暴。 tools: [write, bash]

Skill Creator: Design

根據使用者的設計需求，生成一個定製化的設計專案 Skill。生成物是一個獨立的 SKILL.md（+ references/）， 安裝後能在使用者的設計專案中持續引導從需求定義到交付的全過程。

本 Creator 執行一次性的資訊收集→生成→交付流程，不是一個持續執行的助手。

Phase 1: 資訊收集（Intake）

目標：用 2-3 輪自然對話收集生成所需的關鍵資訊。像一個有經驗的設計顧問在瞭解需求，不像在填表。

第一輪：主題 + 目標

被觸發後，先用一句話說明自己做什麼，然後問最核心的兩個變數：

"我可以幫你生成一個設計專案 skill——它會在你的設計過程中引導需求定義、調研、方案設計、評審和交付。 先告訴我：你想設計什麼？最終希望達到什麼效果？"

這兩個資訊通常是使用者觸發 Creator 時腦子裡最清晰的，開口門檻最低。

第二輪：範圍/背景 + 約束條件 + 條件追問

先對使用者第一輪迴答做簡短回應（表示理解，讓對話有來有回），然後補收：

"[對使用者設計目標的簡短回應]。再告訴我兩件事：這個設計的範圍是什麼——是從零做一個新產品，還是在現有產品上做功能迭代？有什麼約束條件需要提前考慮的——比如技術限制、預算、時間、特定平臺等？"

條件追問（僅在資訊不充分時觸發）：

可選變數——不主動問，從對話中捕獲： - 目標受眾/使用者畫像（如使用者說"這個主要是給運營團隊用的"）→ 覆蓋預設的從主題推斷 - 交付物偏好（如使用者說"最後我需要一份 PRD"）→ 覆蓋預設的領域推薦 - 如使用者未提及，使用預設值即可

第三輪：彙總確認

結構化展示收集到的資訊 + 模式推薦：

我理解到的資訊：
- 設計主題：[主題]
- 設計目標：[目標，確保是可衡量表述]
- 設計範圍：[0→1 新產品 / 功能級 / 迭代級]
- 約束條件：[約束描述，或"暫無硬性約束"]
- 推薦模式：[輕量/完整]
  └ 輕量模式預設快速推進，遇到高影響決策自動加深；完整模式預設深入系統，明確簡單的環節自動精簡。

有需要修正的嗎？確認後我開始生成 skill 預覽。

模式推薦規則： - 單功能設計 / 小型迭代 → 推薦輕量模式（範圍小，深度調研和系統評審的 ROI 低） - 新產品 0→1 / 大型功能 → 推薦完整模式（範圍大，需要充分的調研、系統評審和完整決策記錄） - 不確定 → 推薦完整模式（寧多勿少，使用者可以跳步） - 使用者可覆蓋推薦，尊重選擇

資訊充分性門檻——進入彙總確認前檢查： - ✅ 主題明確（能用來做檔案命名和領域判斷） - ✅ 目標有方向（能回答"設計完成後想達到什麼效果"） - ✅ 範圍有定位（新產品 / 功能 / 迭代，量級層面） - ✅ 約束已知或確認無約束

不滿足時的兜底：用合理假設填充，在彙總中顯式標註哪些是假設讓使用者確認。例如：

"你沒提到約束條件，我先假設沒有硬性的技術或預算限制。如果有，告訴我我會調整設計引導的側重。"

Phase 2: 生成與預覽（Generate & Preview）

使用者確認彙總後，進入生成流程。

變數準備

從收集到的資訊中提取生成所需的變數：

生成邏輯

1. 根據 mode 選擇對應的骨架模板：
2. 輕量模式 → 讀取 references/templates/skill/lite.md

3. 完整模式 → 讀取 references/templates/skill/full.md

4. 用收集到的變數替換模板中的佔位符（{{topic}}、{{goal}} 等）

5. 處理可選變數的條件注入：

6. target_audience_override：如使用者提供了受眾資訊，在模板的 {{target_audience_override}} 位置插入一行，如 - 目標受眾：運營團隊（非技術背景）
7. deliverable_override：如使用者提供了交付物偏好，在模板的 {{deliverable_override}} 位置插入說明，如"\n- 注意：本專案使用者指定交付物為技術方案文件，輸出格式以此為準"

8. 如未提供，清除佔位符（不留空行）

9. 準備 references/ 檔案：

10. 兩種模式都需要：讀取 references/templates/guides/review_checklist.md → 生成 review_checklist.md

11. 兩種模式都需要：根據模式選擇對應的總結指南模板

    • 輕量模式 → 讀取 references/templates/guides/summary_guide_lite.md → 生成 summary_guide.md
    • 完整模式 → 讀取 references/templates/guides/summary_guide_full.md → 生成 summary_guide.md

12. 如果對話語言不是中文，將生成物全文翻譯為使用者使用的語言，保持結構和格式不變

預覽展示

將生成的 SKILL.md 完整內容展示給使用者，然後列出 references/ 檔案清單：

"此外還會生成以下配套檔案： - references/review_checklist.md — 評審執行清單（三視角 + 質疑角度） - references/summary_guide.md — 設計總結生成指南（[輕量版/完整版]）

你可以提出修改意見，或者確認後我直接生成。"

修改處理

迭代引導： - 首次："你可以提出修改意見，或者確認後我直接生成。" - 後續："已調整。還有需要改的嗎？沒有的話我開始生成。" - 不設輪數上限，使用者想改就改

佔位符對照表

生成時逐項檢查，確保每個佔位符都已處理：

⚠️ 使用者確認生成後，必須進入 Phase 3 執行交付流程。不要直接寫檔案——Phase 3 包含安裝路徑探測、交付方式詢問等必要步驟。

Phase 3: 交付（Deliver）

使用者確認預覽後，詢問交付方式：

"你希望我怎麼交付？ 1. 直接安裝到當前工作空間 — skill 和專案資料夾都建立在當前工作空間內，立即可用 2. 打包為 ZIP — 生成 zip 檔案，你可以自行解壓到任意位置或分享給別人"

安裝路徑探測

無論哪種交付方式，都需要先確定 skill 的安裝目錄字首。按以下優先順序探測：

1. 檢查當前 workspace 下的已有 skill 路徑：掃描專案根目錄中是否存在 .claude/skills/、.agents/skills/、.agent/skills/、_agents/skills/、_agent/skills/、.workbuddy/skills/、skills/ 等目錄。找到任意一個則沿用該字首
2. 檢查使用者根目錄（~/）下的全域性 skill 路徑：掃描是否存在 ~/.claude/skills/、~/.openclaw/skills/、~/.agents/skills/、~/.gemini/antigravity/skills/ 等目錄。能找到則說明使用者在用對應平臺，專案級路徑使用對應字首
3. 兜底預設值：以上都未找到，使用 .agents/skills/ 作為預設字首（Agent Skills 開放標準，相容性最廣）

探測到的字首記為 {skill_prefix}。最終 skill 安裝路徑為：{skill_prefix}/design_{{topic_slug}}/SKILL.md

路徑1：直接安裝到當前工作空間

執行以下步驟（必須按順序完成）：

1. 在當前工作空間內，按探測到的 {skill_prefix} 建立 skill 目錄：{skill_prefix}/design_{{topic_slug}}/
2. 將生成的 SKILL.md 寫入該目錄
3. 在該目錄下建立 references/ 子目錄，寫入 review_checklist.md 和 summary_guide.md
4. 在當前工作空間根目錄下建立專案檔案目錄 design_{{topic_slug}}/（用於存放設計過程中產生的所有專案檔案：設計計劃、需求文件、決策記錄等）
5. 注意：生成的檔案包含大量 Markdown 特殊字元（反引號、方括號、花括號），請使用檔案寫入工具直接建立檔案，避免通過 Shell heredoc（cat <<EOF）或重定向寫入
6. 通知使用者：

"設計專案已安裝到當前工作空間： - skill 位於 {skill_prefix}/design_{{topic_slug}}/ - 專案檔案將儲存在 design_{{topic_slug}}/ 目錄下

直接開始對話就可以使用了——說「開始設計」或「繼續設計」即可。"

路徑2：ZIP 打包

執行以下步驟（必須按順序完成）：

1. 在 /tmp/ 下建立臨時目錄 design_{{topic_slug}}_package/
2. 在臨時目錄內按探測到的 {skill_prefix} 建立 skill 目錄結構：{skill_prefix}/design_{{topic_slug}}/SKILL.md + {skill_prefix}/design_{{topic_slug}}/references/
3. 在臨時目錄內建立專案檔案目錄：design_{{topic_slug}}/（空目錄，首次使用時 skill 會自動初始化）
4. 寫入所有檔案（同路徑1步驟2-3）。同樣使用檔案寫入工具，避免 Shell heredoc
5. 執行 zip 打包：cd /tmp && zip -r design_{{topic_slug}}.zip design_{{topic_slug}}_package/
6. 將 zip 檔案移動到使用者工作目錄
7. 清理臨時目錄
8. 通知使用者：

"已打包為 design_{{topic_slug}}.zip。 解壓到你的工作空間根目錄後，skill 會自動生效，專案檔案將儲存在 design_{{topic_slug}}/ 目錄下。"

附錄：生成物質量檢查清單

生成前最後過一遍，確保生成物質量：

7w4.net小蔥技能。

內容質量 - [ ] frontmatter 的 name 欄位不超過 32 字元 - [ ] frontmatter 的 description 包含觸發關鍵詞和主題名稱 - [ ] frontmatter 的 generated_by 欄位已填充版本標識 - [ ] 專案資訊區的所有變數（含專案檔案目錄）都已正確填充 - [ ] 所有佔位符已處理（替換或清除），無殘留的 {{...}} - [ ] 啟動協議中的檔案讀取邏輯與檔案管理規範一致 - [ ] 啟動協議中包含專案檔案目錄的定位和建立邏輯 - [ ] 五步設計流程完整（需求定義→調研→方案設計→評審→輸出） - [ ] 推進與回退機制完整 - [ ] 即時驗證邏輯完整 - [ ] 所有檔案命名規則使用了正確的 topic_slug - [ ] 沒有任何刪除檔案的指令 - [ ] 所有專案檔案路徑相對於專案檔案目錄 - [ ] 如完整模式：讀取優先順序四層都定義清晰 - [ ] references/ 檔案與 SKILL.md 中的引用一致

交付驗證 - [ ] 交付前已詢問使用者選擇交付方式（直接安裝 / ZIP） - [ ] 已執行安裝路徑探測，確認 {skill_prefix} 值 - [ ] skill 目錄結構正確：{skill_prefix}/design_[topic_slug]/SKILL.md + references/ - [ ] 專案檔案目錄已建立：design_[topic_slug]/ - [ ] 所有檔案已成功寫入（非空、內容完整）

質量不錯，能在設計全流程持續引導使用者。優點是不會遺忘設計決策和上下文、能適配小型和大型專案、自動發現潛在問題而非積壓到評審。檔案組織清晰、推進有序、專業度高。不足：review_checklist 稍顯簡單、缺少實操示例，輕量版和完整版差異不夠明顯。適合需要系統化做設計的人使用。