figma-generate-library

デザインシステムビルダー — Figma MCP スキル

コードと一致する、プロフェッショナル品質のデザインシステムアセットを Figma で構築します。ワークフローの規模は、要求された成果物に合わせます。トークンセット、1 つのコンポーネント、完全なライブラリ、または対象を絞った調整から選択します。選択した手順は、整合性があり、安全に再試行できる構築フェーズに分けて実行し、根拠に基づいて検証します。

前提条件：use_figma を呼び出すたびに、figma-use スキルも必ず読み込んでください。このスキルでは、Plugin API の構文規則（戻り値のパターン、ページのリセット、ID の返却、フォントの読み込み、カラーの範囲）を扱います。このスキルでは、デザインシステムのドメイン知識とワークフローのオーケストレーションを扱います。

**このスキルの一部として use_figma を呼び出す場合、カンマ区切りの skillNames パラメーターには必ず figma-generate-library を含めてください。このスキルが MCP リソース経由で読み込まれた場合は、名前の先頭に resource: を付ける必要があります（例：resource:figma-generate-library）。**これはログ用のパラメーターであり、実行には影響しません。

---

1. スコープと完了条件

最初の変更を行う前に、ユーザーの依頼から主要なスコープを 1 つ選び、対象となる成果物と受け入れ基準を記録します。範囲の狭い依頼を、黙ってライブラリ全体のプロジェクトへ拡大してはいけません。

依頼されたスコープ	必須の作業	依頼または必要性がない限り対象外
トークン／基盤のみ	依頼された変数、モード、スコープ、コード構文、スタイル、および依頼されたサンプルシート	コンポーネント、コンポーネントページ、Code Connect、ライブラリ全体のナビゲーション
単一のコンポーネントまたはファミリー	互換性のある基盤を調査して再利用し、コンポーネントに必要な不足トークンのみを作成し、依頼されたバリアント／プロパティ／バインディングを構築して、コンポーネントを検証する	関連のない基盤、その他のコンポーネント、ファイル全体の骨組み、広範なドキュメントや監査
ライブラリ全体／デザインシステム	調査、基盤、ファイル構成、依頼されたコンポーネント一覧、ドキュメント、統合、最終 QA	合意済みの v1 対象範囲外の作業
調整／更新	コードと Figma の差分を確認し、影響を受けるトークン、スタイル、コンポーネント、ドキュメント、依存項目のみを更新する	有効なアセットの再構築、またはライブラリの拡張

状況共有は内容に応じた分量にします。変更前にスコープと受け入れ基準を簡潔にまとめたチェックリストを 1 回提示し、重要な節目で進捗を共有し、最後に作成・変更したオブジェクト、検証の根拠、未解決の制約を 1 回にまとめて報告します。変更のないチェックリストを繰り返したり、すべての API 呼び出しを逐一説明したりしないでください。

結果を安全に再試行できるスクリプトであれば、関連する操作をまとめて実行します。ページコンテキストの切り替え時、復旧が難しい変更の前、または実際に失敗した後に対象を絞って再試行する場合は、操作を分割します。検証チェックポイントを作ることだけを目的に、正常に動作する操作を分割してはいけません。変更は順番に実行します。書き込みから返される構造的な証拠（ID と、関連する件数、名前、境界情報）を使用し、証拠がない場合、または後続の変更によって古くなった場合にのみ、独立した監査を実施します。整合性のある構成フェーズごとにビジュアルレビューを 1 回行い、対象を絞ったビジュアル修正を行った場合にのみ、修正後のスクリーンショットを 1 回撮影します。最後に合格したスクリーンショットを最終版とします。

完了の定義

選択したスコープの条件がすべて満たされたら終了します。

