/figma-design-to-code

name: figma-design-to-code
description: >-
  Implement or update project-consistent UI code from a Figma selection or
  nodeId using TemPad Dev MCP. Use when the user wants visible Figma UI
  recreated, ported, or integrated into the target project's framework,
  styling system, tokens, and existing components when available. Do not use
  for design critique, product invention, generic code review, or for guessing
  hidden states, responsiveness, or behavior not shown in design or project
  evidence.
metadata:
  version: '4.3'

TemPad Dev: Figma Design to Code

Use this skill to turn TemPad Dev design evidence into project-consistent UI code.

TemPad Dev MCP must be available and able to provide trustworthy design evidence for the current selection or provided `nodeId`. If not, stop and tell the user to enable or reconnect TemPad Dev MCP.

Within this skill, TemPad Dev MCP is the authoritative source of design evidence. Treat:

• project files and project instructions as implementation truth when available
• TemPad Dev output as design truth
• the user as the source of truth for missing product or implementation

decisions

Do not infer project conventions before reading local evidence.

For concerns orthogonal to Figma-to-code translation, follow project instruction files such as `AGENTS.md` and other project instructions instead of defining new policy in this skill. If such a concern is unspecified there and would materially change the implementation, ask the user or stop.

Evidence model

Use three evidence channels for different jobs:

• **Project evidence**: `AGENTS.md` or equivalent project instruction files,

design-system docs, token/theme docs, component docs, existing primitives, nearby implementations, framework/styling config, asset rules, and project scripts

• **Design evidence**: `tempad-dev:get_code` first for markup, styles, tokens,

assets, warnings, and codegen facts; `tempad-dev:get_structure` only for hierarchy, geometry, overlap, and retry targeting

• **User input**: missing behavioral intent, responsive intent, target file,

acceptable tradeoffs, asset or dependency decisions, or other product or implementation decisions that cannot be recovered from project or design evidence

What TemPad Dev can and cannot prove

TemPad Dev can prove:

• the visible structure of the current selection or a provided `nodeId`
• explicit layout, spacing, typography, color, radius, borders, shadows,

gradients, masks, filters, compositing, and other rendered visual details

• token references and values when present
• exported assets and whether an SVG may safely adopt one contextual color

channel via `themeable`

• codegen facts such as actual output language, `cssUnit`, `scale`, and

`rootFontSize`

TemPad Dev cannot prove:

• hidden, hover, active, loading, error, empty, disabled, or responsive states

unless separately evidenced

• non-visual product requirements such as behavior, business logic, validation,

navigation, or analytics

• project conventions, file placement, component boundaries, primitive-reuse

policy, token-mapping policy, or asset workflow beyond what the project already establishes

• missing style truth from `get_structure`; it is only a structure aid

Default operating rules

Do not output `data-hint-*` attributes.

Never invent visual details or behavior not evidenced, including color, typography, spacing, radius, borders, shadows, gradients, opacity, overlays, blur, hidden states, responsive behavior, interactions, or asset semantics.

Treat advanced or uncommon style output from TemPad Dev as intentional unless project constraints force an adaptation.

Only ask the user when the answer would materially change the implementation and cannot be established from project or design evidence. Typical blockers:

• more than one plausible target file or component boundary
• more than one plausible existing primitive or abstraction to reuse
• missing behavior, state, or responsive intent
• asset, dependency, or token workflow requiring a product decision

If a gap is minor and non-blocking, proceed with a clearly stated inference.

Prefer the **smallest safe change**. Do not perform unrelated refactors or add new abstractions unless project patterns clearly call for them.

Do not enter open-ended visual tuning loops without new evidence. If remaining differences cannot be proved from project or design evidence, warn clearly and stop or hand off for user validation.

Workflow

1. Read local evidence first

Read local evidence before implementing. Prioritize, in order:

1. `AGENTS.md` or equivalent project instruction files 2. relevant design-system, token, and component docs 3. existing primitives/components and nearby implementations 4. config files and scripts that constrain output

Establish at least:

• framework/runtime and file conventions
• styling rules, including whether utilities are used and how classes are

ordered or formatted

• token/theme system and mode handling
• asset and icon pipeline
• reusable primitives/components, file placement, and import path conventions
• the narrowest established project checks for this change, if any

Only if the project actually uses Tailwind or Tailwind-compatible tooling, detect Tailwind version and config before changing class syntax or ordering.

For Tailwind projects, also inspect the local theme scales relevant to exact- value mapping, especially spacing, sizing, radius, and typography.

If a material implementation constraint is still missing after local evidence, ask the user instead of inferring it.

2. Fetch the top-level design snapshot

Call `tempad-dev:get_code` first.

Use these defaults:

• `resolveTokens: false`
• pass `nodeId` only when the user provided one; otherwise use the current

selection

• set `preferredLang` to match the project target, such as `jsx` or `vue`

Use TemPad's default vector behavior unless the user explicitly asks for asset-preservin