agentleFS
ulises-jeremiasulises-jeremias/agent-toolkit/skills/design/figma-implement-design/SKILL.md

figma-implement-design

Skill19 starsChanged 2 months agoMITView on GitHub

Translates Figma designs into production-ready application code with 1:1 visual fidelity.

We split this skill into the rules it gives an agent

45 rules. 25 are common, 1 is distinctive, and 19 are very specific to this project.

  • 25

    Common

    Most of the 19 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 19

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the deliverable is code in the user's repository.

    line 18
  2. Very specific:

    If the user asks to create/edit/delete nodes inside Figma itself, install the opt-in figma-use pack (see docs/SKILLS.md).

    line 19
  3. Very specific:

    If the user asks to build or update a full-page screen in Figma from code or a description, install the opt-in figma-generate-design pack …

    line 21
  4. Very specific:

    If the user asks only for Code Connect mappings, switch to figma-code-connect-components.

    line 24
  5. Very specific:

    If the user asks to author reusable agent rules (AGENTS.md/CLAUDE.md), switch to figma-create-design-system-rules.

    line 26
  6. Very specific:

    OR when using figma-desktop MCP: User can select a node directly in the Figma desktop app (no URL required)

    line 36
  7. Common:

    When the user provides a Figma URL, extract the file key and node ID to pass as arguments to MCP tools.

    line 47
  8. Very specific:

    Note: When using the local desktop MCP (figma-desktop), fileKey is not passed as a parameter to tool calls.

    line 56
  9. Very specific:

    When using the figma-desktop MCP and the user has NOT provided a URL, the tools automatically use the currently selected node from the open …

    line 66
  10. Very specific:

    Run get_design_context with the extracted file key and node ID.

    line 72
  11. Very specific:

    Run get_metadata(fileKey=":fileKey", nodeId="1-2") to get the high-level node map

    line 88
  12. Very specific:

    Run get_screenshot with the same file key and node ID for a visual reference.

    line 94
  13. Common:

    IMPORTANT: Follow these asset rules:

    line 106
  14. Very specific:

    If the Figma MCP server returns a localhost source for an image or SVG, use that source directly

    line 108
  15. Common:

    DO NOT import or add new icon packages - all assets should come from the Figma payload

    line 109
  16. Very specific:

    DO NOT use or create placeholders if a localhost source is provided

    line 110
  17. Common:

    Treat the Figma MCP output (typically React + Tailwind) as a representation of design and behavior, not as final code style

    line 119
  18. Common:

    Use the project's color system, typography scale, and spacing tokens consistently

    line 122
  19. Common:

    Avoid hardcoded values - use design tokens from Figma where available

    line 132
  20. Common:

    When conflicts arise between design system tokens and Figma specs, prefer design system tokens but adjust spacing or sizes minimally to …

    line 133
  21. Common:

    Follow WCAG requirements for accessibility

    line 134
  22. Common:

    Add component documentation as needed

    line 135
  23. Common:

    Before marking complete, validate the final UI against the Figma screenshot.

    line 139
  24. Common:

    Place UI components in the project's designated design system directory

    line 155
  25. Common:

    Follow the project's component naming conventions

    line 156
  26. Common:

    Avoid inline styles unless truly necessary for dynamic values

    line 157
  27. Common:

    ALWAYS use components from the project's design system when possible

    line 161
  28. Common:

    When a matching component exists, extend it rather than creating a new one

    line 163
  29. Common:

    Document any new components added to the design system

    line 164
  30. Common:

    Avoid hardcoded values - extract to constants or design tokens

    line 168
  31. Common:

    Keep components composable and reusable

    line 169
  32. Common:

    Add TypeScript types for component props

    line 170
  33. Very specific:

    Run get_screenshot(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15") for visual reference

    line 183
  34. Common:

    Check if project has existing button component

    line 185
  35. Common:

    If yes, extend it with new variant.

    line 186
  36. Very specific:

    Run get_metadata(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5") to understand the page structure

    line 199
  37. Very specific:

    Run get_design_context(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId=":childNodeId") for each major section

    line 201
  38. Very specific:

    Run get_screenshot(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5") for the full page

    line 202
  39. Very specific:

    Never implement based on assumptions.

    line 214
  40. Common:

    If you must deviate from the Figma design (e.g., for accessibility or technical constraints), document why in code comments.

    line 222
  41. Common:

    Always check for existing components before creating new ones.

    line 226
  42. Common:

    When in doubt, prefer the project's design system patterns over literal Figma translation.

    line 230
  43. Very specific:

    Solution: Use get_metadata to get the node structure, then fetch specific nodes individually with get_design_context.

    line 237
  44. Very specific:

    Solution: Verify the Figma MCP server's assets endpoint is accessible.

    line 247
  45. Common:

    Solution: When project tokens differ from Figma values, prefer project tokens for consistency but adjust spacing/sizing to maintain visual …

    line 252

“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Implement Design

Overview

This skill provides a structured workflow for translating Figma designs into production-ready code with pixel-perfect accuracy. It ensures consistent integration with the Figma MCP server, proper use of design tokens, and 1:1 visual parity with designs.

Skill Boundaries

  • Use this skill when the deliverable is code in the user's repository.
  • If the user asks to create/edit/delete nodes inside Figma itself, install the opt-in figma-use pack (see docs/SKILLS.md).
  • If the user asks to build or update a full-page screen in Figma from code or a description, install the opt-in figma-generate-design pack (see docs/SKILLS.md); it requires figma-use.
  • If the user asks only for Code Connect mappings, switch to figma-code-connect-components.
  • If the user asks to author reusable agent rules (AGENTS.md/CLAUDE.md), switch to figma-create-design-system-rules.

Prerequisites

  • Figma MCP server must be connected and accessible
  • User must provide a Figma URL in the format: https://figma.com/design/:fileKey/:fileName?node-id=1-2
    • :fileKey is the file key
    • 1-2 is the node ID (the specific component or frame to implement)
  • OR when using figma-desktop MCP: User can select a node directly in the Figma desktop app (no URL required)
  • Project should have an established design system or component library (preferred)

Required Workflow

Follow these steps in order. Do not skip steps.

Step 1: Get Node ID

Option A: Parse from Figma URL

When the user provides a Figma URL, extract the file key and node ID to pass as arguments to MCP tools.

URL format: https://figma.com/design/:fileKey/:fileName?node-id=1-2

Extract:

  • File key: :fileKey (the segment after /design/)
  • Node ID: 1-2 (the value of the node-id query parameter)

Note: When using the local desktop MCP (figma-desktop), fileKey is not passed as a parameter to tool calls. The server automatically uses the currently open file, so only nodeId is needed.

Example:

  • URL: https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15
  • File key: kL9xQn2VwM8pYrTb4ZcHjF
  • Node ID: 42-15

Option B: Use Current Selection from Figma Desktop App (figma-desktop MCP only)

When using the figma-desktop MCP and the user has NOT provided a URL, the tools automatically use the currently selected node from the open Figma file in the desktop app.

Note: Selection-based prompting only works with the figma-desktop MCP server. The remote server requires a link to a frame or layer to extract context. The user must have the Figma desktop app open with a node selected.

Step 2: Fetch Design Context

Run get_design_context with the extracted file key and node ID.

get_design_context(fileKey=":fileKey", nodeId="1-2")

This provides the structured data including:

  • Layout properties (Auto Layout, constraints, sizing)
  • Typography specifications
  • Color values and design tokens
  • Component structure and variants
  • Spacing and padding values

If the response is too large or truncated:

  1. Run get_metadata(fileKey=":fileKey", nodeId="1-2") to get the high-level node map
  2. Identify the specific child nodes needed from the metadata
  3. Fetch individual child nodes with get_design_context(fileKey=":fileKey", nodeId=":childNodeId")

Step 3: Capture Visual Reference

Run get_screenshot with the same file key and node ID for a visual reference.

get_screenshot(fileKey=":fileKey", nodeId="1-2")

This screenshot serves as the source of truth for visual validation. Keep it accessible throughout implementation.

Step 4: Download Required Assets

Download any assets (images, icons, SVGs) returned by the Figma MCP server.

IMPORTANT: Follow these asset rules:

  • If the Figma MCP server returns a localhost source for an image or SVG, use that source directly
  • DO NOT import or add new icon packages - all assets should come from the Figma payload
  • DO NOT use or create placeholders if a localhost source is provided
  • Assets are served through the Figma MCP server's built-in assets endpoint

Step 5: Translate to Project Conventions

Translate the Figma output into this project's framework, styles, and conventions.

Key principles:

  • Treat the Figma MCP output (typically React + Tailwind) as a representation of design and behavior, not as final code style
  • Replace Tailwind utility classes with the project's preferred utilities or design system tokens
  • Reuse existing components (buttons, inputs, typography, icon wrappers) instead of duplicating functionality
  • Use the project's color system, typography scale, and spacing tokens consistently
  • Respect existing routing, state management, and data-fetch patterns

Step 6: Achieve 1:1 Visual Parity

Strive for pixel-perfect visual parity with the Figma design.

Guidelines:

  • Prioritize Figma fidelity to match designs exactly
  • Avoid hardcoded values - use design tokens from Figma where available
  • When conflicts arise between design system tokens and Figma specs, prefer design system tokens but adjust spacing or sizes minimally to match visuals
  • Follow WCAG requirements for accessibility
  • Add component documentation as needed

Step 7: Validate Against Figma

Before marking complete, validate the final UI against the Figma screenshot.

Validation checklist:

  • Layout matches (spacing, alignment, sizing)
  • Typography matches (font, size, weight, line height)
  • Colors match exactly
  • Interactive states work as designed (hover, active, disabled)
  • Responsive behavior follows Figma constraints
  • Assets render correctly
  • Accessibility standards met

Implementation Rules

Component Organization

  • Place UI components in the project's designated design system directory
  • Follow the project's component naming conventions
  • Avoid inline styles unless truly necessary for dynamic values

Design System Integration

  • ALWAYS use components from the project's design system when possible
  • Map Figma design tokens to project design tokens
  • When a matching component exists, extend it rather than creating a new one
  • Document any new components added to the design system

Code Quality

  • Avoid hardcoded values - extract to constants or design tokens
  • Keep components composable and reusable
  • Add TypeScript types for component props
  • Include JSDoc comments for exported components

Examples

Example 1: Implementing a Button Component

User says: "Implement this Figma button component: https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15"

Actions:

  1. Parse URL to extract fileKey=kL9xQn2VwM8pYrTb4ZcHjF and nodeId=42-15
  2. Run get_design_context(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15")
  3. Run get_screenshot(fileKey="kL9xQn2VwM8pYrTb4ZcHjF", nodeId="42-15") for visual reference
  4. Download any button icons from the assets endpoint
  5. Check if project has existing button component
  6. If yes, extend it with new variant; if no, create new component using project conventions
  7. Map Figma colors to project design tokens (e.g., primary-500, primary-hover)
  8. Validate against screenshot for padding, border radius, typography

Result: Button component matching Figma design, integrated with project design system.

Example 2: Building a Dashboard Layout

User says: "Build this dashboard: https://figma.com/design/pR8mNv5KqXzGwY2JtCfL4D/Dashboard?node-id=10-5"

Actions:

  1. Parse URL to extract fileKey=pR8mNv5KqXzGwY2JtCfL4D and nodeId=10-5
  2. Run get_metadata(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5") to understand the page structure
  3. Identify main sections from metadata (header, sidebar, content area, cards) and their child node IDs
  4. Run get_design_context(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId=":childNodeId") for each major section
  5. Run get_screenshot(fileKey="pR8mNv5KqXzGwY2JtCfL4D", nodeId="10-5") for the full page
  6. Download all assets (logos, icons, charts)
  7. Build layout using project's layout primitives
  8. Implement each section using existing components where possible
  9. Validate responsive behavior against Figma constraints

Result: Complete dashboard matching Figma design with responsive layout.

Best Practices

Always Start with Context

Never implement based on assumptions. Always fetch get_design_context and get_screenshot first.

Incremental Validation

Validate frequently during implementation, not just at the end. This catches issues early.

Document Deviations

If you must deviate from the Figma design (e.g., for accessibility or technical constraints), document why in code comments.

Reuse Over Recreation

Always check for existing components before creating new ones. Consistency across the codebase is more important than exact Figma replication.

Design System First

When in doubt, prefer the project's design system patterns over literal Figma translation.

Common Issues and Solutions

Issue: Figma output is truncated

Cause: The design is too complex or has too many nested layers to return in a single response. Solution: Use get_metadata to get the node structure, then fetch specific nodes individually with get_design_context.

Issue: Design doesn't match after implementation

Cause: Visual discrepancies between the implemented code and the original Figma design. Solution: Compare side-by-side with the screenshot from Step 3. Check spacing, colors, and typography values in the design context data.

Issue: Assets not loading

Cause: The Figma MCP server's assets endpoint is not accessible or the URLs are being modified. Solution: Verify the Figma MCP server's assets endpoint is accessible. The server serves assets at localhost URLs. Use these directly without modification.

Issue: Design token values differ from Figma

Cause: The project's design system tokens have different values than those specified in the Figma design. Solution: When project tokens differ from Figma values, prefer project tokens for consistency but adjust spacing/sizing to maintain visual fidelity.

Understanding Design Implementation

The Figma implementation workflow establishes a reliable process for translating designs to code:

For designers: Confidence that implementations will match their designs with pixel-perfect accuracy. For developers: A structured approach that eliminates guesswork and reduces back-and-forth revisions. For teams: Consistent, high-quality implementations that maintain design system integrity.

By following this workflow, you ensure that every Figma design is implemented with the same level of care and attention to detail.

Additional Resources

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.