figma-design-to-code

What this skill does

# 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-preserving vector fidelity and the current MCP version clearly supports
it.

Use `resolveTokens: true` only when the user explicitly does not want
design-token usage.

Treat returned `lang` as authoritative because TemPad Dev plugin or config may
override `preferredLang`.

Record these as design facts:

- `code`
- `lang`
- `warnings`
- `assets`, if present
- `tokens`, if present
- `codegen`

Use `codegen.config.{cssUnit,rootFontSize,scale}` as the authoritative unit
context for exact-value mapping.

Prefer fetching the full requested top-level selection first so parent
composition and containment are not lost.

### 3. Resolve incomplete or conflicting evidence before implementing

If `get_code` warns or fails, narrow uncertainty instead of guessing.

- **`depth-cap`**: keep the returned top-level result as the source of parent
  layout and composition, then use returned `data-hint-id` values to choose
  narrower `get_code` follow-ups for the subtrees you still need.
- **budget overflow or shell response**: keep the returned parent shell as the
  composition source of truth, then fetch omitted child subtrees separately and
  fill them into that known shell. Prefer the smallest parent container that
  still preserves the shared layout for the child subtrees you must assemble.
  Do not treat plain string truncation as usable evidence.
- **layout, hierarchy, or overlap uncertainty**: call
  `tempad-dev:get_structure`, but use it only to resolve hierarchy or geometry,
  or to choose a narrower parent-shell retry target. Do not treat it as
  missing style truth.
- **remaining contradiction**: if project evidence, design evidence, and
  structure evidence still conflict after narrowing, stop.
- **untrustworthy parent recovery**: if you still cannot obtain a trustworthy
  parent shell or parent composition via `get_code`, stop full implementation
  and ask the user to narrow scope or choose the highest-priority subtree.

Retry policy:

- retry once only for transient transport or connectivity failures
- do not blind-retry deterministic issues such as invalid selection, hidden
  node, wrong file, `depth-cap`, budget overflow, or unreadable target; change
  scope or inputs first

If TemPad MCP appears unavailable, inactive, or pointed at the wrong file, stop
and tell the user to:

- enable MCP server in TemPad Dev Preferences
- keep the correct TemPad Dev / Figma tab active
- use the MCP badge in the TemPad Dev panel to activate the correct file if
  multiple Figma tabs are open

If asking the user to narrow scope