• 最終成果物が確定した対象一覧を網羅し、要求されたバリエーション／状態の範囲、必要なアセット、スコープ内のレビュー例を含め、適用される信頼できる情報源に実質的に忠実であること。
• コンポーネントのタスクでは、メインコンポーネントと構築用アセットを最終レビュー用フレームの外に置き、要求された状態を1つのコンパクトなフレーム内にインスタンスとして表示します。終了前に、そのフレームを通常の表示倍率で確認し、クリップ、欠落、コントラスト不足、空、配置ずれ、分離したコンテンツを修正します。
• 必要な変数スコープ、エイリアス、コード構文、コンポーネントプロパティ、バリエーション、バインディングが検証済みであること。
• 要求された成果物が、適用される構造面および視覚面の検証に合格すること。クリップや切り詰めが意図的でない限り、要求されたコンテンツがすべて表示されていることを確認します。不具合を修正し、影響を受けた出力のみを再確認します。
• 信頼できる情報源に必要なアセットがある場合はプレースホルダーを置き換え、一時的なインスタンス、テスト用フレーム、キャプチャ、未使用の成果物、無関係な孤立ノードを削除します。
• 合意した受け入れ確認の合格を妨げる既知の不具合や未解決の判断事項がないこと。スコープ外の制約は報告し、追加作業は開始しません。

追加のドキュメント、コンポーネント、Code Connect マッピング、アクセシビリティの一斉点検、推測に基づく監査は、選択したスコープで必要とされない限り、後続作業です。完了の定義を満たしたら終了します。

スコープの変更

ユーザーが成果物を変更した場合は、スコープと受け入れチェックリストを更新します。検証済みの作業は維持し、新たに適用される手順のみを実行します。選択されていない作業経路の作業を遡って追加しないでください。

---

2. スコープ別ワークフロー

すべてのスコープで、まず対象を絞った調査を行います。関連コードを分析し、対象となる Figma アセットと規約を確認し、search_design_system の前に get_libraries を呼び出し、変更を加える前にコードと Figma の不一致を解決します。互いに独立した検索はまとめて実行し、結果を再利用します。要求された対象一覧を確定したら、以下の該当する経路のみを実行します。

トークン／基盤

1. 要求されたコレクション、モード、プリミティブ、セマンティックエイリアス、スコープ、コード構文を作成または更新します。
2. 要求されたテキストスタイルとエフェクトスタイルを作成します。
3. 要求された場合にのみ、見本またはドキュメント用ページを作成します。
4. 数、モード値、エイリアス、スコープ、構文、スタイル、および要求された視覚的成果物を検証して終了します。

単一コンポーネントまたはファミリー

1. 互換性のあるローカルまたはライブラリの変数、テキストスタイル、エフェクトスタイルを調査して再利用します。コンポーネントに必要な基盤のうち、不足しているもののみを作成します。ソースで定義された役割、ライブラリ標準の役割、または繰り返し使用されるコンポーネントの役割については、共有テキストスタイルまたはエフェクトスタイルを作成または再利用し、該当するすべてのコンポーネントノードに適用します。単発のドキュメント内のスタイルはインラインのままにします。
2. 要求された基本コンポーネント、バリエーション、プロパティ、バインディング、依存コンポーネントを構築します。
3. ファイルの規約に合う場合、または要求にドキュメント付きのショーケースが必要な場合は、専用ページを使用します。それ以外の場合は、既存のコンポーネント領域に配置します。
4. バリエーション数、プロパティ、変数バインディング、代表的なノードに適用されたテキスト／エフェクトスタイルの ID、構造、外観を検証して終了します。

ライブラリ全体／デザインシステム

1. 調査： トークンとコンポーネントの対象一覧を確定し、ギャップ分析を出力します。
2. 基盤： コレクション、変数、エイリアス、スコープ、コード構文、スタイルを作成します。
3. ファイル構成： 合意したカバー、導入、基盤、コンポーネント、ユーティリティの各ページに加え、要求されたドキュメントを作成します。
4. コンポーネント： プロパティ、バインディング、ドキュメント、検証を含め、依存関係の順に合意した対象一覧を構築します。
5. 統合と QA： 合意したコンポーネント対象一覧について Code Connect マッピングを完了し、アクセシビリティ、命名、バインディングを監査して、合意したすべてのページを視覚的に検証します。

