figma-pixel-implement

Figma Pixel Implement

Figma ノードから、エクスポート元に忠実なアセット、画面 × 状態の一覧、および figma-pixel-verify が照合できる、対象リポジトリ内の継続的に更新される仕様書を含めて、UI を対象のコードベースに実装します。

完了の境界： このスキルは「実装済み＋測定可能な契約」（コード＋Inventory、Spec、Assets セクションのファイルパス）までを担当します。セッション内だけの表は完了とはみなされません。実装された表示グラフィックに対する Assets の行が不足している場合、実装は未完了です。プロジェクトにコンポーネントワークベンチがある場合は、対象範囲の一覧（状態 × コンテキスト）をストーリーで網羅することも、実装完了の条件です（ワークフロー 9）。ピクセルの調整は figma-pixel-verify が担当し、この実行はその工程まで続きます。ユーザーに提示する結果は、そのスキル全体の PASS です。反復作業はこの実行内で行います。

このスキルはプラットフォームに依存しません（Claude Code／Cursor／OpenCode／その他）。特定の Agent のスキル ID ではなく、Figma のデザインコンテキスト機能が必要です。

ビジュアルの信頼できる情報源： 指定された Figma ノードです。現在のノードと矛盾するウォークスルーや QA のメモは、メモ／残課題として記録し、expected の代わりにはしません。

前提条件

1. Figma のデザインコンテキストが利用可能であること（必須条件） — Agent がノードの構造化されたデザインペイロード（デザインコンテキスト、メタデータ、スクリーンショット、環境に応じたアセットのエクスポート）を取得できることを確認します。この経路がない場合や認証に失敗した場合は、中止し、ユーザーの Agent で Figma MCP／プラグイン／同等の機能を有効にする方法を伝えます。唯一の選択肢として、固定されたインストール手順をでっち上げてはいけません。URL だけを根拠に UI をでっち上げてはいけません。
2. 任意：プラットフォーム固有の Figma→コードのガイダンス — この Agent に公式の Figma デザイン→コード用スキルまたはガイド（名称は製品によって異なります。Cursor プラグインの例は figma-design-to-code）が付属している場合は、利用可能であれば読み込み、URL の解析／Code Connect／適用ルールに従います。指定されたスキルが見つからなくてもブロッカーではありません。Figma MCP（または同等の機能）と、このスキルの忠実度ルールを使って続行します。Claude Code、OpenCode、その他の Agent で Cursor 専用のスキル ID を必須にしてはいけません。
3. Figma URL またはノード — figma.com のデザイン／make URL、または明示的な fileKey ＋ nodeId を優先します。不足している場合は、確認の質問を一度だけ行い、明確化質問のルールに従います。

ワークフロー（順序どおり）

