ecomfe/figma-design-to-code

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 because of budget overflow, report the current consumption, limit, and overage from the error text.

4. Implement code in the established project style

Translate TemPad Dev output into the implementation's established patterns.

• Reuse existing primitives and abstractions when they fit without guessing.
• Keep the established framework and styling system. Do not introduce a second one.
• Follow established file placement and import conventions.
• If the implementation is utility-first, keep utilities and match existing conventions. Otherwise translate generated utilities into the established styling approach while preserving values.
• Preserve exact values. Do not coarsen arbitrary values such as py-[4px], text-[12px], or font-[600] into named utilities unless local project evidence proves the same rendered value; for rem output, use codegen.config.{cssUnit,rootFontSize,scale} to convert exactly. Apply this to spacing, sizing, inset, gap, radius, font-size, line-height, letter-spacing, and font-weight.
• Implement the base state only unless variants, interactions, or responsive behavior are evidenced.
• Preserve emitted pseudo-elements. If TemPad output includes before:, after:, content-*, or equivalent CSS, keep them or use an established equivalent with the same rendered result.
• Preserve other high-fidelity details from get_code, including pseudo- classes, filters, masks, blend or backdrop effects, and other non-default visual properties, unless implementation constraints require adaptation.
• New runtime or build dependencies require user confirmation unless explicitly waived.
• Extract new abstractions only when repetition plus established patterns justify it.
• If multiple plausible primitives, layout abstractions, or delivery strategies fit and evidence does not decide, ask the user instead of guessing.

Assets

Follow the established asset policy first.

• Download bytes only from TemPad-provided asset.url. Never substitute public internet assets.
• Treat assets as files to save or reference, not as text evidence to parse.
• If policy forbids storing assets, you may reference TemPad URLs, but you must warn that the output depends on the local TemPad asset server.
• If a vector is emitted as <svg data-src="..."> in code, treat that placeholder markup as the current design truth for structure, sizing, and instance color evidence. data-src points at the uploaded SVG asset. Only refactor delivery when the implementation already has another established SVG policy.
• If TemPad falls back to inline SVG because asset upload failed, treat that inline markup as the design truth for that vector instead of re-synthesizing the shape from the asset metadata.
• Do not introduce a new SVG pipeline if one is already established.
• Preserve vector semantics:
  • themeable: true means one context-driven color channel, typically via currentColor
  • drive that color from the established wrapper or component styling rather than inventing a new icon API
  • vectors without themeable: true keep their internal palette
• Use asset.themeable only after accounting for the project's existing SVG delivery policy.
• Do not invent multi-color SVG props or custom CSS variables unless the implementation already has an established icon API that requires them.

Tokens

Preserve design-token usage by default.

Token evidence may be either direct values or mode-specific values keyed by Collection:Mode. Preserve references between variables when present.

• Prefer existing tokens only when equivalence is justified by value, references, and semantics, not by name alone.
• If the implementation can safely carry design-token references for this change, preserve TemPad token references until they are mapped through the normal token workflow.
• Add new tokens only when there is already an established process for doing so and this change is expected to use it.
• If token landing, mode selection, or mapping remains ambiguous or unsupported, use explicit values and warn.
• Hints may be used only for reasoning about mode selection; never output hint attributes.

Semantics and accessibility

When not already using an appropriate primitive or component:

• use native elements where appropriate, such as button, a, input, and label
• preserve keyboard interaction and focusability
• add accessible names when needed, such as aria-label or alt

Assume the existing CSS reset or normalize strategy. Do not add new reset libraries or global CSS unless there is already a defined pattern for it.

5. Project checks and handoff

Project checks are project-defined, not skill-defined.

• Follow project instruction files such as AGENTS.md, local docs, and existing project scripts for any lint, format, typecheck, build, test, preview, screenshot, or design-comparison steps relevant to this change.
• Run the narrowest relevant checks that the project already defines and the current host or client can actually execute.
• If those checks fail, repair obvious implementation issues when feasible and re-run the relevant checks.
• Do not invent a default verification matrix just because this is a Figma-to-code task.
• If no established or runnable check path exists for this change, say the output is unverified.
• If shell recovery or subtree stitching was involved and no existing project check can confirm the resulting layout, explicitly call out the remaining visual risk.
• Do not claim visual or design-complete verification unless the project already has a normal preview, screenshot, or design-comparison workflow. Otherwise ask the user to visually validate the result against Figma.

Stop conditions

Stop instead of shipping code when:

• TemPad Dev MCP is unavailable, unauthorized, disconnected, inactive on the correct file, or otherwise cannot provide trustworthy design evidence
• the target cannot be read or is not visible
• project, design, and user evidence still conflict after narrowing
• a missing user decision would materially change the implementation and cannot be safely inferred
• required implementation constraints are missing and cannot be safely inferred from project or design evidence
• a trustworthy parent composition cannot be recovered after depth-cap, shell response, or budget overflow
• required assets cannot be retrieved or stored under the established policy
• new dependencies would be required and user confirmation has not been obtained

Output contract

When shipping code, end with:

• what was implemented and where
• evidence caveats, warnings, any stated inference, and whether shell recovery or subtree stitching was used
• asset handling, including whether assets were stored locally or still depend on TemPad URLs
• token handling, including mapped tokens, preserved references, or explicit fallback values
• dependency notes, including whether any were added and whether approval was obtained
• project-check status, including commands run if any, what passed or failed, and what remains unverified
• any residual visual risk and the visual confirmation the user should still perform

If blocked, provide at most 3 concrete next items needed from the user.

Examples

Example: over-budget parent with recoverable shell

• get_code returns a parent shell and a shell warning
• keep that shell as the composition source of truth
• fetch missing child subtrees with get_code
• insert them into the known parent structure
• do not rebuild sibling layout from guesswork
• if no trustworthy parent shell can be recovered, stop and ask for a narrower scope instead of reconstructing parent layout from guesses
• report any remaining visual risk if project checks cannot confirm the layout

Example: SVG marked themeable: true

• first check the established icon or SVG delivery policy
• if the implementation already uses contextual icon color, adapt the SVG to one color channel, usually currentColor
• do not invent multi-color props or a custom icon API
• if more than one delivery strategy is plausible and evidence does not decide, ask the user

Example: token mapping is ambiguous

• preserve TemPad token references if the implementation can safely carry them
• map to existing tokens only when value plus semantic equivalence is justified
• if mode selection or landing zone is still unclear, use explicit values and warn instead of inventing a mapping