figma-create-design-system-rules

figma-create-design-system-rules 技能概覽

這個技能的用途

figma-create-design-system-rules 能幫你把 Figma 的實作知識，轉成 coding agents 可以遵循的、專屬於專案的規則。當你希望整個 codebase 在元件選擇、命名、token、檔案位置，以及「哪些東西不能硬寫死」這些決策上保持一致時，figma-create-design-system-rules skill 特別有用。

適合安裝給誰

如果你正在為某個 repo 建立或調整 Design System，尤其是 Figma 到 code 的流程常常跑偏、最後落到不一致的寫法，這個技能就很適合。它很適合前端團隊、design system owner，以及任何不想每次都在 prompt 裡重複解釋同一套實作慣例的人。

它的不同之處

figma-create-design-system-rules 最大的價值，在於它抓的是 repo 專屬慣例，而不是只給你泛泛的 design system 建議。它是為了搭配 Figma MCP server 設計的，因此能根據真實設計脈絡來建立規則，而不是靠猜。當你需要一套能在多個任務中重複使用的指引時，這會比一次性的 prompt 更實用。

如何使用 figma-create-design-system-rules 技能

安裝並連接必要工具

要進行 figma-create-design-system-rules install，先透過你的 skills manager 安裝這個技能，並且在要求產生規則之前，確認 Figma MCP server 已可使用。這個技能依賴 Figma 工具連線；如果沒有它，就拿不到足夠可信的設計脈絡來產出可用的專案規則。

先準備對的輸入

要讓 figma-create-design-system-rules usage 發揮效果，起手式應該是一個很明確的目標：是哪個 repo、哪一段 codebase、以及你想要被保護住的實作風格。好的 prompt 會直接點出技術堆疊、元件的單一事實來源、樣式系統，以及限制條件，例如：

• “Generate rules for our Next.js app using Tailwind and shared components in src/components.”
• “Create Design System Rules for a React Native repo with tokens in JSON and strict accessibility checks.”

先讀這些檔案

實際使用 figma-create-design-system-rules guide 時，先看 SKILL.md，再檢查 agents/openai.yaml、references/rule-template.md，以及 scripts/check_agents_md.sh。這些檔案會告訴你預期的輸出格式、規則模板，以及這個 repo 是否預期根目錄要有 AGENTS.md。如果你要對接的是其他 agent，請改用技能中列出的對應規則檔路徑：

• Claude Code: CLAUDE.md
• Codex CLI: AGENTS.md
• Cursor: .cursor/rules/figma-design-system-rules.mdc

從設計脈絡寫到 repo 規則

最有效的流程是：先蒐集 Figma 脈絡，再對應到 codebase 的慣例，最後寫出足夠具體、能真正改變行為的規則。重點要放在 agent 不該自行發揮的決策，例如元件選擇、token 使用、命名模式，以及實作檔案應該放在哪裡。不要只是問寬泛的「最佳實務」；要直接要求反映你這個 repo 真實運作方式的規則。

figma-create-design-system-rules 技能 FAQ

這只適合 Design System 嗎？

不是。figma-create-design-system-rules for Design Systems 雖然是主要使用情境，但這個技能本質上是在把設計實作知識轉成可重用的 repo 規則。只要你的 codebase 有可重複的 UI 慣例，即使不是正式的 design system 團隊，也一樣能派上用場。

使用它一定要有 Figma MCP 嗎？

要。這個技能明確要求連上 Figma MCP server，所以它不是純文字 prompt 的工作流程。若你無法連接 Figma，直接下 prompt 可能更省事，但產出的內容通常比較沒有依據，也比較不容易重複使用。

它比一般 prompt 更好嗎？

通常是，前提是你需要的是可重複使用的規則，而不是一次性的答案。一般 prompt 可以解釋某一個畫面；figma-create-design-system-rules 則更適合當你希望模型在同一個 repo 裡，未來很多任務都持續沿用相同慣例時使用。

什麼情況下應該跳過它？

如果你只需要快速的一次性實作建議、你的 repo 還沒有穩定慣例，或是你無法確認目標規則檔與 agent 環境，就可以先不要用。這些情況下，短而精準的 prompt 往往比先安裝、再設定整套技能更快。

如何改善 figma-create-design-system-rules 技能

提供更嚴格的 repo 脈絡

品質提升最大的關鍵，是把 codebase 內哪些東西必須保持一致講清楚。請把元件路徑、token 來源、樣式系統、無障礙預期，以及命名規則都寫進去。例如，直接說明「src/ui 放基礎元件、src/features 放組合元件，而且絕對不要 inline color values」，會比「幫我的 app 寫規則」提供好得多的輸入。

要求能擋住錯誤的規則

figma-create-design-system-rules 最有價值的輸出，是一組能防止 Figma-to-code 常見失誤的 guardrails：硬寫 spacing、隨意新增元件、token 漂移，以及檔案放置混亂。你應該要求它寫出明確規則，告訴 agent 要選什麼、要避開什麼，以及當設計有歧義時，應該先去哪裡確認。

第一次產出後要檢視並收斂

把第一次輸出當成你真實 repo 的草稿，而不是最終政策文件。如果產出的規則太寬，請補上你 codebase 裡更窄的例子再重新產生；如果規則太死，就把造成阻礙的段落放寬，但保留那些能維持一致性的部分。最好的 figma-create-design-system-rules usage，通常來自一到兩輪、搭配真實 repository 範例的修訂。