figma-generate-library

figma-generate-library skill 概覽

figma-generate-library 的作用

figma-generate-library 能幫你用較少的猜測，從程式碼庫建立或更新 Figma 設計系統。它最適合需要 variables、semantic tokens、component libraries、說明頁，以及能忠實對應原始程式碼的 light/dark theming 的團隊。不同於一般化的 prompt，figma-generate-library skill 會提供一套有順序的 Design Systems 工作流程，幫你判斷先做什麼、哪些可以延後，以及如何維持檔案一致性。

適合誰使用

如果你要把產品 codebase 轉成可維護的 Figma library，尤其是需要可重用的基礎元件，而不是一次性的 mockup，這個 skill 就很適合。它適合 design systems lead、product designer、design engineer，以及處理 token parity、component publication 或 library cleanup 的 agents。若你只需要單一畫面或快速的視覺概念，這個 skill 通常太重了。

為什麼它不一樣

figma-generate-library 的核心價值在於編排：它假設工作是多步驟的，會檢查相依性，並在 variables、components 與 docs 之間維持有序建置。它設計來搭配 figma-use 使用；後者負責 Plugin API 呼叫，而這個 skill 則決定該做哪些東西，以及以什麼順序做。這讓 figma-generate-library skill 比單純的「建立設計系統」prompt 更有用，因為它減少的是結構性錯誤，而不只是輸出差異。

如何使用 figma-generate-library skill

安裝並載入正確的 skills

進行 figma-generate-library install 時，除了加上這個 skill，也要在任何 Figma 寫入步驟前先載入 figma-use。repository 預期在執行期間會保有 skill context，而且這套指引是要驅動許多較小的 use_figma 呼叫，而不是一次大批次處理。實務上，你應該把它視為一個工作流程 skill，而不是單一指令產生器。

先做探索，不要直接建立

先讀 SKILL.md，再查看 references/discovery-phase.md、references/token-creation.md、references/component-creation.md 和 references/documentation-creation.md。如果你預期可能失敗或執行中斷，也要讀 references/error-recovery.md。這些支援腳本很明確地表示，整個流程依賴檔案檢視、狀態重建、驗證與清理，而不是盲目生成。

把模糊目標轉成可用的 prompt

一個好的 figma-generate-library usage prompt 會包含 codebase、目標 framework、要生成的內容，以及 Figma 裡已經存在什麼。例如：「根據 src/styles/tokens.css 和 src/components，為我們的 React app 建立 tokens 和核心 components，保留現有 page 名稱，並優先處理 Button、Input 和 Badge，再做 documentation pages。」這比「做一個設計系統」更好，因為這個 skill 可以把你的真實限制映射成有順序的流程，並避免做過頭。

能提升輸出的實務流程

使用這個 figma-generate-library guide 模式：1) 找出 token 來源與命名規則，2) 建立 variables 與 semantic aliases，3) 按依賴順序建立 components，4) 加入 documentation，5) 驗證並清理。若你想了解這個 skill 如何看待結構與驗證，可以先看 scripts/inspectFileStructure.js、scripts/createVariableCollection.js、scripts/createComponentWithVariants.js 和 scripts/validateCreation.js。若想讓輸出更好，在要求它開始之前，先提供實際的 token 來源、既有 page 名稱，以及任何 component inventory。

figma-generate-library skill 常見問題

figma-generate-library 只適合 design systems 嗎？

是，主要就是如此。figma-generate-library skill 是為 Figma 裡的 design systems 設計的，特別適合需要可重用基礎、component variants，以及 code-to-design 對齊的情境。它不是 ad hoc layout 產生或單一簡報檔案的最佳選擇。

它和一般 prompt 有什麼不同？

一般 prompt 可能會產出看起來合理的 Figma 規劃，但 figma-generate-library 多了強制性的順序、相依性意識，以及復原邏輯。當任務橫跨很多 node、multiple collections 或反覆修改時，這點特別重要。如果你重視整個 library 的一致性，這個 skill 會比從零開始寫 prompt 更適合作為起點。

初學者需要先懂整個 repository 嗎？

不用。只要能辨識 codebase 和想要的 Figma 輸出，初學者也能使用這個 skill。初學者最常見的風險是範圍定義得太含糊，結果只做出部分 library，或命名對不上。若你剛開始，先從少量 tokens 和一兩個核心 components 做起，再嘗試完整 library。

什麼情況下不該用這個 skill？

如果你只需要快速的視覺探索、一次性 prototype，或是不依賴 code parity 的任務，就不要用 figma-generate-library。當你無法提供可靠的 token、component 名稱或 theming 規則來源時，它也不是好選擇。

如何優化 figma-generate-library skill

先提供最有價值的輸入

figma-generate-library 的最佳結果來自具體的來源素材：token 檔、theme variables、component 目錄，以及既有的 Figma 檔案結構。如果可以，請提供精確路徑，並註明當 code 與 Figma 不一致時，應以哪個來源為準。這能減少命名、mode mapping 與 component 排序上的歧義。

明確指定 library 最重要的目標

使用者通常最在意三件事：token fidelity、component 一致性，以及這個 library 是否能順利 publish。請一開始就講清楚你的優先順序，例如「完全對齊 code tokens」、「保留既有 component 名稱」，或「以乾淨的 public asset panel 為優先」。這些優先順序會影響 skill 怎麼取捨，尤其是在來源不完整時。

避開常見失敗模式

最常見的問題，是一次想做太多、跳過 discovery，以及混用不相容的命名規則。另一個常見問題，是在底層 variables 還沒建立前，就先要求 components。若 figma-generate-library skill 的輸出感覺不對，先檢查你是否提供了 token source、component inventory，以及清楚的 file-state snapshot。

在第一輪之後持續迭代

把第一版結果當成 library 規劃草稿，而不是最終檔案。先檢視已建立的內容，再透過要求補上缺少的 token 層級、下一層相依元件，或清理孤立 node 來微調。如果初始輸出已經接近但還不完整，下一輪通常最好更聚焦，例如：「新增 semantic color modes」、「根據現有 atom set 建立 Button variants」，或「只為已建立的 foundations 製作文件」。