$npx -y skills add figma/mcp-server-guide --skill figma-generate-libraryBuild or update a professional-grade design system in Figma from a codebase. Use when the user wants to create variables/tokens, build component libraries, create individual components with proper variant sets and variable bindings, set up theming (light/dark modes), document fou
| 1 | # Design System Builder — Figma MCP Skill |
| 2 | |
| 3 | Build professional-grade design systems in Figma that match code. This skill orchestrates multi-phase workflows across 20–100+ `use_figma` calls, enforcing quality patterns from real-world design systems (Material 3, Polaris, Figma UI3, Simple DS). |
| 4 | |
| 5 | **Prerequisites**: The `figma-use` skill MUST also be loaded for every `use_figma` call. It provides Plugin API syntax rules (return pattern, page reset, ID return, font loading, color range). This skill provides design system domain knowledge and workflow orchestration. |
| 6 | |
| 7 | **Always include `figma-generate-library` in the comma-separated `skillNames` parameter when calling `use_figma` as part of this skill. If this skill was loaded via an MCP resource, you MUST prefix the name with `resource:` (e.g. `resource:figma-generate-library`).** This is a logging parameter — it does not affect execution. |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## 1. The One Rule That Matters Most |
| 12 | |
| 13 | For every phase, follow this communication contract. |
| 14 | |
| 15 | Before starting a phase: |
| 16 | - Post a user-facing checklist titled `Phase N Checklist`. |
| 17 | - Include every task/subtask that will be attempted in that phase. |
| 18 | - Include the phase exit criteria. |
| 19 | - Do not begin mutating work for the phase until this checklist has been posted. |
| 20 | - If the phase requires explicit approval, ask for approval after the checklist and wait. |
| 21 | |
| 22 | During execution: |
| 23 | - Before each major subsection, post a short update naming the exact section being worked on, using this format: |
| 24 | `Working on Phase N.X: <section name>` |
| 25 | - Keep updates concise, but make the current work visible. |
| 26 | - When a subsection completes, mark it as completed in the running checklist if the interface supports checklist/status updates; otherwise mention completion in the next progress update. |
| 27 | |
| 28 | At the end of each phase: |
| 29 | - Post a `Phase N Summary` with: |
| 30 | - Completed tasks |
| 31 | - Created or changed Figma objects |
| 32 | - Validations performed |
| 33 | - Decisions or conflicts resolved |
| 34 | - Remaining risks or follow-ups |
| 35 | - Then show the required phase artifact for that phase and continue automatically. |
| 36 | - Only ask for explicit approval after Phase 0 or if a genuine decision fork arises (see [Section 6](#6-decision-forks)). For Phases 1–4, the default is to continue automatically after the summary. |
| 37 | |
| 38 | ### Stable Task IDs |
| 39 | |
| 40 | Use one task ID format everywhere: `P{phase}.{step}`. |
| 41 | |
| 42 | Rules: |
| 43 | - Use lettered step IDs only: `P0.a`, `P0.b`, `P1.a`, `P3.d`. |
| 44 | - Do not use plain bullet points for task lists. |
| 45 | - Every phase checklist, progress update, validation note, and phase summary MUST reference the same task IDs |
| 46 | |
| 47 | **No setup exception:** Creating a new Figma file, importing a library, creating pages, variables, collections, styles, or components all count as creation/mutation. Do not treat any of them as harmless setup. |
| 48 | |
| 49 | **This is NEVER a one-shot task.** Building a design system requires 20–100+ `use_figma` calls across multiple phases, with mandatory progress between them. Any attempt to create everything in one call WILL produce broken, incomplete, or unrecoverable results. Break every operation to the smallest useful unit, validate, get feedback, proceed. |
| 50 | |
| 51 | --- |
| 52 | |
| 53 | ## 2. Mandatory Workflow |
| 54 | |
| 55 | Work through the phases in order. Do not move to the next phase until the current phase's required actions and acceptance checks are complete. If a phase cannot pass, stop and report the blocker. Do not approximate, skip, or defer a failed phase unless the user explicitly approves the limitation. No best-effort substitutions. No quiet approximations. No handoff with missing source truth, missing visual truth, fake assets, approximate typography, broken interactions, or unverified states. |
| 56 | |
| 57 | ### Phase 0: DISCOVERY (always first — no `use_figma` writes yet) |
| 58 | |
| 59 | - [ ] 0a. Analyze codebase → extract tokens, components, naming conventions |
| 60 | - [ ] 0b. Inspect Figma file → pages, variables, components, styles, existing conventions |
| 61 | - [ ] 0c. Search subscribed libraries → use `search_design_system` for reusable assets |
| 62 | - [ ] 0d. Lock v1 scope → exact token set + component list recorded before any creation |
| 63 | - [ ] 0e. Map code → Figma → every conflict (code disagrees with Figma) resolved and recorded |
| 64 | - [ ] 0f. Print a **gap analysis** to chat: |