mcpField
B
build-figma

build-figma

github.com/cursorデザイン・UI14.5k99 回インストール今日更新
リポジトリ

build-figma について

Figmaのデザインを本番UIに実装するためのオーケストレーションスキルで、リポジトリ内で作業するコーディングエージェントを対象とします。Figmaプラグインと接続済みMCP、cursor-team-kitが必要で、実装の前後にインテークとビジュアル検証のゲートを設けます。

主な機能

  1. 01FigmaのファイルIDとノードIDを解析
  2. 02デザインコンテキストとスクリーンショットを取得
  3. 03ノードをリポジトリのコンポーネントに対応付け
  4. 04対象UIのスタイリングシステムを使用
  5. 05Figmaを基準に実際のUIを検証
  6. 06証拠と未解決の差異を報告

活用シーン

  1. 01既存リポジトリでのFigmaデザイン実装
  2. 02デザイントークンとコンポーネント対応の確認
  3. 03実際のUIとFigmaのスクリーンショットの比較
  4. 04ビジュアル検証の阻害要因の追跡

MCP 対応

Figmaプラグインと接続済みMCPを使って、デザインコンテキスト、スクリーンショット、アセットURLを取得します。これらを本番UIの実装に反映します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/cursor/plugins --skill build-figma

インストール後、Claude Code で/build-figmaを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
design-system-discovery.md
failure-lessons.md
visual-judge.md

詳細

Figma の構築

Figma から本番 UI へのオーケストレーターです。以下のスキルを置き換えるものではありません。各フェーズの開始時にそれぞれを読み、この文書で説明を繰り返さないでください。

必要なものは figma（プラグインと接続済み MCP）および cursor-team-kit です。まず ../dyl-mode/references/requirements.md で確認してください。不足している場合 → 停止し、/add-plugin <name> を実行するようユーザーに伝えてください。

ゲートの条件を形作った失敗例：references/failure-lessons.md。

委譲先（内容をコピーしない）

フェーズ参照先
Figma MCP の仕組みget_design_context を呼び出す前に、Figma プラグインの figma-design-to-code
デザインシステムの調査references/design-system-discovery.md、次に、そこで見つかったリポジトリ固有のデザインシステムスキルまたはルール
ビジュアルに関する主張／判定形式cursor-team-kit の verify-this と references/visual-judge.md
ライブ UI の操作cursor-team-kit の control-ui、または対象画面に対応するリポジトリ独自の操作スキル

ゲート

Build-figma progress:
- [ ] 0. Parse fileKey + nodeId (refuse file-only URLs)
- [ ] 1. Intake done before any product UI edit (see below)
- [ ] 2. Mapped to the repo's primitives/tokens only
- [ ] 3. Styling in the surface's own styling system
- [ ] 4. Visual judge VERIFIED per visual-judge.md (verify-this claim shape)

ゲート 1 はコーディングをブロックします。「まず機能を実装し、見た目の仕上げは後で行う」ことが、主な失敗パターンです。

ワークフロー（概要）

0. URL を解析する

figma.com/design/:fileKey/...?node-id=1-2 → fileKey、nodeId（1-2 → 1:2）。ブランチ URL では branchKey を fileKey として使用します。node-id がない場合 → 停止します。

1. 受け入れ（ブロッキング）

figma-design-to-code に従います。get_design_context と get_screenshot を呼び出します。応答が情報不足、または大きすぎる場合は、実装可能な子ノードに分割します。MCP URL からブランドアセットをダウンロードし、ロゴを描き直してはいけません。

デザインシステムの調査を実施します。その後、/tmp/build-figma/<slug>/intake.md を作成します。

  • 対象画面、コードパス、およびライブ環境での操作方法。
  • ノードツリー。
  • メトリクステーブル。 Figma の px をトークンに対応付けます。一致するトークンがない場合は、値を固定します。
  • ノード → プリミティブの対応表。 各 Figma ノードを既存のコンポーネントに対応付けます。一致するものがないノードは新規として、その理由を記します。
2. 実装

対象画面のスタイルシステムと、対応付けたコンポーネントを使用します。Figma の px がプリミティブの既定サイズと一致しない場合は、そのスタイルシステム内で Figma のメトリクスを固定します。プリミティブの既定値を全体的に変更してはいけません。以下のハード禁止事項を守ってください。

3. ビジュアル判定（ブロッキング）

references/visual-judge.md を使って verify-this を特化させます。Figma の画像をベースライン、ライブ環境のキャプチャを処置後として扱います。まずテーマの明暗を一致させ、その後、評価基準を適用して判定を記録します。NOT VERIFIED の後は、不合格になった項目を修正し、再キャプチャして、評価基準をもう一度適用します。VERIFIED または INCONCLUSIVE になるまで繰り返します。INCONCLUSIVE になった場合は、ブロッカーを報告して停止します。ゲート 4 が完了したと主張してはいけません。

4. 報告

受け入れファイルのパス、対応付けの要点、判定と証拠のパス、残っている課題。

ハード禁止事項

  1. Figma MCP の Tailwind／React をプロダクトコードとして貼り付ける。
  2. Figma またはリポジトリにブランドアセットがあるのに、独自に作成する。
  3. Figma の異なる構造に「十分近い」プリミティブを使用する。
  4. Figma の px を確認せず、テキスト、ボタン、ダイアログのサイズトークンを信頼する。
  5. 判定を行わずに、ビジュアルの作業が完了したと主張する。
  6. intake.md が存在する前に、プロダクト UI を編集する。

コメント

Markdown 対応