1. 対象を解析する — fileKey / nodeId を抽出します（node-id=1-2 は 1:2 に変換）。仕様表用にフレーム名を記録します。
2. デザインのコンテキストを取得する — 前提条件の手順の後に、環境のデザインコンテキストツールを呼び出します。出力はそのまま貼り付けられる最終コードではなく、適応するための参考資料として扱います。
3. 大きなフレーム — ペイロードが途中で切れている場合、またはフレームが明らかに複数セクションで構成されている場合は、まずメタデータ／構造を取得してから、表示されている子セクションをすべて取得して実装します。表示されている各セクションを実装するたびに、そのセクションのインベントリと仕様の行を作成中の成果物に追記します。取得していない表示セクションがある場合、実装は未完了です。推測した固定値より、変数／トークンを優先します。デザイン用チャンネルでレート制限に達した場合は一時停止し、未完了のセクションを報告します。
4. 画面 × 状態のインベントリ — 仕様表の前に、デザインに基づく画面／セクション × 視覚状態を列挙します（コンポーネントのバリアント名、外観に関わるプロトタイプの反応、読み取れる注釈／コメント／適応メモ）。default / hover / pressed / disabled / selected など、文書化された状態はインベントリ項目にします。読み取れるメモは、内容に応じて blocked、視覚状態、または out-of-scope: behavior のインベントリ行にします。算出スタイルの行に該当しないプロトタイプや製品の動作（ウィンドウのドラッグ、自動追従スクロール、マウスホイールによるページ送りなど）は、out-of-scope: behavior としてリストに残します。デザインに Hover（または同等の）バリアントがない場合は no-variant-in-design と記録します。メモからホバー色やサイズを推測してはいけません。メモが名前付きノードの構造化された値と矛盾する場合は、ノードの値を expected に保持し、矛盾を記録します。コンポーネントのホストコンテナーが変化する可能性がある場合（幅の変更、狭い幅への圧縮）は、インベントリに context 軸を追加します。製品の幅の下限、プリセットのチェックポイント、圧縮時の負荷をインベントリ行または任意の context 列に記録します。
5. テーマ構造を検出する — デザインでテーマがどのように表現されているかを確認します。複数モードを持つ変数コレクション（例：light／dark）か、テーマ別のフレーム／バリアントかを判定します。ファイルに複数モードがある場合、またはプロジェクトがすでにテーマを切り替えている場合（data-theme、トークンファイル、prefers-color-scheme）、テーマはスコープ内です。テーマのインベントリ（モード名またはテーマ別フレームの nodeId）を記録します。ファイルにもプロジェクトにも第 2 のテーマがない場合は、指定されたフレーム／バリアントを対象にします。
6. 作成中の仕様を構築する — 対象リポジトリ内の永続的なパスを決定します。プロジェクトに既存の Figma ドキュメント用ディレクトリがある場合は、そこを優先します。ない場合は docs/figma/<safe-frame-name>.md にします。その中に Inventory、Spec、および必須のAssetsサブセクションを作成します（Verify は figma-pixel-verify 用に空のままにします）。インベントリの後に、測定可能な行を記述します。取得したノードツリーから機械的にすべて展開し、サンプリングはしません。取得した表示ノードごとに、位置（親またはセクションからの相対 x/y）とサイズの行を作成します。テキストノードごとに、完全なタイポグラフィ一式（font-size、weight、line-height、color、alignment）と、複数行の場合は行数も記録します。コンテナーごとに、padding、gap、radius、shadow、および各子要素のフレーム原点からの累積絶対オフセットも記録します。兄弟要素間の間隔は、関係を示す basis を付けて記録します。取得したノードは、仕様の行でカバーするか、理由を添えて out-of-scope として記載します。何も記載せず省略すると、仕様は未完了です。最低限必要な列は node / role、state、property、expected（Figma の正確な値）、unit、basis（値の基準となる親または兄弟要素）、token / class in repo、source（variable、MCP field、metadata、または Code Connect component）、primitive（project-component | custom-layout | platform-control）です。**塗りの帰属：**ノードに読み取り可能な塗りがない場合、周囲の色のスクリーンショットを塗りの根拠にせず、Spec の expected は transparent / none にします。**テキストの色：**テキストノード独自の読み取り可能な Figma 変数を token / source として使用します。ない場合は raw-only と記録します。スクリーンショットは視覚的な参考資料にすぎず、数値の唯一の根拠にはなりません。テーマがスコープ内の場合、テーマで変化するプロパティには mode 列（またはモードごとの行）を追加し、デザイン自体から各モードの値を特定します（チャンネルが公開する場合は変数の valuesByMode、それ以外はファイル／フレームのモードを切り替えて再取得するか、テーマ別フレームから取得します）。共通の値は 1 行にまとめます。セッションノートは下書きにすぎません。Assets を含むファイルが存在するまで、実装は未完了です。**参照用エクスポート：**スコープ内のすべてのフレームについて、デザインソースからラスター画像をエクスポートし、対象リポジトリに保存します。成果物にはノード ID、ローカルパス、エクスポート倍率を記録します。figma-pixel-verify はこれらを差分スイープのベースラインとして使います。スコープ内のフレームに参照用エクスポートがない場合、実装は未完了です。テンプレート：reference.md。
7. プロジェクトに対応付ける — 既存のコンポーネント、トークン、レイアウトプリミティブを再利用します。プロジェクトにデザインシステム変数がある場合は、ハードコード値より優先します。トークンに結び付いていない個別値には印を付けます。忠実度を保つためにハードコードが必要な場合は、期待値を仕様表に記録します。**レイアウトで測定可能なコントロール：**ノードに明示的な幅と高さが指定されている場合、出荷時に画面が使用する親コンテナー内のレイアウト後に残るコントロールが、そのボックスに一致する必要があります。親なしでコントロールをレイアウトするプローブは該当しません。レイアウト後のサイズが一致するプロジェクトコンポーネントを優先します。標準のプラットフォームコントロールがすべて異なるサイズにレイアウトされる場合は、カスタムコントロールを作成し、そのレイアウトパスでトラック、つまみ、ラベルのフレームを割り当てます（primitive: custom-layout）。platform-control が有効なのは、標準インスタンスのレイアウトプローブが仕様のボックスに一致した場合のみです。ペイロードがフラット化されていて外側のボックスしかわからない場合も、その外側のボックスを一致するプロジェクトコンポーネントまたは custom-layout に対応付けます。内部サイズは、構造化された子ノードの取得結果、またはデザインノードを参照する既存の仕様行から得ます。
8. Assets（必須ルール） — 許可／禁止リストについては reference.md を参照してください。実際の画像／SVG バイト列をプロジェクト（または承認済みの動的ソース）にエクスポートします。表示されている各アイコン／ロゴは、葉パスを重ねるのではなく、外側のインスタンスから 1 ファイルとして切り出します。汎用の 16／20／24 の枠ではなく、そのインスタンスの幅、高さ、オフセットを再現します。そのインスタンスの読み取り可能な階層から、重なりや浮動レイヤーを復元します。デザインで引き伸ばしが必要な場合を除き、SVG のアスペクト比を維持します。<img>／フレームワークの画像機能／エクスポートを保持する SVG を使います。手書きのパスのプレースホルダー、CSS の mask / mask-image と fill／currentColor による再着色、ライト用エクスポートしかない場合にテーマ用マスクを推測して作ることは禁止です（2 つ目のエクスポートを優先するか、保留として記録します）。テーマがスコープ内の場合は、各モードまたはテーマ別フレームから、デザインで提供されるアセットをテーマごとにエクスポートします。一方のテーマのエクスポートを使い、再着色を独自に作ることも禁止です。スコープ内のすべてのグラフィックについて、ノード、ローカルパス、形式を Assets サブセクションに記録します。
9. ストーリーとコンポーネントテスト — 対象プロジェクトに Storybook または同様のコンポーネントワークベンチ（既存のストーリー設定、ワークベンチ構成、またはスクリプト）がある場合、スコープ内の Inventory 行（状態 × コンテキスト）をすべて網羅するストーリーを作成します。それぞれの状態は、後で Agent が操作できる宣言的なエントリ（テスト ID、ノブ、自動アクションなど）で公開し、プロジェクト既存のストーリー規約に従います。作成中の成果物に Stories サブセクションを追加し、ストーリー → 対応するインベントリ行 → エントリを対応付けます（テンプレート：reference.md）。テスト環境がある場合は、主要な Spec 値（ジオメトリ、色、トークンの対応付け）を固定するコンポーネントテストを作成します。テスト環境がない場合は、足場を追加せず、提案を記録します（助言であり、ブロッキング要件ではありません）。コンポーネントワークベンチがない場合は、導入提案を一度だけ記録します（独立していて、観測可能で、エージェントがテスト可能なサーフェス）。測定には figma-pixel-verify のチャンネルラダーを使用します。
10. テーマの対応付け — 指定されたフレーム／バリアントの色に忠実なデザインを維持します。テーマがスコープ内の場合、テーマごとにハードコードしたリテラルを複製するのではなく、テーマで変化する変数をプロジェクトのテーマ機構（CSS カスタムプロパティ／デザイントークン／data-theme または prefers-color-scheme による切り替え）に対応付けます。
11. 引き継ぐ — 作成中の成果物のパスを提示します（Inventory + Spec + Assets があり、ワークベンチがある場合は Stories も含みます）。同じ実行内で figma-pixel-verify を読み込み、その手順に従います。PASS 以外の行がある場合は、そのスキルで修正し、ユーザーに結果を見せる前に再測定します。ユーザー向けの結果は、総合 PASS、または実行できなかった測定コマンドを明記した FAIL です。パスがない場合、実装は未完了です。