照合／更新

1. 既存のアセットを棚卸しし、現在のコードソースとの正確な差分を特定します。
2. 影響を受けるアセットをその場で更新し、可能な限り有効な名前、ID、バインディング、ライブラリ構造を維持します。
3. 変更したアセットと、既知の依存先を検証したら終了します。

必須の受け入れチェックに失敗した場合は、続行する前に対象範囲内の不具合を修正してください。偽のアセット、近似したタイポグラフィ、壊れたインタラクション、未検証の状態で代用しないでください。

このスキルで選択したワークフロー、検索頻度、検証ルール、完了の定義は、参照資料にあるより広範な指示、チェックリスト、例より優先されます。選択した経路に必要な参照資料だけを読み込んでください。

---

3. 重要なルール

Plugin API の基本（use_figma スキルより — ここでも適用されます）：

• データを返すには return を使用します（自動シリアライズされます）。IIFE でラップしたり、closePlugin を呼び出したりしないでください。
• すべての return 値に、作成または変更したノード ID をすべて含めてください。
• ページコンテキストは呼び出しごとにリセットされます。各スクリプトの開始時に、必ず await figma.setCurrentPageAsync(page) を実行してください。スクリプトごとに呼び出せるのは最大 1 回です。各コンポーネントまたはドキュメントページは、それぞれ独立した use_figma 呼び出しにしてください。変更を行うスクリプト内で figma.root.children をループしてページを切り替えないでください。その作業は対象ページごとに 1 回の集中的な呼び出しに分割してください（figma-use → gotchas.md → use_figma 呼び出しごとに現在のページを一度だけ設定 — 複数ページにまたがる作業は呼び出しごとに分割 を参照）。
• figma.notify() はエラーを発生させます。決して使用しないでください。
• 色の値は 0～255 ではなく、0～1 の範囲です。
• テキストを書き込む前に、必ずフォントを読み込む必要があります：await figma.loadFontAsync({family, style})。利用可能なフォントを確認し、正確なスタイル文字列を検証するには、await figma.listAvailableFontsAsync() を使用してください。読み込みに失敗した場合は、利用可能なフォントを照会して正しい名前または代替フォントを見つけてください。 デザインシステムのルール：

