如何把一套 Figma 工作流移植成一个 Open Design 插件

一套 Figma 工作流通常起步于肌肉记忆：导出这些 frame、同步那些 token、重建那个 deck 模板、把规范交给工程。这是那种活在某个人脑子里、每次新项目开始时都要重新讲一遍的工作。

0.8.0-preview 讨论提出了一个更锋利的要求：把那份肌肉记忆移植成一个插件。不是一个螺栓拧在画布上的面板。不是一个只有一个团队能跑的私有脚本。而是一套可复用的 Open Design 工作流，让 agent 能像处理任何其他设计任务一样，通过同一个本地优先的循环把它拿起、执行、审查并交接出去。

这是 0.8.0-preview 插件征集的实操版。如果你的团队今天有一套可重复的设计工作流，这篇文章会展示把它变成一个插件形态的贡献是什么样子——它需要哪些文件、agent 如何把它拿起、以及它发布后落在哪里。

值得移植的那套工作流比你想的要小

别从「取代 Figma」开始。从一个烦人的、可重复的小活开始。

好的第一个插件候选：

现有工作流	插件形态的版本
导出一个 Figma 营销页并用代码把它重建出来	`figma-migration` 插件，提取布局、映射 token，并生成一个 web 产物
每个月把一个品牌套件变成发布幻灯片	一个带 `SKILL.md`、示例资源和锁定设计系统的 deck 插件
为每个客户做同样的移动端引导原型	一个移动端屏幕插件，带受众、语气、功能清单和平台的输入字段
把一份组件规范转换成 Storybook 就绪的 UI	一个代码迁移插件，读取仓库、映射组件，并写出一份可审查的 diff

单位不是整个设计部门。单位是某个人已经每周重复两次的一套工作流。如果你没法用一句话把它说清——「把 X 变成 Y，带着这些约束」——那它多半是两个插件、而不是一个，你应该在动手写一行 Markdown 之前就把它拆开。

这正是为什么 Open Design 的 skill 层在这里很重要。一个插件不是一个不透明的运行时扩展。它是一个装着文件的文件夹：一份 SKILL.md 契约、可选的设计系统、可选的示例，以及一个 open-design.json 伴随文件，告诉 Open Design 如何展示并应用这套工作流。你和规则之间没有二进制格式，这意味着任何人都能读这个插件、fork 它，或日后修它。

一个设计 frame 正从画布上被提取出来、放进一个可移植的模块盒子里，在近白色的编辑风底纹上被绿色框选中 — 移植一套工作流，意味着把可重复的那部分从画布里抬出来、放进一个可移植的插件里。

Open Design 的切入点是可移植性

插件规范把契约讲得很直白：SKILL.md 始终是那份可执行的 agent 契约，而 open-design.json 则添上了 marketplace 元数据、输入字段、默认值、预览和上下文接线。

这给了一套工作流两条命。在 Open Design 里，它表现为一个插件，带着预览、输入、来源出处和一键「使用」的路径。在 Claude Code、Cursor、Codex、Gemini CLI、OpenClaw 或另一个 skill 目录里，同一个文件夹仍然作为一个普通的 agent skill 起作用，因为核心行为活在 Markdown 里。你不是在为一个明年就会被弃用的运行时写东西；你是在写一个文件，两年后 agent 读它的方式还是一模一样。

库的走读已经解释了基础原语：skill、system、adapter 和 daemon。插件在这些原语周围添上了分发与可重复性——它们是一个团队交付、审查并复用的单位，而不是 agent 碰巧在磁盘上发现的那个原始 skill。

对于一套 Figma 到代码的工作流，各个面通常长这样：

面	具体文件
agent 行为	`SKILL.md`
Open Design 元数据	`open-design.json`
品牌或视觉契约	`design-systems/{brand}/DESIGN.md`
示例输出	插件文件夹里的 `example.html` 或 `examples/{plugin-id}/example.html`
预览媒体	插件文件夹里的 `preview/poster.png` 或 `preview/index.html`

结果不是一个截图生成器。它是一套可复用的 agent 工作流，带着一份可见的契约——agent 遵循的每一条规则都摆在那个文件夹里，人类可以读、可以改。

一条具体的移植路径

这里是把一套 Figma 落地页工作流移植成一个插件的最小路径。整件事六步，其中大部分都是 Markdown。

1. 给那个可重复的活起个名字

写下描述这个活的那一句话：「把一个 Figma 营销 frame 变成一个响应式 Astro 页面，用自家品牌系统，审查就绪。」如果你没法把它塞进一句话，就收窄它直到能塞进去为止。这个名字会成为你的插件 id（figma-workflow）以及在 marketplace 里展示的标题。

2. 写 skill 契约

SKILL.md 是 agent 读取的那份可执行契约。front matter 命名 skill 及其触发条件；正文是 brief——输入形态、输出路径、约束，以及一份 agent 在交接前应当自查的审查清单。

