design-system-importerlisted

Imports an EXISTING design system from Figma into a Claude-readable format and into code. Use this when the design system already exists (usually in Figma) and just needs to be translated into a spec Claude can apply and tokens the codebase can use — NOT when starting from scratch (use design-system-generator for greenfield/taste-based creation). Pulls colors, type, spacing, radius, shadows, icons, and component specs from Figma as the source of truth, writes a precise markdown spec at docs/design-system.md, syncs the actual code tokens (e.g. src/styles.css @theme) to match Figma, produces an HTML visual style guide, and updates CLAUDE.md. Trigger whenever the user wants to import, sync, translate, extract, or 'get my Figma design system into code / into a format Claude can read', or wants the prototype's tokens corrected to match the real Figma system. The Figma file is always the source of truth; the existing code/prototype is not.
brianamazzio/design-system-toolkit · ★ 0 · Web & Frontend · score 70

Install: claude install-skill brianamazzio/design-system-toolkit

# Design System Robust (Figma → Spec → Code) You help a designer who **already has a design system** — almost always in Figma — get it into two places it isn't yet: a **Claude-readable markdown spec**, and the **project's code tokens**. This is an **import/translate** job, not a creation job. Do not run a taste interview ("how should it feel"). The decisions are already made; your job is faithful extraction and translation. ### The one rule that governs everything **Figma is the source of truth. The code/prototype is NOT.** Data flows **one direction: Figma → spec → code.** The project's current tokens (and any auto-observed `docs/design-system.md`) are a rough starting point at best and are probably wrong. When Figma and the code disagree, **Figma wins**, and you update the code to match — never the reverse. ### Dual-file parity is an invariant — never update one without the other This skill maintains two parallel views of the same system: `docs/design-system.md` (agent-readable) and `design-system-visual.html` (human-readable). **Every change touches both, in the same turn.** Add a token, type style, icon, brand asset, or component → it goes into the markdown spec **and** gets rendered in the HTML guide. Fix a value → fix it in both. If a dev server serves a copy of the guide (e.g. in `public/`), re-sync that too. A change that lands in only one file silently desyncs the human and agent views — the exact failure this skill exists to prevent. Before finishing any desig