implementing-figma-ui-tempad-dev

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

TemPad Dev: Figma to UI Implementation

TemPad Dev：从Figma到UI实现

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.

本技能需要TemPad Dev MCP。如果

tempad-dev:*

工具不可用/未激活/未授权，请停止操作并告知用户安装TemPad Dev MCP，确保其在Figma设计文件的TemPad Dev面板中已激活。

TemPad Dev会输出类Tailwind的JSX或Vue中间表示（IR）。请将MCP输出视为设计事实，绝不猜测关键样式。

Evidence rules

证据规则

Priority order:

```
tempad-dev:get_code
```
(authoritative: explicit values, layout intent, warnings, assets, tokens, codegen, lang)
```
tempad-dev:get_structure
```
(hierarchy, overlap, bounds clarification)
```
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.

优先级顺序：

```
tempad-dev:get_code
```
（权威来源：明确值、布局意图、警告、资源、令牌、代码生成、语言）
```
tempad-dev:get_structure
```
（层级、重叠、边界说明）
```
tempad-dev:get_screenshot
```
（仅用于视觉交叉验证；绝不用于尺寸测量）

绝不要自行编造：颜色、排版（字号/字重/行高/字符间距）、间距、圆角、边框、阴影、渐变、透明度/遮罩、模糊效果。

不要输出

data-hint-*

属性。

Workflow

工作流程

1) Detect repo conventions

1) 检测仓库约定

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.

从仓库中（不要假设）识别干净集成所需的内容：

框架/运行时与文件约定（React/Vue、TS/JS、SFC约定、命名规则）
样式集成规则（是否允许使用工具类？类排序？代码检查？提取模式？）
令牌/主题系统（CSS variables、令牌文件、命名规则、深色模式/多模式）
资源政策（公共文件夹vs导入、图标流水线、哈希处理、目录规则）
现有基元/组件（按钮、输入框、排版、布局包装器）、导入路径约定

仅当仓库实际使用Tailwind（或兼容Tailwind的工具）时，才检测影响类语法/格式的Tailwind版本和约定。

如有不确定，最多提出3个最精简的问题；否则继续操作，并在推断的地方给出警告。

2) Fetch baseline design snapshot

2) 获取基线设计快照

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)

调用

tempad-dev:get_code

时需包含：

```
resolveTokens: false
```
仅当用户提供了
```
nodeId
```
时才传入该参数；否则依赖工具的默认行为（当前选中内容）
```
preferredLang
```
：选择与仓库匹配的语言（jsx或vue）

重要提示：

get_code.lang

是MCP在考虑TemPad Dev插件/配置优先级后实际使用的语言。插件可能会覆盖

preferredLang

。请使用返回的

lang

和

codegen

事实正确解读IR，然后转换为仓库所需的输出格式。

记录以下设计事实：

```
code
```
、
```
lang
```
```
warnings
```
```
assets
```
（如果存在）
```
tokens
```
（如果存在）
```
codegen
```
（例如缩放比例、长度单位、rootRem及其他规范化设置）

3) Resolve warnings and uncertainty

3) 解决警告与不确定性

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.

如果警告表明证据缺失/不完整/不确定，请立即采取行动：

```
depth-cap
```
：对列出的每个子树根节点
```
nodeId
```
调用一次
```
get_code
```
并拼接结果，或者缩小范围并列出遗漏的部分。
```
truncated
```
：缩小范围（更小的选中内容或关键子树）并警告输出内容不完整。
布局/重叠/效果不确定性：调用
```
get_structure
```
和/或
```
get_screenshot
```
解决矛盾。
- 截图仅用于确认解读，绝不用于推导数值。
- 如果在调用结构/截图接口后矛盾仍未解决（或无法缩小范围），则停止操作。

4) Assets handling (only if

assets

exists)

4) 资源处理（仅当

assets

存在时）

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

首先遵循仓库的资源政策：

首选方式：通过MCP的
```
resources/read
```
接口使用
```
resourceUri
```
获取字节数据，按照政策要求的路径保存到仓库中，并按照仓库约定引用。
备选方式：如果MCP因大小限制无法读取，使用TemPad提供的
```
asset.url
```
下载资源并仍存储到仓库中（除非政策禁止）。
如果政策禁止存储资源，可引用TemPad的URL，但必须警告输出内容依赖本地TemPad资源服务器。

绝不要从公共互联网下载资源。仅可使用MCP提供的

resourceUri

或TemPad提供的

asset.url

。

5) Tokens mapping (only if

tokens

exists)

5) 令牌映射（仅当

tokens

存在时）

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:

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.
Add new tokens only if the repo already has an established token workflow and this change is expected.
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.

令牌证据的结构：

```
tokens
```
是一个以标准CSS变量名称（例如
```
--...
```
）为键的记录。
每个令牌的值要么是字符串，要么是以
```
Collection:Mode
```
字符串为键的记录，其值为字符串。
任何值字符串都可能引用其他变量；请保留这些引用。

映射目标：在安全的情况下与仓库令牌集成；否则保留

get_code

返回的明确值。

规则：

当你可以通过值等价性（包括引用）加上仓库中的语义对齐来证明等价时，优先使用现有仓库令牌。令牌命名可作为辅助证据，但绝不要仅因为名称相似就进行映射。
仅当仓库已有成熟的令牌工作流且此更改符合预期时，才添加新令牌。
如果模式选择或映射仍不明确，请保留明确值并给出警告。

仅当提示存在时，才可将其用于模式选择的推理；绝不要输出提示属性。

6) Implement repo-native code

6) 实现仓库原生代码

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.

将TemPad Dev IR转换为仓库约定的格式：

工具优先的仓库（Tailwind/UnoCSS）：保留工具类；调整排序/格式以匹配仓库规则。如果使用Tailwind，在更改类语法前需遵循仓库的Tailwind版本/配置。
非工具类仓库：将工具类转换为仓库的样式方案（CSS Modules/作用域CSS/Sass/CSS-in-JS），同时保留明确值。

约束条件：

不要引入新的框架或样式系统。
新的运行时/构建依赖需要用户确认，除非用户明确表示无需确认。
仅实现基础状态，除非变体/状态可通过仓库约定或证据证明。

组件提取与基元：

仅当存在重复且符合仓库模式时才进行提取。
当现有仓库基元/组件匹配预期语义且无需猜测样式时，优先使用它们。

7) Semantics and accessibility minimums

7) 语义化与可访问性最低要求

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.

仅当IR原本需要使用普通容器语义（例如可点击的

div

）且你尚未使用合适的仓库基元/组件时，才应用以下要求：

适当使用原生元素（
```
button
```
、
```
a
```
、
```
input/label
```
）。
确保键盘交互和可聚焦性。
在需要时添加可访问名称（
```
aria-label
```
、
```
alt
```
）。

假设仓库已存在CSS重置/规范化样式。除非仓库已有明确的模式，否则不要添加新的重置库或全局CSS。

8) Exit and wrap-up

8) 退出与收尾

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)

在以下情况时停止操作（不要交付代码）：

TemPad Dev MCP不可用/未授权，或无法读取目标内容
证据矛盾且无法通过结构/截图或缩小范围解决
所需资源无法按照仓库政策获取/存储

否则，交付基于最佳证据的基础实现，并在结尾说明：

证据警告：所有
```
warnings
```
、遗漏内容或推断的仓库约定
资源：已存储vs TemPad URL，以及任何政策驱动的约束
令牌：已映射vs明确值，以及任何不明确之处
依赖：是否添加了任何依赖（以及是否获得了用户确认）
如果已停止操作：下一步所需的信息（最多3项）

implementing-figma-ui-tempad-dev

Original

Translation

TemPad Dev: Figma to UI Implementation

TemPad Dev：从Figma到UI实现

Evidence rules

证据规则

Workflow

工作流程

1) Detect repo conventions

1) 检测仓库约定

2) Fetch baseline design snapshot

2) 获取基线设计快照

3) Resolve warnings and uncertainty

3) 解决警告与不确定性

4) Assets handling (only if
`assets`
exists)

4) 资源处理（仅当
`assets`
存在时）

5) Tokens mapping (only if
`tokens`
exists)

5) 令牌映射（仅当
`tokens`
存在时）

6) Implement repo-native code

6) 实现仓库原生代码

7) Semantics and accessibility minimums

7) 语义化与可访问性最低要求

8) Exit and wrap-up

8) 退出与收尾

implementing-figma-ui-tempad-dev

Original

Translation

TemPad Dev: Figma to UI Implementation

TemPad Dev：从Figma到UI实现

Evidence rules

证据规则

Workflow

工作流程

1) Detect repo conventions

1) 检测仓库约定

2) Fetch baseline design snapshot

2) 获取基线设计快照

3) Resolve warnings and uncertainty

3) 解决警告与不确定性

4) Assets handling (only if assets exists)

4) 资源处理（仅当assets存在时）

5) Tokens mapping (only if tokens exists)

5) 令牌映射（仅当tokens存在时）

6) Implement repo-native code

6) 实现仓库原生代码

7) Semantics and accessibility minimums

7) 语义化与可访问性最低要求

8) Exit and wrap-up

8) 退出与收尾

4) Assets handling (only if
`assets`
exists)

4) 资源处理（仅当
`assets`
存在时）

5) Tokens mapping (only if
`tokens`
exists)

5) 令牌映射（仅当
`tokens`
存在时）