mcpField
F
figma-design-to-code

figma-design-to-code

github.com/ecomfeデザイン・UI642371 回インストール今日更新
リポジトリ

figma-design-to-code について

figma-design-to-codeは、TemPad Dev MCPの根拠を使い、既存プロジェクト内にFigmaデザインを実装するスキルです。プロジェクト固有の規約に従い、根拠のある視覚的な詳細を保ち、裏付けのない状態や動作を作りません。

主な機能

  1. 01TemPad Devでデザイン根拠を取得
  2. 02プロジェクトの指示と規約に準拠
  3. 03根拠のある表示値を維持
  4. 04適切な既存コンポーネントを再利用
  5. 05根拠のない状態や動作を追加しない
  6. 06プロジェクト指定のチェックを実行

活用シーン

  1. 01コードベースで選択したFigmaデザインを実装
  2. 02デザイントークンを既存スタイルに対応
  3. 03Figmaの出力をプロジェクトのコンポーネントに適用
  4. 04範囲を絞った実装変更を検証

MCP 対応

このスキルはTemPad Dev MCPを使い、現在の選択範囲または指定されたノードIDについて信頼できるデザイン根拠を取得します。返されたコード、アセット、トークン、警告、コード生成情報を実装の指針にします。

インストール

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

$npx skills add https://github.com/ecomfe/tempad-dev --skill figma-design-to-code

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

同梱ファイル

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

agents/
openai.yaml
assets/
icon.svg
references/
assets-and-tokens.md
recovery.md

詳細

Figma デザインをコードに実装する

Figma で確認できる根拠を、意図された結果を維持する最小限のプロジェクト標準の実装に変換します。その結果を主役にしてください。プロジェクトのファイル、TemPad の出力、ルール、ツール呼び出しは、実装の根拠であり、機械的に再現する成果物ではありません。

現在の選択範囲、またはユーザーが定めたスコープ内の正確なノード ID について、信頼できるデザインの根拠を TemPad Dev MCP から取得してください。記憶やスクリーンショットだけ、または get_structure のメタデータからデザインを再構成してはいけません。

根拠と権限

各情報源は、それぞれが確立できる範囲に限って使用してください。

  • ユーザーが、スコープ、要件、禁止事項、未確定のプロダクト上または実装上の判断事項を定めます。
  • プロジェクトが、フレームワーク、ファイルの配置、コンポーネントの境界、スタイル、トークン、アセット、依存関係、検証の規約を定めます。
  • TemPad Devが、目に見える構造とレンダリングされたデザインの事実を示します。

Figma からコードへの変換以外の事項については、プロジェクトの指示ファイルに従ってください。ルーティング、分析、i18n、CMS、その他の無関係なシステムに関するポリシーを追加してはいけません。

TemPad で確立できるのは、視覚的な階層、レイアウト、間隔、タイポグラフィ、色、エフェクト、トークンの参照、エクスポートされたアセット、コード生成単位のコンテキストです。根拠のない状態、レスポンシブ動作、ビジネスロジック、ナビゲーション、バリデーション、分析、プロジェクトの規約は確立できません。get_structure は階層と幾何学的な根拠としてのみ扱い、不足しているスタイルの確定情報として扱ってはいけません。

ワークフロー

1. 実装範囲を定める

この実装を変え得るローカルの根拠だけを、次の順序で確認します。

  1. 該当する AGENTS.md または同等の指示;
  2. 関連するデザインシステム、トークン、コンポーネント、アセットのガイダンス;
  3. 最も近い類似実装と再利用可能なプリミティブ;
  4. このタスクに必要なフレームワーク、スタイル、チェックの設定。

対象のファイルまたはコンポーネントの境界、フレームワーク、スタイル設定方法、トークンとアセットのパス、再利用候補、依存関係の制約、関連する最小限のチェックを確認します。プロジェクトが実際に Tailwind 互換のツールを使用している場合に限り、Tailwind のバージョンとテーマのスケールを調べます。

必要な実装範囲が明確になったら、リポジトリ全体を広く調べてはいけません。プロジェクトの判断事項が不足しており、それによって結果が大きく変わる場合は、実装を始める前に確認してください。

2. 指定されたスコープのデザインを確認する

実装前に、指定されたルートについて TemPad Dev の get_code を直接呼び出します。

  • 現在の選択範囲(複数ノードを含む)では、nodeId と nodeIds を省略します。正確な対象が 1 つの場合は nodeId、複数の場合は nodeIds を使用します。ユーザーが指定した ID、または定められたスコープ内で TemPad が返した ID のみ使用してください;
  • デフォルトでは resolveTokens: false を使用します。リテラルの出力が要求されている場合、または特定の読み取りによって利用側の実際の値を確認する必要がある場合は、true を使用します;
  • プロジェクトのターゲットから preferredLang を設定します。プラグインの設定によって指定が上書きされる場合があるため、返された lang を正としてください;
  • ユーザーがベクターのアセット保持忠実度を明示的に求めない限り、TemPad のデフォルトのベクター動作を維持します。その場合は、アクティブなツールスキーマが対応していれば vectorMode: "snapshot" を使用します。