1. 依存するコンポーネントより基盤を先に整える — 互換性のある既存の変数やスタイルを再利用します。コンポーネントの構築に必要な基盤が不足している場合は、先に作成してください。有効な基盤を作り直してはいけません。
2. 作成する前に調査する — 読み取り専用の use_figma を実行して、既存の規約を確認します。それに合わせてください。
3. ファイル内のコンポーネント構成に合わせる — 完全なライブラリでは通常、コンポーネントごとにページを作成します。密接に関連するファミリーは、同じページにまとめてもかまいません。単一コンポーネントのタスクでは、ライブラリの骨組みを新たに作成する代わりに、既存のコンポーネント領域を使用してもかまいません。
4. ビジュアルプロパティを変数にバインドする (デフォルト) — 塗り、線、パディング、角丸、間隔が対象です。意図的に固定するジオメトリ（アイコンのピクセルグリッドサイズ、静的な区切り線など）は例外です。以前の use_figma 呼び出しで取得した変数を使用する場合は、バインド前に、その呼び出しで返された実際の Figma 変数 ID を使って新しいハンドルを解決してください。JavaScript の参照は呼び出しをまたいで保持されません。 Plugin API を使用する場合は、バインド前に await figma.variables.getVariableByIdAsync(id) で変数を解決します。
5. すべての変数にスコープを設定する — ALL_SCOPES のままにしてはいけません。背景：FRAME_FILL, SHAPE_FILL。テキスト：TEXT_FILL。境界線：STROKE_COLOR。間隔：GAP。角丸：CORNER_RADIUS。プリミティブ：[]（非表示）。
6. すべての変数にコード構文を設定する — WEB 構文では必ず var() で囲みます。--color-bg-primary ではなく、var(--color-bg-primary) とします。コードベースにある実際の CSS 変数名を使用してください。ANDROID/iOS では囲みません。
7. プリミティブに意味的なエイリアスを設定する — { type: 'VARIABLE_ALIAS', id: primitiveVar.id } を使用します。セマンティックレイヤーで生の値を複製してはいけません。
8. combineAsVariants の後にバリアントを配置する — バリアントは (0,0) に積み重なります。手動でグリッド配置し、サイズを変更してください。
9. アイコンには INSTANCE_SWAP を使用する — アイコンごとにバリアントを作成してはいけません。バリアントの組み合わせ数が「サイズ × スタイル × 状態」で 30 を超える場合は、サブコンポーネントに分割してください。
10. 一貫性のある命名 — 冪等なクリーンアップと再開ができるよう、一貫性のある一意なノード名を使用します。作成したノード ID は戻り値と状態台帳で追跡してください。
11. 破壊的なクリーンアップを行わない — クリーンアップスクリプトでは、推測するのではなく、命名規則または返された ID でノードを特定します。
12. 証拠で検証してから進める — 検証されていない作業を土台にしてはいけません。書き込みで返された構造上の証拠（ID と、関連する数、名前、境界）を根拠にしてください。受け入れ条件の確認に必要な場合、または関連する変更によって以前の証拠が無効になった場合に限り、整合性のある各フェーズで一度だけ構造監査をまとめて実行します。整合性のある各コンポジションフェーズでビジュアルレビューを一度行い、対象を絞ったビジュアル修正を行った後に限り、修正後のスクリーンショットを一度撮影します。
13. use_figma の呼び出しを並列化しない — Figma の状態変更は必ず順番に行います。ツールが並列呼び出しに対応していても、2 つの use_figma 呼び出しを同時に実行してはいけません。
14. Node ID を捏造しない — 必ず、以前の呼び出しで返された状態台帳から ID を読み取ります。記憶を頼りに ID を再構成したり、推測したりしてはいけません。
15. ヘルパースクリプトを使用する — scripts/ のスクリプトを use_figma 呼び出しに埋め込んでください。200 行のインラインスクリプトを一から書いてはいけません。

---

4. 状態管理（長いワークフローでは必須）

Figma オブジェクトにワークフローの状態を保存しないでください。検出には決定論的な名前を使用し、状態台帳には返された正確な ID を記録してください。人が読めるコンポーネントの目的と使用方法のガイダンスは、コンポーネントまたはコンポーネントセットの description に記載してください。

エンティティの種類	安定した識別情報	存在を確認する方法
ページとフレーム	決定論的な名前 + 状態台帳 ID	figma.root.children.find(p => p.name === pageName) または await figma.getNodeByIdAsync(id)
コンポーネントとコンポーネントセット	バリアント／セット名 + 状態台帳 ID	page.findOne(n => n.name === name) または await figma.getNodeByIdAsync(id)
変数	コレクション内の名前	(await figma.variables.getLocalVariablesAsync()).find(v => v.name === name && v.variableCollectionId === collId)
スタイル	名前	getLocalTextStyles().find(s => s.name === name)

作成直後に、返された ID をすべて状態台帳に記録してください。削除の許可判断にあいまい検索を使用しないでください。

状態の永続化：状態台帳を会話のコンテキストだけに頼らせないでください。ディスクに書き込んでください：

/tmp/design-system-state-{RUN_ID}.json

毎ターンの開始時にこのファイルを読み直してください。長いワークフローでは会話のコンテキストが途中で切り詰められるため、このファイルを信頼できる情報源とします。

次の項目を記録する状態台帳を維持してください：

