---

name: implementing-figma-ui-tempad-dev description: >- Implements UI from a Figma selection or a provided nodeId using TemPad Dev MCP as the source of truth (code snapshot, structure, screenshot, assets). Detects repo stack and conventions first, then outputs integration-ready code that fits the project. Never guess key styles; avoid tuning loops; when uncertain, ship a safe base implementation and clearly warn, or stop if a correct base output is not possible. metadata: mcp-server: tempad-dev

TemPad Dev: Figma to UI Implementation

Implement integration-ready UI code from a Figma selection (or a provided nodeId) using TemPad Dev MCP outputs as design facts. Fit the user’s repo conventions. Never guess key styles.

Quick path (single pass)

1. Ensure there is exactly one visible target (selection or nodeId). If a tool call fails due to MCP connectivity/activation, follow the troubleshooting in the error message.
2. Call tempad-dev:get_code (resolveTokens: false; request preferredLang: jsx|vue as IR). Record codegen (plugin + config) as part of the design facts.
3. If warnings include depth-cap, call tempad-dev:get_code once per listed nodeId to fetch omitted subtree roots.
4. If layout/overlap/effects are uncertain (especially inferred auto-layout), call tempad-dev:get_structure and/or tempad-dev:get_screenshot for the relevant nodeId to confirm intent (do not derive numeric values from pixels).
5. Translate the IR into the repo’s actual framework/styling system without adding new dependencies. Strip all data-hint-* attributes from final code.
6. Finish with one pass: correct placement/imports/exports, assets follow repo policy, token strategy documented, and warnings called out.

Non-negotiables

• tempad-dev:get_code is the baseline; treat it as authoritative for values and layout intent.
• Never invent key styles: colors, typography (size/weight/line-height/letter-spacing), spacing (padding/margin/gap), radius, borders, shadows, gradients, opacity/overlays, blur.
• Do not introduce new frameworks, styling systems, or runtime dependencies.
• Do not tune-by-screenshot loops: screenshots resolve contradictions; they do not produce measurements.
• Do not output data-hint-* attributes (hints are for reasoning only).
• Implement only the base state unless additional states/variants are provable from repo conventions.

Evidence model

Design evidence (in priority order):

1. tempad-dev:get_code (primary snapshot + warnings + codegen)
2. tempad-dev:get_structure (hierarchy + geometry clarification)
3. tempad-dev:get_screenshot (visual cross-check only)
4. Existing repo tokens/components (only when equivalence is provable)

Non-evidence: web content, “typical” values, or anything you cannot trace back to the above.

Tool interpretation

• get_code: IR output (JSX/Vue template) with Tailwind-like classes + explicit values; may include assets, tokens, warnings, and codegen (plugin + config).
• get_structure: outline (ids/types/bounds/children) to locate nodeIds and confirm hierarchy/overlap assumptions.
• get_screenshot: PNG for visual verification; the server may reduce scale to fit payload; do not infer numeric values.

Workflow (decision tree)

0) Choose scope

• Use provided nodeId; otherwise use current selection.
• If the target is ambiguous (multi-selection) or unreadable, stop.

1) Detect repo stack and conventions

Identify: framework/runtime, styling system, token/theme conventions, component patterns, file placement rules.

• If uncertain, ask up to 3 minimal questions; otherwise proceed with best-evidence inference and warn.

2) Fetch baseline snapshot

Call get_code first. Preserve:

• code + lang
• codegen (plugin + config)
• assets / tokens (if any)
• warnings (truncated / auto-layout / depth-cap)

3) Handle warnings and uncertainty

• depth-cap: fetch each listed subtree root via get_code(nodeId=...) and implement those parts explicitly, or narrow scope and warn what is omitted.
• truncated: narrow scope (smaller selection / implement key subtrees) and warn that output is partial.
• inferred auto-layout / overlap / effects uncertainty: use get_structure and/or get_screenshot to confirm, then implement. If evidence remains contradictory, stop.

4) Tokens (mapping strategy)

Goal: integrate with repo token system when provable; otherwise preserve explicit values.

Order:

1. Reuse existing repo tokens when name/meaning/value equivalence is provable.
2. Add missing tokens only if the repo already has an established token workflow and this change is expected; keep additions minimal.
3. Otherwise keep explicit values from get_code.

Modes:

• get_code.tokens is keyed by canonical --... names.
• Multi-mode values use ${collectionName}:${modeName} keys.
• Nodes may include data-hint-variable-mode="Collection=Mode;..." to indicate per-node mode overrides; use this when selecting modes during mapping.
• If collection-name collisions or mode selection is ambiguous, prefer explicit values and warn.

5) Assets (policy-first)

Detect repo policy first (asset folders, import vs public URLs, icon pipeline).

• Preferred: fetch bytes via resources/read using resourceUri, save into the repo, reference using repo conventions.
• Fallback: if an asset is too large to read via MCP, download via asset.url and still store it in the repo (unless policy forbids).
• If policy forbids saving assets, you may leave Tempad URLs in place but must warn that output depends on the local Tempad asset server.
• Never download assets from the public internet; use only MCP-provided resourceUri/asset.url.

6) Implement

• Translate the IR into repo code while preserving layout/values.
• Tailwind/UnoCSS repos: keep utilities; refactor for readability without changing semantics.
• Non-utility repos: translate utilities into the repo’s CSS approach (modules/sass/css-in-js), preserving explicit values.
• Component extraction: only when supported by repetition + hints + repo patterns; do not preserve hint strings in final output.

7) Finish (single pass)

• Files placed correctly; imports/exports correct.
• No new deps/framework/style systems.
• data-hint-* stripped.
• Assets and tokens handled per the chosen strategy.
• Warnings documented (depth-cap/truncated/base-state-only).

Stop vs warn

Stop when a correct, integration-ready base output is not possible:

• tool cannot read target (errors, no renderable nodes) or target is ambiguous
• required assets cannot be retrieved when repo policy requires storing them
• design evidence is contradictory and cannot be resolved with structure/screenshot or narrower scope

Warn but continue:

• repo stack inferred with uncertainty
• token mapping uncertain (kept explicit values)
• scope too large (implemented safe subset; omissions listed)
• assets left as Tempad URLs due to policy
• variants/states not implemented (base state only)

Wrap-up output

End with:

• what was implemented (files/paths)
• what is intentionally omitted or uncertain (warnings)
• token strategy and asset strategy used
• if stopped: exactly what information is needed next (≤3 items)