figma-generative-plugins

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create and update generative Figma plugins

创建和更新生成式 Figma 插件

Load this skill before every

create_generative_plugin

update_generative_plugin

call. In user-facing language, call the result a “plugin.” The “generative” qualifier only distinguishes this account-library tool from other plugin systems.

在每次调用

create_generative_plugin

或

update_generative_plugin

之前加载此 skill。在面向用户的表述中，将结果称为“插件”。“生成式”这一限定词仅用于将这个账户库工具与其他插件系统区分开来。

Preflight

预检查

Before authoring, confirm the request fits this surface:

Plugins run in the Figma Design editor.
Every plugin must provide functional UI for its core workflow. A plugin with no configurable inputs still needs a clear primary action and useful status or validation feedback.
Never embed API keys, OAuth tokens, signed URLs, or other secrets. Plugin source is readable by people who can access it. For authenticated integrations, stop and offer a static dataset, a public no-auth endpoint, or a different architecture.

开始编写前，确认请求适合此使用场景：

插件在 Figma Design 编辑器中运行。
每个插件都必须为核心工作流提供可用的 UI。即使插件没有可配置输入，也必须提供明确的主要操作，以及有用的状态反馈或验证反馈。
绝不嵌入 API keys、OAuth tokens、signed URLs 或其他 secrets。插件源代码可被有权访问它的人读取。对于需要身份验证的集成，应停止操作，并提供静态数据集、公开且无需身份验证的端点，或采用其他架构。

Create workflow

创建工作流

Resolve the requested workflow and its useful controls. Ask a concise question only if required inputs or behavior are genuinely ambiguous.
Resolve
```
planKey
```
. Reuse one supplied by the user; otherwise call
```
whoami
```
. Use the sole eligible plan automatically, or ask the user to choose when several materially different plans are available.
Call
```
create_generative_plugin
```
once with a concise name, description, and
```
planKey
```
. This creates a runnable square-drawing scaffold, not the requested final plugin.
Call
```
get_generative_plugin
```
with the returned
```
id
```
, then read every source URI. This establishes the scaffold's manifest, UI message contract, and current TypeScript entrypoint.
Replace the scaffold with complete authored files for the requested behavior and UI.
Call
```
update_generative_plugin
```
with the returned
```
id
```
, a
```
files
```
array containing complete replacements for
```
code.ts
```
and, when the UI changes,
```
ui.html
```
, plus a specific
```
commitMessage
```
. Use
```
metadata
```
when changing the name or description.

Never stop after

create_generative_plugin

: the starter must be replaced with the requested experience.

确定所请求的工作流及其有用的控件。只有当必需输入或行为确实存在歧义时，才提出一个简洁的问题。
确定
```
planKey
```
。如果用户提供了一个，则复用；否则调用
```
whoami
```
。如果只有一个符合条件的 plan，则自动使用；如果有多个在实质上不同的 plan，则请用户选择。
使用简洁的名称、描述和
```
planKey
```
，调用一次
```
create_generative_plugin
```
。这会创建一个可运行的绘制方形脚手架，而不是用户所要求的最终插件。
使用返回的
```
id
```
调用
```
get_generative_plugin
```
，然后读取每个源代码 URI。这用于确定脚手架的 manifest、UI 消息契约和当前 TypeScript 入口点。
使用针对所请求行为和 UI 完整编写的文件替换脚手架。
使用返回的
```
id
```
调用
```
update_generative_plugin
```
，传入一个
```
files
```
数组，其中包含
```
code.ts
```
的完整替换内容；当 UI 发生变化时，还应包含
```
ui.html
```
，并提供具体的
```
commitMessage
```
。更改名称或描述时使用
```
metadata
```
。

调用

create_generative_plugin

后绝不能就此停止：必须用所请求的体验替换 starter。

Update workflow

更新工作流

Identify the plugin. If needed, call

list_generative_plugins

, then

get_generative_plugin

Read every source URI returned by the get tool before editing. Treat those files as the current source of truth.
Preserve existing UI, controls, relaunch behavior, validation, and user-visible affordances unless the user asks to change them.
Call
```
update_generative_plugin
```
with complete replacement content for every changed existing file. Use
```
{ path: "code.ts", content: "..." }
```
for the entrypoint and
```
{ path: "ui.html", content: "..." }
```
for the UI. Unspecified files are preserved.