ツールの意図（プラットフォームに依存しない）

目標を説明し、使用するネイティブツールはエージェントに選ばせます。

意図	エージェントが実現する方法の例
構造化されたデザインペイロード	Figma MCP のデザインコンテキスト／メタデータツール
ビジュアルリファレンス	スクリーンショットまたはキャンバスのキャプチャツール
アセットのダウンロード	MCP のアセットダウンロードまたはエクスポート API
コード／継続的に更新される仕様の編集	ネイティブの編集／書き込みツール（仕様ファイルは対象リポジトリ内にあります）

指定された MCP サーバー ID や CLI だけを唯一の手段として必須にしないでください。

他のスキルとの関係

機能	境界
エージェントネイティブな Figma→コードのガイダンス（任意、名称は異なる場合があります）	利用できる場合は MCP の衛生管理のために読み込みます。特定の製品のスキル ID を必須の依存関係にしないでください
Figma MCP／デザインコンテキストツール	構造化データの取得に必須です
figma-pixel-verify	測定に基づく合否判定を担当します。同じ成果物（または仕様ソースの兄弟ファイル）の Verify セクションに記録します
ホストの PDCA ワークフロー	永続的な保存先がない場合、実装は未完了です。Verify セクションがない場合、その検証ステージは不合格です
design-approval-gate	ホストワークフローにおける実装前の承認を担当します。独立した機能です

