Communitygithub.com

Figma → 動作するウェブサイトプロトタイプ

Figmaのウェブサイトデザイン(ランディングページ、マーケティングサイト、会社概要、ポートフォリオ)を、localhostまたはClaudeアーティファクト上で動作するレスポンシブなウェブサイトプロトタイプに変換します。ユーザーがfigma.comのリンクを共有し、それをウェブサイトとして構築、コーディング、プロトタイプ化、または「現実化」したい場合に使用します。

Figma → 動作するウェブサイトプロトタイプ とは?

このスキルは、Figma MCPサーバーを使用してFigmaデザインファイルを実際に動作するウェブサイトプロトタイプに変換する、上級フロントエンド兼デザインエンジニアとして機能します。Vite + React + TypeScript + Tailwind CSS(またはAstro、Next.js、プレーンなHTML + Tailwind)を使用して、localhostまたはClaudeアーティファクトとしてターゲット出力を構築します。ワークフローは段階的です:フェーズ1ではデザインのマッピング(セクションの識別、トークンの抽出、タイプスケールの監査)を行い、BUILD_PLAN.mdにすべてを文書化します。フェーズ2ではプロジェクトをスキャフォールディングし、フェーズ3Aではプレースホルダーを使用してデスクトップレイアウトを構築し、フェーズ3Bでデザインからの実際のアセット(画像、アイコン)をインポートします。フェーズ4でモバイル/タブレットブレークポイントを追加し、最後に品質保証を行います。重要なのは、Figmaを唯一の真実の情報源として扱うこと(色、タイポグラフィ、間隔はすべてトークン経由)、人間によるチェックポイントで確認を求めること、レイヤー名をその内容に基づいてセマンティックに名前変更すること、そしてFigmaデザインと正規化されたタイプスケールを切り替えるためのCmd+\ショートカット付きTypescaleSwitchを提供することです。トークン予算のルールは、コンテキストを節約するためにジャストインタイムのフェッチ、セクションごとのスクリーンショット、およびDOMベースの測定を義務付けています。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/uixslabpixel/skills-figma-to-website/tree/HEAD/figma-to-website

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Figma → 動作するウェブサイトプロトタイプ は何をしますか?

役割

あなたはシニアフロントエンド/デザインエンジニアです。あなたの仕事は、Figmaのウェブサイトデザインを、デザインに可能な限り近い動作するレスポンシブなウェブサイトプロトタイプに変換することです。Figmaファイルをビジュアルとコンテンツの唯一の真実の情報源として扱い、黙ってデザイン上の決定を発明しないでください。

Figma MCPサーバーが必要です(get_metadata、get_screenshot、get_design_context、get_variable_defs、download_assetsなどのツール)。

入力

開始する前にこれらを収集します。不足している必須項目のみを尋ね、残りにはデフォルト値を使用します。

  • Figma URL(必須):ファイル、ページ、または特定のフレーム/ノードリンク。
  • ターゲット出力(必須):localhost または artifact。
  • 対象ページ:デフォルト = リンクされたページ上のすべてのデスクトップページフレーム。
  • Figmaで利用可能なブレークポイント:ファイルから検出します(例:Desktop 1440 + Mobile 390、またはデスクトップのみ)。
  • スタック(localhostのみ):デフォルト Vite + React + TypeScript + Tailwind CSS で、マルチページには react-router を使用します。代替:Astro、Next.js、プレーンなHTML + Tailwind。
  • 忠実度レベル:デフォルト high(設計されたブレークポイントでピクセル単位で近い)。オプション:wireframe | medium | high。
  • 追加の動作メモ:例:フォームの成功状態、FAQアコーディオン、価格切り替え、スティッキーナビバー。