{
  "runId": "ds-build-2024-001",
  "scope": "single-component",
  "step": "component-button",
  "entities": {
    "collections": { "primitives": "id:...", "color": "id:..." },
    "variables": { "color/bg/primary": "id:...", "spacing/sm": "id:..." },
    "pages": { "Cover": "id:...", "Button": "id:..." },
    "components": { "Button": "id:..." }
  },
  "pendingValidations": ["Button:screenshot"],
  "completedSteps": ["discovery", "foundations/verified", "component-button/base"]
}

冪等性チェック：作成する前に毎回、名前と状態台帳 ID で検索してください。存在する場合はスキップするか更新し、重複を作成しないでください。

再開プロトコル：セッション開始時、またはコンテキストが切り詰められた後に、読み取り専用の use_figma を実行し、すべてのページ、コンポーネント、変数、スタイルを名前でスキャンして {key → id} マップを再構築してください。その後、ディスクに保存されている状態ファイルがあれば読み直してください。

継続プロンプト（新しいチャットで再開する際にユーザーに提示してください）：

「デザインシステムの構築を続けています。実行 ID：{RUN_ID}。figma-generate-library スキルを読み込み、最後に完了したステップから再開してください。」

---

5. ライブラリの検出とsearch_design_system — 再利用の判断基準

対象範囲を絞った検出パスで検索し、その結果を再利用します。コンポーネントを作成する前に再検索するのは、元の一覧に含まれていなかった場合、利用可能なライブラリが変わった場合、または以前の検索結果で解決できなかった場合に限ります。

対象ファイルに対してsearch_design_systemを呼び出す前に、必ずそのファイルのget_librariesを呼び出してください。ライブラリが追加されている、または利用可能だと仮定してはいけません。

get_librariesの結果が空でも、検索を省略してよい理由にはなりません。検索範囲を指定するためのライブラリキーがないことを意味するだけです。get_librariesはページネーションを行います（コミュニティのUIキットは最初のページにのみ表示され、組織のライブラリは20件ずつ表示されます）。そのため、一覧が空でもライブラリが存在しない証拠にはなりません。結果に応じて、次のように対応してください。

• ライブラリが返された場合 — includeLibraryKeysを指定して範囲を絞り、search_design_systemを実行します。libraries_available_to_addにあるライブラリはデフォルトでは検索されません。検索対象にするには、そのlibraryKeyを渡してください。
• ライブラリが返されなかった場合 — includeLibraryKeysを省略して、search_design_systemを実行します。省略するとファイル自体が検索範囲となり、検索範囲を指定できるライブラリが見つからなかった場合に適した動作です。

検索自体で結果が空だった場合に限り、ギャップ分析に「利用可能なデザインシステムのアセットなし」と記録し、コードトークンを使って構築できます。get_librariesの呼び出しが失敗した、または呼び出していないことから「ライブラリなし」と推測してはいけません。

// Discover all libraries accessible to the file
get_libraries({ fileKey })
// Returns:
//   libraries_added_to_file: [{ name, libraryKey, description, source }, ...]
//   libraries_available_to_add: [{ name, libraryKey, description, source }, ...]
//   libraries_available_to_add_next_offset: number | null

返されたlibraryKeyの値を使い、includeLibraryKeysで特定のライブラリに検索範囲を絞ってください。利用可能なライブラリが多い場合に、ノイズの多い検索結果を避けられます。

libraries_available_to_add_next_offsetがnullでない場合は、さらに組織のライブラリがあるため、その値をoffsetに設定してget_librariesを再度呼び出してください。組織のライブラリは20件ずつ表示され、コミュニティのUIキットは最初のページにのみ表示されます。

// Search across all libraries (default)
search_design_system({
  queries: [
    { entity: "component", query },
    { entity: "variable", query },
    { entity: "style", query }
  ],
  fileKey
})

// Search within a specific library only
search_design_system({ queries: [{ entity: "component", query }], fileKey, includeLibraryKeys: ["lk-abc123..."] })

次の条件をすべて満たす場合は再利用します。