确定要更新的插件。如有需要，先调用
```
list_generative_plugins
```
，然后调用
```
get_generative_plugin
```
。
编辑前，读取 get 工具返回的每个源代码 URI。将这些文件视为当前的事实来源。
除非用户要求更改，否则保留现有的 UI、控件、重新启动行为、验证机制和用户可见功能。
调用
```
update_generative_plugin
```
，为每个发生更改的现有文件提供完整的替换内容。对于入口点使用
```
{ path: "code.ts", content: "..." }
```
，对于 UI 使用
```
{ path: "ui.html", content: "..." }
```
。未指定的文件将保留不变。

Authoring rules

编写规则

Before writing replacement files, read Plugin source authoring. It covers the file replacement contract, UI/message lifecycle, PropsKit controls, dynamic-page compatibility, fonts, relaunch behavior, bounded work, geometry, and Plugin API gotchas.
Keep the plugin’s primary action obvious and make invalid selection or input states understandable.
```
update_generative_plugin
```
can replace existing
```
code.ts
```
and
```
ui.html
```
files, but cannot replace
```
manifest.json
```
or create new files. Keep
```
figma.showUI(__html__, ...)
```
in
```
code.ts
```
and replace
```
ui.html
```
when the requested workflow needs different controls.
Avoid destructive canvas changes unless they are the explicit purpose of the plugin and the UI makes that clear.
Do not close before asynchronous work and UI messages have completed.
Treat a non-error
```
update_generative_plugin
```
result as success. Record the returned version when present; a successful response may omit it.
On a build error, use the returned compiler output to make the smallest source correction and retry once. If it still fails, surface the error instead of repeatedly rewriting the plugin.

写入替换文件前，阅读插件源代码编写。其中涵盖文件替换契约、UI/消息生命周期、PropsKit 控件、动态页面兼容性、字体、重新启动行为、有界工作、几何处理以及 Plugin API 常见问题。
让插件的主要操作保持清晰明确，并确保无效选择或输入状态易于理解。
```
update_generative_plugin
```
可以替换现有的
```
code.ts
```
和
```
ui.html
```
文件，但不能替换
```
manifest.json
```
或创建新文件。在
```
code.ts
```
中保留
```
figma.showUI(__html__, ...)
```
；当所请求的工作流需要不同控件时，替换
```
ui.html
```
。
除非破坏性画布更改是插件的明确用途，并且 UI 已清楚说明，否则应避免此类更改。
在异步工作和 UI 消息处理完成之前，不要关闭插件。
将
```
update_generative_plugin
```
返回的非错误结果视为成功。如果结果中包含版本号，则记录该版本；成功响应可能不包含版本号。
遇到构建错误时，根据返回的编译器输出进行最小幅度的源代码修正，然后重试一次。如果仍然失败，应报告错误，而不是反复重写插件。

Completion

完成

Report the plugin name and id, plus the returned version when present and a short description of its UI and primary action. Construct and include a clickable URL that opens a new Design file with the unpublished plugin ready to try, using the exact plugin id as

try-tool-resource-content-id

https://www.figma.com/file/new?try-tool-resource-content-id=<id>&try-tool-resource-type=gen_tool&type=design&mode=design

After presenting the new-file link, ask whether the user wants to open the plugin in an existing Figma Design file instead. If yes, reuse a file URL already provided or ask for one, then add the same

try-tool-resource-content-id

and

try-tool-resource-type

query parameters to that URL. Never guess the file URL.

报告插件名称和 id，以及返回的版本（如果存在），并简要说明其 UI 和主要操作。构建并提供一个可点击的 URL，该 URL 会打开一个新的 Design 文件，其中已准备好可供试用的未发布插件，并将准确的插件 id 作为

try-tool-resource-content-id

：

https://www.figma.com/file/new?try-tool-resource-content-id=<id>&try-tool-resource-type=gen_tool&type=design&mode=design

呈现新文件链接后，询问用户是否希望改为在现有的 Figma Design 文件中打开该插件。如果用户回答“是”，则复用已提供的文件 URL，或向用户索取一个，然后为该 URL 添加相同的

try-tool-resource-content-id

和

try-tool-resource-type

查询参数。绝不猜测文件 URL。