注意点

• Cursor 専用のスキル名を、すべてのエージェントで必須として扱う。
• MCP が生成したコードを、プロジェクトへの適用なしに最終版として扱う。
• figma-pixel-verify を使わずに「ピクセルパーフェクト」と主張する。
• Figma がフラットなアセットとしてエクスポートしたアイコンに、CSS のマスクによる色の変更を使う。
• 仕様テーブルを省略し、検証可能な項目をなくす。
• セッション内だけのテーブルを、実装完了（永続的な保存先なし）として扱う。
• 大きなフレームの外枠だけをサンプリングして、実装完了とする。
• デザインにないホバー時やダークテーマの値を作り出す。
• テーマが対象範囲に含まれる場合：要求されたテーマだけを実装し、他のテーマの値やアセットをデザインから特定せず、独自に作成する。
• デザイン上の関係が「兄弟要素 X までの距離」である場合に、ノード自体のパディングを expected として使う。
• out-of-scope: behavior の項目について、ピクセル検証の合格を主張する。
• ノードに判読可能な塗りがないのに、スクリーンショットでは塗られているように見えるという理由で、単色の塗りを適用する。
• アイコンをリーフパスの断片や汎用的な 16／24 ラッパーから再構成する。
• 判読可能な Figma のテキスト変数を、独自に作成したセマンティックエイリアスに置き換える。
• Assets サブセクションがない状態で、実装完了とする。
• コンポーネントワークベンチがあっても、ストーリーが対象範囲内のインベントリ行を網羅していない状態で、実装完了と宣言する。
• 仕様テーブルの expected ではなく、チャットやウォークスルーのメモにある数値を基にストーリー／テストを作成する。
• 取得したすべてのノードを機械的に展開せず、「主要な値」だけを仕様テーブルに抜き出す。行がない項目は後続工程で測定できません（未知の未知）。
• フレームごとの参照エクスポートなしで引き継ぐ。差分チェックにベースラインがありません。