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 b