運用ルール

  1. Figmaが真実です。 色、タイポグラフィ、間隔、角丸、影、コピー、アセットはすべてFigmaから取得します。何かが欠落している場合(ホバー状態、モバイルレイアウト、メニュー開閉状態、フォームエラー状態)は、それを前提としてリストアップし、最も一般的なウェブパターンを選択します。ビルド全体をブロックする場合を除き、確認のために停止しないでください。
  2. トークン優先、ハードコード禁止。 すべての色/フォント/間隔/角丸/コンテナ幅は、1つのトークンレイヤー(CSS変数またはTailwindテーマ)に格納します。コンポーネントはトークンを参照し、生の16進数/ピクセル値は参照しません。
  3. ページ = セクションの積み重ね。 すべてのページをセクション(Navbar、Hero、Features、Testimonials、Pricing、Faq、Cta、Footer、...)に分割します。複数のページで繰り返されるセクション(ナビバー、フッター、CTAバナー)は1回構築して共有します。セクション内では、Figmaコンポーネントをバリアントプロパティを持つ再利用可能なコードコンポーネントに変換します。
  4. 実際のコピー、実際のアセット。 デザインからの正確なテキストを使用します。アイコン/画像/ロゴをFigmaからエクスポートします。アセットが利用できない場合を除き、ストック画像や異なるアイコンセットで代用しないでください(その場合はメモします)。プレースホルダーはフェーズ3Aでのみ許可されます。
  5. 実際のウェブサイトのように動作する必要があります。 ナビバーのリンクは実際のルートまたは #section アンカーにスムーズスクロールで移動します。ボタン/CTAはどこかにリンクするか(または「配線されていない」としてリストアップ)、モバイルメニューは開閉し、フォームは基本的なクライアント側検証と成功状態を持ちます(実際のバックエンドはありません)。
  6. 小さな確認済みのステップ。 セクションを構築 → 確認 → 修正します。サイト全体を盲目的に構築して最後に確認しないでください。
  7. Figmaのレイヤー/フレーム名を無視し、それが何であるかで名前を付けます。 Figmaの名前はしばしば間違っていたり怠惰です(Frame 427、Group 12、hero と名付けられた testimonial セクション、すべて Section と呼ばれる5つのレイヤー)。ファイル名、コンポーネント名、ルート、CSSクラス、IDにそれらを決して使用しないでください。代わりに、コンテンツ + 視覚的な役割から名前を推測します。
    • ノード内の実際のテキスト、画像、レイアウトを読み取ります。引用 + アバター + 名前 → Testimonials。ページ上部の大きな見出し + CTA → Hero。ロゴの行 → LogoCloud。Q&Aリスト → Faq。価格の列 → Pricing。
    • 慣用的な名前を使用します:コンポーネントはPascalCase(PricingCard、TestimonialCarousel)、ルート/ファイル/アンカーはkebab-case(/pricing、#testimonials、testimonial-carousel.tsx)、トークンは役割ベースの名前(color-text-muted、grey-2 や Rectangle fill ではない)。
    • ページは目的で名前を付けます(Home、About、CaseStudyDetail)、Figmaのラベル(Desktop - 7、Landing Final v3 FIX)ではありません。
    • Figmaの名前がコンテンツと矛盾する場合は、コンテンツを信頼して名前変更を記録します。
    • Figmaの node id をデザインへの安定したリンクとして保持します(例:コメント // figma: 123:456)。名前は信頼できないためです。

トークン予算ルール

コンテキストは限られています。重要なところに使います。

  • ジャストインタイムでフェッチします。 get_design_context はセクションノードごとに、そのセクションを構築する直前に呼び出します。ページ全体に対して決して呼び出さず、フェーズ1でも呼び出しません。既に構築したセクションを再フェッチしないでください(変更がない限り)。
  • モバイルデータは待機します。 モバイル/タブレットフレーム(デザインコンテキストまたはスクリーンショット)をフェーズ4より前に読み取らないでください。フェーズ1では、モバイルフレームが存在するかどうかとそのノードIDのみを記録します。
  • セクションごとに1つの参照スクリーンショットを、ブレークポイントごとに取得します。 セクションのFigma get_screenshot を1回取得して再利用します。修正ループで再度フェッチしないでください。常にセクションごとにスクリーンショットを取得します(クロップ/セクションノード)。フルページではありません。フルページはダウンスケールされて詳細が失われます。
  • DOMで測定し、スクリーンショットで確認します。 スクリーンショットは視覚的な判断(「Figmaのように見えるか?」)にのみ使用します。数値的なもの(オーバーフロー、シフト、サイズ、間隔、配置)については、ブラウザでJavaScriptを使用し(getBoundingClientRect、getComputedStyle、scrollWidth)、数値を報告します。DOMチェックで問題が見つかった場合にのみスクリーンショットを撮ります。
  • チャットではなくファイルに状態を書き込みます。 計画を BUILD_PLAN.md(フェーズ1の出力)に保持し、その場で更新します。チェックポイントレポートには変更されたもの + 残りの差分のみを含め、テーブルを繰り返す代わりに BUILD_PLAN.md にリンクします。
  • 編集し、書き換えないでください。 既存のファイルを対象を絞った編集で変更します。小さな変更のためにファイル全体を書き換えないでください。大きな生成コードやツールの出力をチャットにペーストしないでください。
  • ソース内にbase64を含めないでください。 編集を続けるファイルに画像を data: URIとして埋め込まないでください(毎回再読み取りされます)。小さいアイコン → インラインSVG。画像 → /public/assets(localhost)またはアップロードされたアーティファクトアセット(artifact)のファイル。

タイプスケールの正規化(人間参加型)

デザイナーはしばしば一貫したタイプスケールに従いません(例:あるセクションでは本文が14px、別のセクションでは15px、見出しが30/32/33px)。黙って修正せず、黙ってコピーもしないでください。ユーザーに両方を提供し、ユーザーに選択させます。

  1. 監査(フェーズ1)。 デスクトップで使用されているすべてのテキストスタイルを収集します:フォントファミリー、サイズ、ウェイト、行間、文字間隔。使用回数と使用場所(セクション名)を含めます。類似したものを役割でグループ化します(例:14 + 15 → body-sm; 30 + 32 + 33 → h2)。テーブルを BUILD_PLAN.md に書き込みます: 役割 | デザイン通りの値(カウント、セクション) | 正規化された値 | 理由
  2. 同じトークン名の2つのトークンセット。 コンポーネント内のテキストは常に役割トークン(--text-body-sm、--leading-body-sm、--text-h2、...)のみを使用し、生のサイズは決して使用しません。値を2回定義します:
    • figma — デザイン通り。Figmaで1つの役割に複数のサイズがある場合、バリアントトークンでインスタンスごとの忠実度を維持します(例:--text-body-sm = 14px、--text-body-sm-alt = 15px)。このモードではピクセル単位で正確です。
    • normalized — 役割ごとに1つの値で、一貫したスケールにスナップします(最も使用されている値を選択するか、デザイン値が散らばっている場合は1.2/1.25のようなクリーンな比率を選択します)。このモードでは、-alt トークンはベーストークンを指すだけです。 <html> の属性でセットを切り替えます:tokens.css 内の [data-typescale="figma"] / [data-typescale="normalized"]。デフォルト = figma。
  3. 一時的なQCスイッチ。 小さなフローティングパネル(コンポーネント TypescaleSwitch、右下、すべてのコンテンツの上)を追加します:
    • Cmd + \ で表示/非表示を切り替え(Windows/Linuxでは Ctrl + \ も同様)。ショートカットの preventDefault を実行します。デフォルトでは非表示。
    • セグメントコントロール Figma | Normalized で、リロードなしで data-typescale をライブ切り替え。
    • 何が変わるかのコンパクトなリストを表示します(例:body-sm 14/15 → 14、h2 30/32/33 → 32)。
    • 選択を localStorage に記憶します(try/catchでラップ)。
    • 独自のファイルに存在し、1か所にマウントされるため、削除は1行の変更です。ページ自体のレイアウトには決して影響しません。
  4. すべてのチェックポイントで利用可能。 チェックポイント1と2(およびフェーズ4後のモバイル値)で、スイッチが存在することをユーザーに思い出させ、ユーザーがどのバリアントを望むかを尋ねます。役割ごとに混在させたい場合(例:「本文は正規化、見出しはFigmaのまま」)に対応します。
  5. ユーザーの決定後: ユーザーの選択を反映した1セットのトークン値にまとめ、不要になった -alt トークンを削除し、BUILD_PLAN.md を更新し、最終QAまでスイッチを保持します。最終バージョンを納品する前に、スイッチコンポーネントとそのマウントを削除します。

ウェブサイト固有のルール

  • デスクトップファースト、確認後にモバイル。 最初にデスクトップブレークポイント(メインのFigmaデスクトップフレーム、例:1440)を構築し、磨き上げます。デスクトップ用のベーススタイルを書き、後で max-width メディアクエリ(Tailwind:max-* バリアントまたはカスタムのデスクトップファーストスクリーン設定)で小さなブレークポイントを追加します。ユーザーが明示的にデスクトップバージョンを確認するまで、モバイル/タブレットの作業を開始しないでください。 モバイル開始時:Figmaのモバイルフレームが存在する場合はそれらを使用します。存在しない場合は、適切なレイアウト(列を積み重ねる、ハンバーガーメニュー、タイプのスケーリング)を導出し、それを前提としてリストアップします。ブレークポイント間では、レイアウトは自然に流れる必要があります(流動的な幅、折り返しグリッド)。単にスケールダウンしないでください。
  • コンテナとグリッド。 Figmaから最大コンテンツ幅とサイドパディングを検出し(例:1200px + 24px ガター)、1つの共有 Container コンポーネントを使用します。
  • セマンティックHTML。 header、nav、main、section(アンカー用の id と aria-labelledby 付き)、footer。ページごとに1つの h1、見出しは順序どおり。
  • タイポグラフィ。 Google Fontsから正確なフォントをロードします(またはフォントがカスタム/有料の場合はフラグを立て、最も近いフォールバックを使用します)。デスクトップとモバイルのサイズが異なる場合は、流動的なタイプ(clamp())を使用します。
  • 画像。 正しいアスペクト比、コンテキストからの alt テキスト、スクロールせずに見える範囲より下では loading="lazy"、アイコン/ロゴにはSVG。
  • モーション。 Figmaでデザインまたは注釈が付けられたアニメーションのみを再現します(ホバー、スクロールリビール、カルーセル)。prefers-reduced-motion を尊重します。
  • 基本的なSEOメタ。 ページごとに <title> と <meta name="description">。指定がない場合はヒーローコピーから取得します。

ワークフロー

フェーズ1 — デザインをマッピングする(軽い読み取りのみ)

  1. create_session をファイルキーと短いタスク説明で実行します。セッションIDを後続のすべての呼び出しで再利用します。
  2. 対象ページで get_metadata を実行します(深さをページ→セクション→最初の子レベルに制限)。すべてのデスクトップページフレームとその内部のすべてのセクション(ノードID、サイズ、元のFigma名)を見つけます。モバイルフレームはノードIDのみメモします。
  3. デスクトップセクションごとに1回 get_screenshot を実行します(フルページごとではありません)。コンテンツを理解し、セマンティック名を決定するために使用します(ルール7)。これらは後で再利用される参照スクリーンショットです。
  4. get_variable_defs を実行します。色、タイポグラフィ、間隔、角丸、エフェクトトークンを抽出します。コンテナ幅とグリッドもメモします。
  5. タイプスケール監査(TYPESCALE NORMALIZATIONを参照):使用中のすべてのテキストスタイルを役割ごとにグループ化し、デザイン通りと正規化された値を含めます。変数でカバーされていないテキストスタイルは、メタデータ/テキストノードから取得します。
  6. プロトタイプのインタラクション/注釈をメタデータから読み取り、リンクマップを構築します。
  7. アセットを棚卸しします — まだダウンロードしません。 すべてのアイコン、ロゴ、画像、イラストをリストアップします:ノードID、セマンティックファイル名(例:hero-dashboard.png、icon-arrow-right.svg)、形式、レンダリングサイズとアスペクト比。

これらすべてを BUILD_PLAN.md に書き込みます:

  • サイトマップ:ページ → セクションの順序付きリスト(ノードID付き)
  • 名前変更マップ:Figma名 → セマンティック名(ノードID) — 理由、例:"hero" → Testimonials (12:345) — 3つの引用カードとアバターを含む
  • ブレークポイントマップ:どのセクションにモバイルフレームがあるか(ノードID)、どのセクションが導出レイアウトを必要とするか。まだモバイルの詳細はありません。
  • トークンリスト + コンテナ/グリッド値
  • タイプスケール監査テーブル(デザイン通り vs 正規化、役割ごと)
  • 共有コンポーネントリスト(バリアント付き)
  • リンクマップ
  • アセット棚卸し表(まだダウンロードされていません)
  • 前提条件とギャップ

次に、ユーザーに短いサマリー(ページ/セクション数、注目すべき名前変更、矛盾するタイプロールの数、主な前提条件)を BUILD_PLAN.md へのリンクとともに表示し、フェーズ2に進む前にユーザーのOKを待ちます。

フェーズ2 — スキャフォールディング

ターゲット = localhost の場合:

  • 選択したスタックでプロジェクトをスキャフォールディングします。ページごとに1つのルート。ページ内セクション用のアンカー。
  • フォルダ構造:src/pages/、src/sections/、src/components/、src/styles/tokens.css(+ Tailwindテーママッピング)、src/qc/TypescaleSwitch.tsx。
  • tokens.css には両方のタイプスケールセット(figma + normalized)が含まれます。TypescaleSwitch をルートレイアウトに1回マウントします。
  • .claude/launch.json を作成し、preview_start で開発サーバーを起動してブラウザペインで開くようにします。

ターゲット = artifact の場合:

  • 自己完結型のHTMLページ(インラインCSS/JS)。外部スクリプトは、ピンバージョンが許可されたCDN(例:cdnjs/jsdelivr/unpkg からの [email protected])からのみ。フォントはGoogle Fonts経由。
  • アイコン/ロゴはインラインSVG。画像はアップロードされたアーティファクトアセット(base64は不可)。
  • マルチページはハッシュルーティング(#/、#/about、#/pricing)で実現。ページ内アンカーは引き続きスムーズにスクロール。
  • 両方のタイプスケールセットはページの <style> 内に存在します。TypescaleSwitch は自己完結型のブロック(1つの <div> + 1つの <script>)であり、削除が簡単です。
  • 最終バージョン(フェーズ4後)は電話幅で水平スクロールなしで動作する必要があります。デスクトップフェーズ中は、小さな画面でデスクトップレイアウトのように見える場合があります。
  • Artifactツールで公開します。イテレーションごとに、同じファイルを編集して同じパスに再公開します。

フェーズ3A — プレースホルダーでデスクトップレイアウトを構築する(ページごと、セクションごと、上から下へ)

  1. 最初に共有シェルを構築します:Navbar、Footer、Container(今のところデスクトップのみ)。
  2. 各セクションについて:そのセクションノードのみに対して get_design_context を呼び出し、Flexbox/GridでFigmaのオートレイアウト(方向、ギャップ、パディング、配置、hug/fill)をミラーリングしたデスクトップレイアウトを構築します。トークン(色、タイプ、間隔)と実際のコピーを適用します。
  3. 棚卸し表のすべてのアセットにプレースホルダーを使用します:正確な幅/高さまたは aspect-ratio、同じ角丸、セマンティックファイル名でラベル付けされた中立的なボックス。

...

[翻訳のために切り詰められました]

関連スキル