• コンポーネントのプロパティAPIが要件に合っている（同じバリアント軸で、互換性のある型である）
• トークンのバインドモデルに互換性がある（同じ変数、またはエイリアス可能な変数を使用している）
• 命名規則が対象ファイルと一致している
• コンポーネントを編集できる（所有していないリモートライブラリ内でロックされていない）

次のいずれかに該当する場合は再構築します。

• APIに互換性がない（プロパティ名が異なる、またはバリアントモデルが適切でない）
• トークンモデルに互換性がない（値がハードコードされている、または変数スキーマが異なる）
• 所有権の問題がある（ライブラリを変更できない）

見た目は一致していてもAPIに互換性がない場合は、ラップします。

• ライブラリのコンポーネントを、新しいラッパーコンポーネント内のネストされたインスタンスとしてインポートします
• ラッパーに使いやすいAPIを公開します

優先順位：既存のローカルコンポーネント → 購読中のライブラリからインポート → libraries_available_to_addにある未購読のUIキットライブラリ（特にアイコン） → 新規作成。

---

6. 判断が分かれる場合

選択肢が分かれ、妥当な答えが2つ以上あり、コードベース、Figmaファイル、または確定済みの計画から明確な答えを選べない場合は、ユーザーに確認してください。黙ってデフォルトを選んではいけません。各選択肢とそのトレードオフ、おすすめの案を示し、ユーザーの意向を確認してから選んでください。

確認しなくてよい場合： 信頼できる情報源（コード、Figmaファイル、合意済みの計画）から正しい選択肢が一つに明確に定まる場合は、それを選んでください。このセクションは本当に判断が分かれる場合を対象としており、あらゆる判断をユーザーに委ねるためのものではありません。

判断が分かれる状況	提示する内容	質問の例
トークン、コンポーネント、または値について、コードとFigmaが一致しない	出典（ファイル／行とノード）を添えて、両方の値を並べて示す	「コードでは--color-bg-primary = #FFFFFFですが、Figmaではcolor/bg/primary = #FAFAFAです。どちらを優先しますか？」
購読中のライブラリに、近いが完全には一致しないものがある	ライブラリコンポーネントの概要とギャップの一覧	「ライブラリのButtonにはloading状態がありません。再利用してローカルでラップしますか、それとも一から作り直しますか？」
計画を確定する段階（0d）でスコープが曖昧	明確に対象となるもの、対象外となるもの、曖昧なもの	「仕様にはButtonとInputが記載されていますが、Fieldは参照されているだけで定義されていません。v1の対象に含めますか？」

ユーザーがすでに構築した選択肢を却下した場合： 先に進む前に修正してください。却下された成果物を土台に作業を進めてはいけません。

---

7. 命名規則

既存のファイル規則に合わせてください。新しく始める場合：

変数（スラッシュ区切り）：

color/bg/primary     color/text/secondary    color/border/default
spacing/xs  spacing/sm  spacing/md  spacing/lg  spacing/xl  spacing/2xl
radius/none  radius/sm  radius/md  radius/lg  radius/full
typography/body/font-size    typography/heading/line-height

プリミティブ：blue/50 → blue/900、gray/50 → gray/900

コンポーネント名：Button、Input、Card、Avatar、Badge、Checkbox、Toggle

バリアント名：Property=Value, Property=Value — 例：Size=Medium, Style=Primary, State=Default

ページ区切り：---（最も一般的）または ——— COMPONENTS ———

命名規則の完全なリファレンス：naming-conventions.md

---

8. トークンアーキテクチャ

複雑さ	パターン
50 トークン未満	単一コレクション、2 モード（ライト／ダーク）
50～200 トークン	標準：プリミティブ（1 モード）＋カラーセマンティック（ライト／ダーク）＋スペーシング（1 モード）＋タイポグラフィ（1 モード）
200 トークン以上	アドバンスト：複数のセマンティックコレクション、4～8 モード（ライト／ダーク × コントラスト × ブランド）。token-creation.md の M3 パターンを参照

