Figma ワークフローを Open Design プラグインに移植する方法

Figma のワークフローはたいてい筋肉の記憶として始まります：このフレームをエクスポートし、あのトークンを同期し、あのデッキテンプレートを再構築し、仕様をエンジニアリングに渡す。それは誰かの頭の中にあり、新しいプロジェクトが始まるたびに説明し直される類の作業です。

0.8.0-preview のスレッドは、より鋭い問いを投げかけます：その筋肉の記憶をプラグインに移植せよ。キャンバスにボルトで留めたパネルではなく。1 つのチームしか実行できないプライベートなスクリプトでもなく。エージェントが手に取り、実行し、レビューし、他のあらゆるデザインタスクと同じローカルファーストのループを通して引き渡せる、再利用可能な Open Design のワークフローです。

これは 0.8.0-preview のプラグイン募集の実践版です。あなたのチームが今日 1 つの繰り返し可能なデザインワークフローを持っているなら、この記事はそれをプラグイン形のコントリビューションに変えるとはどういうことかを示します ── どんなファイルが必要か、エージェントがどうそれを手に取るか、そして公開されたらどこに着地するか。

移植する価値のあるワークフローは思っているより小さい

「Figma を置き換える」から始めないでください。1 つの面倒で繰り返し可能な仕事から始めてください。

最初のプラグインの良い候補：

現在のワークフロー	プラグイン形のバージョン
Figma のマーケティングページをエクスポートしてコードで再構築する	レイアウトを抽出し、トークンをマッピングし、web 成果物を生成する `figma-migration` プラグイン
毎月ブランドキットをローンチスライドに変える	`SKILL.md`、サンプルアセット、固定されたデザインシステムを持つデッキプラグイン
クライアントごとに同じモバイルオンボーディングのモックアップを作る	オーディエンス、トーン、機能リスト、プラットフォームの入力フィールドを持つモバイル画面プラグイン
コンポーネント仕様を Storybook 対応の UI に変換する	リポジトリを読み、コンポーネントをマッピングし、レビュー可能な差分を書くコード移植プラグイン

単位はデザイン部門全体ではありません。単位は、誰かがすでに週に 2 回繰り返している 1 つのワークフローです。それを 1 文で記述できないなら ── 「これらの制約のもとで X を Y に変える」── おそらく 1 つではなく 2 つのプラグインであり、Markdown を 1 行書く前に分割すべきです。

だからこそ Open Design のスキルレイヤーがここで重要になります。プラグインは不透明なランタイム拡張ではありません。それはファイルのフォルダです：SKILL.md の契約、任意のデザインシステム、任意のサンプル、そして Open Design にワークフローをどう表示し適用するかを伝える open-design.json のサイドカー。あなたとルールの間にバイナリ形式はなく、つまり誰でもプラグインを読み、フォークし、後で修正できるのです。

デザインフレームがキャンバスから抽出され、ポータブルなモジュールボックスに落とし込まれ、ほぼ白の編集的な地の上で緑のフレームに選択されている — ワークフローを移植するとは、繰り返し可能な部分をキャンバスから持ち上げ、ポータブルなプラグインへと入れることです。

Open Design の観点はポータビリティ

プラグイン仕様は契約を率直に述べています：SKILL.md は実行可能なエージェントの契約のままであり、一方 open-design.json はマーケットプレイスのメタデータ、入力フィールド、デフォルト、プレビュー、コンテキストの配線を追加します。

これは 1 つのワークフローに 2 つの命を与えます。Open Design では、プレビュー、入力、来歴、ワンクリックの「使う」経路を持つプラグインとして現れます。Claude Code、Cursor、Codex、Gemini CLI、OpenClaw、あるいは別のスキルカタログでは、コアの振る舞いが Markdown に宿っているため、同じフォルダがプレーンなエージェントスキルとして依然動きます。あなたは来年廃止されるランタイム向けに書いているのではなく、2 年後にエージェントが同じように読むファイルを書いているのです。

ライブラリの解説はすでに基本プリミティブを説明しています：スキル、システム、アダプター、そして daemon。プラグインはそれらのプリミティブの周りに配布と再現性を加えます ── プラグインは、エージェントがたまたまディスク上で発見する素のスキルではなく、チームが出荷し、レビューし、再利用する単位なのです。

Figma からコードへのワークフローでは、サーフェスはたいていこのようになります：

