flcker/figma-ui-web

Figma Web UI Development Standard (Framelink MCP Edition)

Resolves poor fidelity when developing Web frontend UI from Figma designs. The root cause is treating Figma's "canvas data" (absolute coordinates, inline color values, pixel-layer stacking) as "implementation data," copying it directly, which breaks responsive layouts, causes color/font inaccuracies, and missing assets.

This skill is designed for Framelink's figma-developer-mcp with two tools:

Tool	Channel	Purpose
get_figma_data	Precision channel	Pull canvas data by fileKey + nodeId: layout, content, visuals, component info
download_figma_images	Visual channel	Export nodes as SVG/PNG/GIF to a local directory by node ID

Note: This is the Framelink version, not the official Figma MCP Server (whose tools are get_design_context/get_variable_defs/download_assets). The methodology is common to both, but tool names follow Framelink's.

For desktop targets (Qt Widget / QML / WinUI / Flutter), use figma-ui-desktop instead of this skill.

Core Principles

1. Dual-channel parallel, no single-channel coding. The precision channel provides exact values; the visual channel provides overall layout and copy. Using only one guarantees distortion—especially using only the visual channel (equivalent to guessing from a screenshot) or only the data channel (equivalent to coding blind).
2. Use exact values, no visual estimation. Colors, font sizes, line height, font weights, spacing, border radius, borders, shadows—all must use the exact values from the design.
3. Request the design first; don't spontaneously write UI.
4. After implementation, a validation loop is mandatory: Compare screenshots to the design → auto-fix defects → human review and iterate. There's no magic to get 100% in one shot; 70-80% fidelity comes from the process, and the rest is filled by the validation loop.

Workflow

Phase One: Skim (Understand Requirements & Structure)

For large designs, skim first to avoid overloading context with a full pull:

1. Use get_figma_data to pull the top-level structure (depth controls traversal depth; start shallow) to understand pages/sections/components.
2. Use download_figma_images to export the overall page image to understand layout and copy.

Phase Two: Deep Read (Get Precise Data Before Implementation)

For the specific components/sections to implement, simultaneously call:

• get_figma_data (with nodeId, read coordinates, color values, font sizes, spacing, border radius, borders per node)
• download_figma_images (export the section image to confirm relative positions of components)

After obtaining data, perform structural analysis before coding:

• Which nodes are repeated patterns (cards, list items, buttons) → extract as components
• Which absolute positions are actually layouts (horizontal arrangement, centering, space-between) → convert to flex/grid
• What are the semantic roles (navigation/form/list) → map to existing UI library components in the project
• Image/icon nodes → download original files to assets via download_figma_images ; do not hand-draw

Phase Three: Implementation

• Use exact colors/font sizes/spacing from the design, no "looks close enough"
• Prioritize using the project's existing component library; first check component props (theme/size/variant) to avoid duplicate style definitions
• Use icons from the project's icon library, not third-party icons
• Follow project conventions for style file naming, CSS class names, indentation depth

Phase Four: Validation Loop

Use Playwright MCP to open the local page, take a screenshot, compare it side-by-side with the design screenshot, automate fixing obvious defects; then human review: identify finer issues (spacing, font weight, color nuances) and actively pass them to the AI for precise fixes, entering the next iteration.

Anti-Laziness Hard Rules

AI tends to use only one channel to code; explicitly require:

• "Call both get_figma_data and download_figma_images to read the design"
• "Do not use only images/screenshots to read the design before writing code"
• "Read get_figma_data's exact values line by line; compare colors, font sizes, and spacing; do not visually estimate"

Component Standards (Replace Per Project)

The following is a template; replace with the project's conventions when applied to a specific project:

• Prioritize using the project's component library (e.g., @notta/components); if in doubt, proactively ask the user
• First check component props; avoid duplicate style definitions
• Use icons from the project's icon library
• Follow project conventions for style file naming, CSS class names, and nesting depth

Fidelity Self-Checklist

Check each item after generation (more reliable than "does it look similar"):

• Colors (are exact hex values used, not approximations?)
• Font sizes / line heights / font weights
• Spacing / margins / padding
• Border radius / borders / shadows
• Layout (does flex/grid match the design's arrangement?)
• z-index / layers
• Are icons/images original files, not hand-drawn?

References

The methodology draws from the official Figma MCP + Playwright UI development workflow (see "Using Figma mcp and Playwright mcp to Boost UI Development and Debugging Efficiency"), with the core ideas being "dual-channel + validation loop + explicit anti-laziness requirements." Tool names have been adapted to Framelink's figma-developer-mcp.