標準パターン（推奨する開始点）：

Collection: "Primitives"    modes: ["Value"]
  blue/500 = #3B82F6, gray/900 = #111827, ...

Collection: "Color"         modes: ["Light", "Dark"]
  color/bg/primary → Light: alias Primitives/white, Dark: alias Primitives/gray-900
  color/text/primary → Light: alias Primitives/gray-900, Dark: alias Primitives/white

Collection: "Spacing"       modes: ["Value"]
  spacing/xs = 4, spacing/sm = 8, spacing/md = 16, ...

---

9. アンチパターン

調査とスコープ：

• ❌ 既存の規則を無視する、または関連するコード、ファイル、ライブラリの調査を省略する
• ❌ 限定的なリクエストを、無関係な基盤、ドキュメント、またはライブラリ全体にまで拡大する

基盤：

• ❌ ALL_SCOPES を使用する、セマンティックレイヤーでプリミティブ値を重複させる、またはコード構文を省略する
• ❌ 基盤が整う前に依存コンポーネントを作成する

コンポーネント：

• ❌ 互換性のある変数があるのに、コンポーネントの塗り、線、スペーシング、または角丸をハードコードする
• ❌ INSTANCE_SWAP を使わず、アイコンごとにバリアントを作成する
• ❌ combineAsVariants の後、バリアントを (0,0) に積み重ねたままにする
• ❌ 分割せずに、30 を超えるバリアントマトリックスを作成する
• ❌ リモートコンポーネントをインポートして、すぐに切り離す

実行と復旧：

• ❌ キャンバスを読み取る前に、safeToRetryWithoutCanvasRead が false のときに再試行する
• ❌ クリーンアップに名前の接頭辞による照合を使う（ユーザー所有のノードが削除されます）
• ❌ 前のステップの未検証の作業を基に作業を進める
• ❌ use_figma の呼び出しを並列化する（必ず順番に実行してください）
• ❌ ノード ID を記憶から推測、またはでっち上げる（必ず状態台帳から読み取ってください）
• ❌ 提供されているヘルパースクリプトを使わず、膨大なインラインスクリプトを記述する

---

10. リファレンスドキュメント

必要に応じてリファレンスを読み、ファイル名から内容を推測しないでください。

ドキュメント	読み込むタイミング
discovery-phase.md	変更を加える前に関連するコードと Figma アセットを分析するとき
token-creation.md	変数、コレクション、モード、またはスタイルを作成するとき
documentation-creation.md	選択したスコープにカバーまたは基盤のドキュメントが含まれるとき
component-creation.md	コンポーネントまたはバリアントを作成するとき
code-connect-setup.md	選択したスコープに Code Connect または変数のコード構文が含まれるとき
naming-conventions.md	変数、ページ、バリアント、またはスタイルに名前を付けるとき
error-recovery.md	スクリプトが失敗したとき、または中断されたワークフローの状態をクリーンアップする必要があるとき

---

11. スクリプト

再利用可能な Plugin API ヘルパー関数です。use_figma 呼び出しに埋め込んでください。

スクリプト	目的
inspectFileStructure.js	すべてのページ、コンポーネント、変数、スタイルを検出し、全インベントリを返します
createVariableCollection.js	モードを含む名前付きコレクションを作成し、{collectionId, modeIds} を返します
createSemanticTokens.js	トークンマップからエイリアス付きのセマンティック変数を作成します
createComponentWithVariants.js	バリアントマトリックスからコンポーネントセットを構築します。グリッドレイアウトに対応しています
bindVariablesToComponent.js	デザイントークンをコンポーネントのすべての視覚的プロパティにバインドします
createDocumentationPage.js	タイトル、説明、セクション構造を含むページを作成します
validateCreation.js	作成されたノードが想定される数、名前、構造と一致することを検証します
cleanupOrphans.js	状態台帳から指定されたノード、変数、コレクションの ID のみを削除します