サーフェス	具体的なファイル
エージェントの振る舞い	`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`

結果はスクリーンショットジェネレーターではありません。見える契約を持つ再利用可能なエージェントワークフローです ── エージェントが従うすべてのルールが、人間が読んで編集できるフォルダに座っています。

具体的な移植の道筋

ここに、1 つの Figma ランディングページのワークフローを移植するプラグインのための最小の道筋を示します。全体は 6 ステップで、そのほとんどは Markdown です。

1. 繰り返し可能な仕事を名づける

その仕事を記述する 1 文を書き出します：「1 つの Figma マーケティングフレームを、ハウスブランドシステムでレスポンシブな Astro ページに変え、レビューの準備を整える。」1 文に収まらないなら、収まるまで絞り込んでください。その名前があなたのプラグイン id（figma-workflow）になり、マーケットプレイスに表示されるタイトルになります。

2. スキルの契約を書く

SKILL.md はエージェントが読む実行可能な契約です。front matter はスキルとそのトリガーを名づけ、本文はブリーフです ── 入力の形、出力パス、制約、そしてエージェントが引き渡す前に自己適用すべきレビューチェックリスト。

---
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 は、素のスキルをマーケットプレイスのプラグインに変えるものです：タイトル、説明、宣言された入力、プレビュー、ソースリポジトリ。これが「使う」パネルと来歴の行を駆動するメタデータです。

{
  "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 ファイルを追加します。エージェントはシステムを契約として取り込みます ── OKLch のパレット、タイプランプ、レイアウトの姿勢 ── ので、生成された 10 枚の画面が依然 1 つの製品のように感じられます。プロジェクトの途中でシステムを混ぜるのも、それらが単なるテキストなので、うまくいきます。

5. 実物のサンプルを 1 つ含める

生成された成果物を examples/ の下に保存し、レビュアーが約束ではなく出力を判断できるようにします。1 つの既知の良好な example.html は、段落 1 つ分の説明よりも価値があります。エージェントにパターンマッチする対象を与え、メンテナーに承認する対象を与えるのです。

まとめると、プラグインは 1 つの読みやすいフォルダです：

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 を使います。スキャフォールド時にスラッシュ区切りのレジストリ名は避けてください。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 フレーム、ハウスブランドシステム、そして月次のリリースリズムを持つ小さなプロダクトチームを想像してみてください。

プラグインの前は、ワークフローは引き渡しの連鎖です：デザイナーがフレームをエクスポートし、エンジニアがレイアウトを再構築し、PM がコピーを書き直し、誰かがトークンのずれを確認し、別の誰かがバグをファイルする。作業は馴染みがありますが、記憶は人々の中に宿り ── 誰かが不在になったり、チームを変わったり、重要だったその 1 つの制約を忘れたりするたびに漏れていきます。

プラグインの後は、ワークフローは実行可能な成果物になります：

ステップ	誰が指揮するか
プラグインを選ぶ	デザイナーまたは PM
Figma URL / スクリーンショット / ローカルアセットをアタッチする	デザイナー
ブランドシステムを選ぶ	デザイナーまたはデザインエンジニア
web 成果物を生成する	Claude Code、Cursor、Codex、Gemini CLI、または別の検出されたエージェント
セクション ID、コピー、密度、レスポンシブな振る舞いをレビューする	Open Design のプレビュー内の人間
ファイルをエクスポートまたは引き渡す	同じローカルプロジェクトフォルダ

チームには依然センスが必要です ── レビューのステップがそれが宿る場所であり、どんなプラグインもそれを置き換えません。プラグインが取り除くのは説明し直すことです：制約、トークンマップ、出力パスが、部族の知識であることをやめ、リポジトリの中のファイルになります。

次に何をするか

あなたのチームに、何度も戻ってくる Figma のエクスポート、トークン同期、ブランドキット、デッキテンプレートがあるなら、最も小さい繰り返し可能なスライスから先に移植してください。SKILL.md から始め、open-design.json を追加し、ブランドの DESIGN.md をアタッチし、実物のサンプルを 1 つ入れ、検証し、そしてそのワークフローが他の誰も再利用できないプライベートツールに育つ前に PR を開いてください。スクリーンショットからプロトタイプへのサンプルが、プラグイン形のバージョンを端から端まで示しています：ポータブルなスキルと Open Design のサイドカーです。

このワークフローを試す。