southleft/skills-for-figma

design-system-inventory-figma

One call to inventory an entire Figma design system — variables/tokens (grouped by collection + mode), components and component sets (with property definitions and per-variant visual specs), and styles (color/text/effect with resolved values).

Ver código fuente
Documento original del Skill

Contenido del repositorio de origen con títulos, ejemplos, código, tablas, enlaces e imágenes preservados.

design-system-inventory-figma — unified tokens + components + styles extraction

A single use_figma call that walks the whole file and returns a structured kit: tokens (every local variable, grouped by collection and mode), components (standalone components + component sets, with property definitions and a compact visualSpec per variant), and styles (paint/text/effect styles with their resolved values). It is the "read everything once" front door for code generation and library audits.

Skill boundaries

  • `use_figma` rules — load the official `figma-use` skill first; it is the full Figma Plugin API reference. Essentials these scripts rely on: plain JS with top-level await + return (no IIFE, no figma.closePlugin(); console.log is not returned), inputs inlined as const at the top of each script, colors in 0–1 range, load fonts before any text op, await figma.getNodeByIdAsync(...), and atomic errors (a failed script applies nothing — read the error, fix, retry).
  • The exact shape of each `visualSpec`references/visual-spec.md.
  • One component in unlimited depth (full tree, reactions, instance refs) →

use deep-component-figma. One variant set as a CSS state machine → use analyze-component-set-figma. Token files on disk → use export-tokens-figma.

  • This is a whole-system design capability the native MCP does not have: get_design_context

works on a single selection and get_metadata returns flat structure, neither gives a unified tokens+components+styles kit on ANY plan.

Workflow

  1. Pick scope & verbosity to control response size on big files. Edit the constants in

`scripts/inventory.js`:

  • INCLUDE — any of "tokens", "components", "styles" (default: all three).
  • VERBOSITY"full" (per-variant visual specs), "summary" (component metadata + props, no

per-variant specs), or "inventory" (names/ids/counts only — for huge files).

  • COMPONENT_NAME_FILTER — substring to limit components (e.g. "Button").
  1. Run via use_figma (skillNames: "design-system-inventory-figma"). Reads variables through

the Plugin API, so it works on every Figma plan (no Enterprise REST requirement).

  1. Consume. Use tokens for color/spacing/typography values, components[].properties for

the component API, components[].variants[].visualSpec for per-state appearance, and styles for any style-based (non-variable) values.

  1. If the result is still large, drop to a lower VERBOSITY or narrow INCLUDE /

COMPONENT_NAME_FILTER and re-run — don't try to page a giant full dump.

Notes

  • Colors are emitted as hex (Figma stores 0–1 RGBA internally); spacing/size values are px.
  • Variables resolve aliases to token names ({Color.Brand.Primary}-style) where possible.
  • Per-variant visual specs come from each variant component node — see

references/visual-spec.md for the fields (fills, strokes, effects, cornerRadius, opacity, layout/padding/spacing, typography).

  • This script is the open-coded, root+first-level equivalent of the bundled figma_get_design_system_kit

tool, written in the native use_figma idiom so it runs without the Desktop Bridge. It captures each component/variant's root visual spec plus its direct children (childSpecs); it does not recurse deeper.

del mismo repositorio

Más Skills

Todos los Skills
southleft
Comunidad

analyze-component-set-figma

Analyze a Figma COMPONENTSET as a state machine for code generation — extract variant axes (state/size/etc.), map state variants to CSS pseudo-classes (hover→:hover, focus→:focus-visible, disabled→:disabled, error→[aria-invalid]), and compute per-variant visual diffs (only what changes per state). Use when generating an interactive component from a Figma variant set — triggers: 'analyze this component set', 'turn these variants into CSS states', 'generate a button/input/checkbox from Figma variants', 'what changes between the hover and default state', 'map Figma variants to component props', 'extract the state machine for this component'. Resolves bound variables to token names. NOT covered by the native MCP's getdesigncontext/getmetadata, which don't give you a variant-axis→CSS-state machine.

instalaciones
1
GitHub Stars
14
Actualizado
1 jun
southleft
Comunidad

annotations-figma

Read and write designer annotations on Figma nodes — node-level design specs that pin properties (fills, width, fontSize, etc.) and carry plain or markdown notes. Use when the user wants to document or inspect interaction specs, animation timings, easing, accessibility requirements, or implementation notes attached directly to a node. Triggers: 'add an annotation', 'annotate this node/component', 'read the annotations on…', 'what specs are pinned to this element', 'list annotation categories', 'document the focus behavior on this button in Figma'. Annotations are distinct from comments (they pin to design properties) and from the description field. Requires the Figma Desktop app (Plugin API).

instalaciones
1
GitHub Stars
14
Actualizado
1 jun
southleft
Comunidad

audit-accessibility-figma

Deep accessibility scorecard for a single Figma component or component set — state coverage (default/hover/focus/disabled/error/active/loading), focus-indicator quality and contrast, non-color state differentiation, target size, annotation completeness, and color-blind simulation (protanopia/deuteranopia/tritanopia), all rolled into per-category 0–100 scores and prioritized recommendations. Use when the user wants to vet ONE component before shipping it: triggers 'audit this component', 'accessibility score for this button', 'is this component set accessible', 'check the states on this component', 'does my button have a focus state', 'color blind check', 'rate this component for a11y', 'component accessibility scorecard'. Works on ANY Figma plan. For a broad sweep over a whole page/frame use lint-design-figma; for CODE-side (HTML) checks use scan-code-accessibility-figma.

instalaciones
1
GitHub Stars
14
Actualizado
1 jun
southleft
Comunidad

check-design-parity-figma

Compare a Figma node's actual specs against a code spec (the values your component renders) and get a 0–100 parity score, a list of discrepancies, and fix suggestions. Use to detect design-to-code DRIFT: triggers 'check design parity', 'does my code match the Figma', 'compare this component to the design', 'is my implementation faithful', 'find differences between design and code', 'verify the build matches Figma', 'design QA against code', 'parity score'. Reads the node's visual / typography / spacing / token / accessibility specs via usefigma (any plan) and diffs them against a codeSpec you provide. Complements the native getdesigncontext: instead of GENERATING code, it VALIDATES that existing code stayed in sync with the design.

instalaciones
1
GitHub Stars
14
Actualizado
1 jun