各ルートの code、lang、warnings、assets、tokens、codegen はまとめて保持します。バッチでは、各 results エントリーに nodeId が示され、result ペイロードまたは error のいずれかが含まれます。正確な単位変換には、そのルートの codegen.config.{cssUnit,rootFontSize,scale} を使用します。

各ルート内で要求された構成を維持します。返された根拠に関連するガイダンスのみ読み込みます。

  • アセットの受け渡しについては、アセット;
  • トークンの定義、コード内の参照、またはマッピングの判断に必要な利用側の値については、トークン;
  • remainingNodeIds、エラー、警告、誤ったファイルの読み取り、または根拠の不足については、復旧。
3. 事実、適応、ギャップを分離する

編集の前に、次を区別してください。

  • 保持すべき設計上の事実。
  • 既存のコンポーネント、トークン、ユーティリティ、アセットの規約によって裏付けられたプロジェクト固有の適応。
  • 未実装のままにしておくか、確認すべき証拠のない製品上の判断。

都合のよい名前ではなく、レンダリングされる値とセマンティクスで対応付けてください。見覚えのあるコンポーネントやトークンは候補であり、等価性の証明ではありません。複数の実質的な実装パスが同じ程度に妥当なままである場合は、ユーザーに確認してください。影響の小さい詳細のみを推論し、結果に影響する推論は報告してください。

4. 最小の一貫した変更を実装する
  • 確立されたフレームワーク、スタイリングシステム、ファイル配置、インポート、抽象化のレベルを維持してください。並行するシステムを導入しないでください。
  • 既存のプリミティブは、そのセマンティクスとレンダリング時の挙動が推測なしに適合する場合にのみ再利用してください。設計上の事実を消してしまう再利用を強行しないでください。
  • プロジェクトの証拠が等価なトークン、ユーティリティ、コンポーネントを証明しない限り、レンダリングされる正確な値を保持してください。rem 出力については、TemPad の実際の cssUnit、rootFontSize、scale で変換してください。
  • 疑似要素、フィルター、マスク、ブレンドおよびバックドロップ効果、グラデーション、非デフォルトのコンポジットなど、意図的に一般的でない出力は、文書化されたプロジェクトの制約が適応を要求しない限り保持してください。
  • 証拠のある状態とレスポンシブのみを実装してください。hover、loading、error、empty、disabled、レスポンシブの挙動を勝手に作らないでください。
  • ネイティブのセマンティック要素を使用し、確立されたプリミティブがすでに提供していない場合は、キーボードアクセスとアクセシブルな名前を保持してください。
  • ユーザーがその制約を明示的に放棄していない限り、ユーザーの承認なしにランタイム依存関係やビルド依存関係を追加しないでください。
  • data-hint-* 属性は出荷するコードに含めないでください。

視覚的なチューニングループに入らないでください。新しいプロジェクト、設計、ツール、検証の証拠が具体的な欠陥を特定した場合にのみ、実装を再度変更してください。

5. プロジェクトの実際のワークフローで検証する

プロジェクトの指示とスクリプトで定義された、最も範囲の狭い関連チェックを実行してください。実装の失敗を修正し、影響を受けるチェックを再実行してください。既存のプレビュー、スクリーンショット、比較ワークフローが利用可能な場合はそれを使用してください。万能の検証マトリクスを勝手に作らないでください。

実行可能なチェックが存在しない場合は、その実装を未検証として報告してください。実際のプロジェクトの比較手段なしに視覚的な完了を主張しないでください。レンダリング結果を Figma と照合して確認するようユーザーに依頼してください。

ハードストップ

次の場合、影響を受ける作業とそれに依存するすべてのものを一時停止してください。

  • TemPad が利用できない、認可されていない、意図したファイルで非アクティブである、または必要なコンポジションについて信頼できる証拠を提供できない。
  • 対象が読み取れない、または表示されない。
  • 対象を絞った復旧の後も、プロジェクト、設計、ユーザーの証拠が依然として矛盾している。
  • 欠落している判断が、挙動、構造、依存関係、アセットの配信、トークンのマッピングを実質的に変える可能性がある。
  • 必要なアセットをプロジェクトの方針に従って取得または保存できない。

十分な証拠に裏付けられた独立した作業は続けてください。要求された範囲で未完了のまま残ったものと、それを解消するために必要な具体的なアクションを報告してください。

引き継ぎ

次を報告してください。

  • 何がどこで変更されたか。
  • 関連する適応、推論、警告、アセット/トークンの扱い、または残存する視覚的リスクのみ。
  • 実行したチェック、その結果、未検証のまま残っているもの。

該当しない懸念は引き継ぎに含めないでください。タスクが一度も使用しなかった分岐に対するコンプライアンスチェックリストを作成しないでください。

判断の例

TemPad が padding: 15px を出力し、プロジェクトに 16px 相当の space-4 トークンがある場合、プロジェクトの証拠が明示的にそのトークンを意図されたマッピングとしない限り、15px を保持してください。プロジェクトの一貫性は表現を選択するものであり、可視デザインの変更を許可するものではありません。

コメント