TemPad Dev: Figma to UI implementation

This skill requires TemPad Dev MCP. If tempad-dev:* tools are unavailable/inactive/unauthorized, stop and tell the user to install TemPad Dev MCP and ensure it is activated in the TemPad Dev panel in the Figma design file.

TemPad Dev outputs Tailwind-like IR in either JSX or Vue. Treat MCP outputs as design facts. Never guess key styles.

Evidence rules

Priority order:

1. tempad-dev:get_code (authoritative: explicit values, layout intent, warnings, assets, tokens, codegen, lang)
2. tempad-dev:get_structure (hierarchy, overlap, bounds clarification)
3. tempad-dev:get_screenshot (visual cross-check only; never for measurement)

Never invent: colors, typography (size/weight/line-height/letter-spacing), spacing, radius, borders, shadows, gradients, opacity/overlays, blur.

Do not output data-hint-* attributes.

Workflow

1) Detect repo conventions

From the repo (do not assume), identify what is needed to integrate cleanly:

• Framework/runtime and file conventions (React/Vue, TS/JS, SFC conventions, naming)
• Styling integration rules (utility allowed? class sorting? linting? extraction patterns?)
• Token/theme system (CSS variables, token files, naming, dark mode/modes)
• Asset policy (public folder vs imports, icon pipeline, hashing, directory rules)
• Existing primitives/components (buttons, inputs, typography, layout wrappers), import path conventions

Only if the repo actually uses Tailwind (or Tailwind-compat tooling), also detect Tailwind version and conventions that affect class syntax/formatting.

If uncertain, ask up to 3 minimal questions; otherwise proceed and warn where inferred.

2) Fetch baseline design snapshot

Call tempad-dev:get_code with:

• resolveTokens: false
• pass nodeId only if user provided one; otherwise rely on the tool’s default behavior (current selection)
• preferredLang: choose what matches the repo (jsx or vue)

Important: get_code.lang is the language actually used by MCP after considering TemPad Dev plugin/config priority. A plugin may override preferredLang. Use returned lang plus codegen facts to interpret the IR correctly, then translate to the repo’s required output.

Record as design facts:

• code, lang
• warnings
• assets (if present)
• tokens (if present)
• codegen (e.g. scale, length units, rootRem, and other normalization settings)

3) Resolve warnings and uncertainty

If warnings indicate missing/partial/uncertain evidence, act immediately:

• depth-cap: call get_code once per listed subtree root nodeId and stitch results, OR narrow scope and list omitted parts.
• truncated: narrow scope (smaller selection or key subtrees) and warn output is partial.
• Layout/overlap/effects uncertainty: call get_structure and/or get_screenshot to resolve contradictions.
  • Screenshots only confirm interpretation, never derive numeric values.
  • If contradictions remain after structure/screenshot (or cannot be narrowed), stop.

4) Assets handling (only if assets exists)

Follow repo asset policy first:

• Preferred: fetch bytes via MCP resources/read using resourceUri, save into repo at policy-correct path, reference with repo conventions.
• Fallback: if MCP cannot read due to size limits, use TemPad-provided asset.url to download and still store in repo (unless policy forbids).
• If policy forbids storing assets, you may reference TemPad URLs but must warn output depends on the local TemPad asset server.

Never download assets from the public internet. Only MCP-provided resourceUri or TemPad-provided asset.url.

5) Tokens mapping (only if tokens exists)

Token evidence shape:

• tokens is a record keyed by canonical CSS variable names (e.g. --...).
• Each token’s value is either a string or a record keyed by Collection:Mode strings whose values are strings.
• Any value string may reference other variables; preserve references.

Mapping goal: integrate with repo tokens when safe; otherwise keep explicit values from get_code.

Rules:

1. Prefer existing repo tokens when you can justify equivalence using value equivalence (including references) plus semantic alignment in the repo.
   Token naming can be supporting evidence, but do not map solely because names look similar.
2. Add new tokens only if the repo already has an established token workflow and this change is expected.
3. If mode selection or mapping remains ambiguous, keep explicit values and warn.

Hints may be used only for reasoning about mode selection when present; never output hint attributes.

6) Implement repo-native code

Translate TemPad Dev IR into the repo’s conventions:

• Utility-first repo (Tailwind/UnoCSS): keep utility classes; adjust ordering/formatting to match repo rules. If Tailwind is used, respect the repo’s Tailwind version/config before changing class syntax.
• Non-utility repo: translate utilities into the repo’s styling approach (CSS Modules/scoped CSS/Sass/CSS-in-JS) while preserving explicit values.

Constraints:

• Do not introduce new frameworks or styling systems.
• New runtime/build dependencies require user confirmation unless the user explicitly says no confirmation is needed.
• Implement base state only unless variants/states are provable from repo conventions or evidence.

Component extraction and primitives:

• Extract only when repetition + repo patterns justify it.
• Prefer existing repo primitives/components when they match intended semantics and do not require guessing styles.

7) Semantics and accessibility minimums

Only apply when the IR would otherwise require plain container semantics (e.g. clickable div) and you are not already using an appropriate repo primitive/component:

• Use native elements where appropriate (button, a, input/label).
• Ensure keyboard interaction and focusability.
• Add accessible names when needed (aria-label, alt).

Assume the repo’s existing CSS reset/normalize. Do not add new reset libraries or global CSS unless the repo already has a defined pattern for it.

8) Exit and wrap-up

Stop (do not ship code) when:

• TemPad Dev MCP is unavailable/unauthorized, or target cannot be read
• Evidence is contradictory and cannot be resolved via structure/screenshot or narrower scope
• Required assets cannot be retrieved/stored under repo policy

Otherwise, ship the best-evidence base implementation and end with:

• Evidence caveats: any warnings, omissions, or inferred repo conventions
• Assets: stored vs TemPad URLs, and any policy-driven constraints
• Tokens: mapped vs explicit values, and any ambiguity
• Dependencies: whether any were added (and whether user confirmation was obtained)
• If stopped: next required info (max 3 items)