---
name: figma-workflow
description: Turn one Figma marketing frame into a responsive Astro page in the house brand system.
trigger: When the user provides a Figma frame URL, screenshot, or exported assets for a marketing page.
---

## Input
- A Figma frame URL, a screenshot, or a folder of exported assets.
- The target brand system (defaults to `house`).

## Output
- An Astro page at `src/pages/<slug>.astro`, plus extracted tokens.

## Constraints
- Map Figma styles to the brand system's tokens. Do not invent colors or type.
- Preserve section order and copy. Flag any text that does not fit the grid.
- Mobile-first: every section must reflow at 360px before desktop.

## Review checklist
- [ ] Section IDs match the source frame.
- [ ] No raw hex values — tokens only.
- [ ] Responsive behavior verified at 360 / 768 / 1280.

3. 添上 Open Design 伴随文件

open-design.json 是把一个裸 skill 变成一个 marketplace 插件的东西：标题、描述、声明的输入、预览和来源仓库。这就是驱动「使用」面板和来源出处那一行的元数据。

{
  "id": "figma-workflow",
  "title": "Figma workflow",
  "description": "Port one Figma marketing frame into a responsive Astro page.",
  "inputs": [
    { "key": "figmaSource", "label": "Figma URL or screenshot", "type": "string", "required": true },
    { "key": "brand", "label": "Brand system", "type": "string", "default": "house" }
  ],
  "preview": "preview/poster.png",
  "source": "https://github.com/your-org/your-plugins"
}

4. 挂上设计系统

如果这套工作流依赖品牌规则，就在 design-systems/ 下添一个 DESIGN.md 文件，而不是把颜色和排版埋在散文里。agent 把这套系统当作一份契约来吸收——OKLch 调色板、字号阶梯、版式 posture——这样十个生成出来的屏幕仍然感觉像同一个产品。在项目进行中混搭多个系统也行，因为它们不过是文本。

5. 放进一个真实的示例

在 examples/ 下存一个生成出来的产物，这样审查者能评判输出、而不只是评判承诺。一个已知良好的 example.html 胜过一整段描述；它给了 agent 可以拿来做模式匹配的东西，也给了维护者可以批准的东西。

拼到一起，这个插件就是一个单一的、可读的文件夹：

plugins/community/figma-workflow/
  SKILL.md              # the agent contract: trigger, output, constraints, review
  open-design.json      # marketplace metadata: title, inputs, preview, source
  design-systems/
    house/
      DESIGN.md         # the brand contract the agent must respect
  examples/
    figma-workflow/
      example.html      # one known-good artifact reviewers can judge
  preview/
    poster.png          # marketplace preview media

6. 校验并打包

在开 PR 之前先跑插件命令。当前的 CLI 路径使用小写的插件 id。在 scaffold 时避免用斜杠分隔的注册表名；od plugin scaffold 创建的是 <out>/<id>/...，所以后续命令都指向那个生成出来的文件夹：

od plugin scaffold --id figma-workflow --title "Figma workflow" --out ./plugins/community
od plugin validate ./plugins/community/figma-workflow --no-daemon
od plugin pack ./plugins/community/figma-workflow

当插件准备好接受注册表审查时，用 od plugin login 和 od plugin whoami --json 通过 GitHub 认证，然后按当前审查路径的发布文档操作。Open Design 不存储你的 GitHub 凭证。

在一个真实的设计团队里这是什么样子

想象一个小产品团队，有一个发布页的 Figma frame、一套自家品牌系统，以及每月一次的发布节奏。

在有这个插件之前，工作流是一条交接链：设计师导出 frame，工程师重建布局，PM 重写文案，有人检查 token 漂移，另一个人立 bug。这活很熟悉，但记忆活在人身上——而每当有人请假、换团队，或忘了那条关键的约束时，它就会泄漏。

在有这个插件之后，工作流变成了一个可运行的产物：

步骤	由谁来主导
选择插件	设计师或 PM
挂上 Figma URL / 截图 / 本地资源	设计师
挑选品牌系统	设计师或设计工程师
生成 web 产物	Claude Code、Cursor、Codex、Gemini CLI，或另一个被检测到的 agent
审查 section ID、文案、密度和响应式行为	在 Open Design 预览里的人类
导出或交接文件	同一个本地项目文件夹

团队仍然需要审美——审查这一步正是它的所在，没有任何插件能取代它。插件移除的是「重新讲一遍」：约束、token 映射和输出路径不再是部落知识，而成了仓库里的一个文件。

接下来该做什么

如果你的团队有一套老是回头找你的 Figma 导出、token 同步、品牌套件或 deck 模板，先把最小的那块可重复切片移植过来。从一个 SKILL.md 起步，添上 open-design.json，挂上品牌的 DESIGN.md，放进一个真实的示例，校验它，然后在这套工作流长成一个谁也没法复用的私有工具之前就开 PR。截图到原型的示例端到端地展示了插件形态的版本：一个可移植的 skill 加上一个 Open Design 伴随文件。

试试这套工作流。