figma-designer

figma-designer skill の概要

figma-designer でできること

figma-designer は、Figma ファイルやデザインのスクリーンショットを、実装につながるアウトプットへ変換する skill です。具体的には、デザイン分析、ビジュアル仕様、コンポーネント詳細、さらに開発者がそのまま引き継ぎやすい PRD 形式のドキュメントを生成できます。価値の中心は単に「この画面を説明する」ことではなく、「プロダクトチームやエンジニアリングチームが解釈のズレを減らして実装できるだけの構造を、デザインから抽出する」ことにあります。

figma-designer を使うべき人

figma-designer が特に向いているのは、次のようなケースです。

• 承認済み UI を実装タスクに落とし込みたいプロダクトエンジニア
• 実装-ready な仕様書を整えたい PM やデザイナー
• 汎用プロンプトより信頼性の高いデザイン handoff を求める AI エージェント利用者
• すでに Figma を使っていて、Figma MCP 経由でファイルを公開できるチーム

一方で、軽い見た目のフィードバックやラフな UI アイデア出しだけが目的なら、通常のプロンプトで十分なことが多いです。figma-designer は、より精度の高い handoff 向けの skill です。

実際に解決したい仕事

多くのユーザーが figma-designer skill を導入する理由は、完成度の高いモックアップと、実装可能な仕様のあいだにあるギャップを埋めたいからです。この skill は Figma MCP を通じてファイルのメタデータ、ノード、コンポーネントを調べ、次のような構造化アウトプットを生成する前提で設計されています。

• レイアウトと余白の仕様
• タイポグラフィとカラートークン
• コンポーネント階層
• 実装メモ
• PRD 形式のドキュメント

主な差別化ポイント

一般的な「このデザインを分析して」というプロンプトと比べると、figma-designer が強いのは次のような場面です。

• スクリーンショットの見た目解釈だけでなく、Figma の実データを直接使いたい
• design token の抽出をより明示的に行いたい
• 感想や総評ではなく、実装に向いたアウトプットがほしい
• prd-planner のような後続 planning skill へつなげる前提で使いたい

導入時の最大の制約

最大のハードルはプロンプトではなくセットアップです。figma-designer install がうまくいくかは、Figma MCP server が利用可能で、かつ認証済みかに大きく依存します。MCP アクセスや必要な Figma tools がない場合、この skill の強みはかなり失われ、出力品質は汎用的なビジュアル分析に近づきます。

figma-designer skill の使い方

開始前に確認したい導入コンテキスト

この skill は zhaono1/agent-playbook の skills/figma-designer にあります。リポジトリの README では、Claude Code 向けに symlink ベースのインストール方法が案内されています。

ln -s ~/agent-playbook/skills/figma-designer/SKILL.md ~/.claude/skills/figma-designer.md

別の skill loader を使っている場合は、自分の環境に合わせてパスを調整してください。重要なのは、エージェントが SKILL.md を発見できて、Figma リンクやスクリーンショットが渡されたときに呼び出せることです。

figma-designer install に必要な依存関係

良い出力を期待する前に、次の前提条件を確認してください。

• Figma MCP server がインストール済みで、到達可能である
• 必要な MCP tools が存在する
  • figma_get_file
  • figma_get_nodes
  • figma_get_components
• セットアップ上必要であれば、有効な FIGMA_ACCESS_TOKEN が設定されている

リポジトリでは、利用可否の確認に次のコマンドが示されています。

mcp-list

また、トークン設定は次の形です。

export FIGMA_ACCESS_TOKEN="your_token_here"

figma-designer に必要な入力

最も相性が良い入力は次のとおりです。

• Figma ファイル URL
• 対象を明確にした frame、page、または flow
• 必要に応じた補足用スクリーンショット
• 実装先のプラットフォーム（web、React Native、SwiftUI など）
• 期待する出力形式（PRD、実装仕様、component inventory など）

ファイルリンクだけでも動作はしますが、対象範囲を絞ったほうが出力品質は大きく上がります。

figma-designer で強いプロンプトを書くコツ

弱い依頼の例は次のようなものです。

Analyze this Figma design: [URL]

より強い figma-designer usage のプロンプト例はこちらです。

Use figma-designer on this Figma file: [URL]

Focus on the login flow frame only.
Output:
1. visual hierarchy
2. spacing, typography, and color tokens
3. reusable components
4. edge cases and interaction assumptions
5. implementation-ready PRD for React Native

Call out anything ambiguous or hidden in the design that engineering should confirm before building.

このほうがうまく機能する理由は次のとおりです。

• 分析対象を限定している
• 構造化された出力を要求している
• 実装プラットフォームを明示している
• 不確実な点を曖昧なまま扱わせず、見せるよう求めている

実案件での figma-designer のベストな進め方

実務で使う figma-designer guide は、だいたい次の流れが現実的です。

1. MCP 接続を確認する
2. Figma URL を渡す
3. 対象の frame、screen、または user flow を正確に指定する
4. token、component、layout spec の抽出を依頼する
5. プラットフォーム別の実装メモを求める
6. 曖昧な点をレビューする
7. 必要に応じて結果を prd-planner に渡し、より広い planning に進める

大きなファイルに対して最初から「全部生成して」と頼むより、この進め方のほうが実用的です。ノイズが増えにくく、本当に見たい画面を取りこぼしにくくなります。

導入前に最初に読むべきリポジトリファイル

採用前に中身を確認したいなら、まず次のファイルを見るのがおすすめです。

1. skills/figma-designer/SKILL.md — 起動ロジック、前提条件、ワークフロー
2. skills/figma-designer/README.md — インストール詳細と基本例
3. skills/figma-designer/references/example-output.md — 出力スタイルを最速で判断できる資料

特に example output は有用です。この skill が目指している handoff の粒度がわかり、レイアウト注記やプラットフォーム別の実装ヒントまで含まれることを確認できます。

Figma URL ではなくスクリーンショットを使うべき場面

スクリーンショットが適しているのは、次のような場合です。

• Figma に直接アクセスできない
• ファイルへのアクセスが制限されている
• 画面の一部だけを軽く分析したい

ただし、figma-designer for UI Design という観点では、スクリーンショットはあくまで次善策です。構造化されたノード情報、コンポーネントのメタデータ、より精度の高い token 抽出が失われます。実装精度が重要なら、ライブな Figma ファイルを優先してください。

figma-designer で依頼すべき出力

役に立つ依頼は、出力内容が明確です。たとえば次のような組み合わせが有効です。

• PRD と visual specification
• design token inventory
• component breakdown と naming suggestions
• プラットフォーム別の implementation notes
• design review 向けの open questions

これは、デザイン解釈と実装可能な詳細を混ぜて出すリポジトリの example output とも整合しています。

プラットフォーム別のプロンプトのコツ

reference output からもわかるように、仕様はプラットフォーム慣習に合わせて調整したほうが有効です。ターゲットは明示してください。

• Web (React)：CSS で扱いやすい spacing や layout の言い回しが必要な場合
• React Native：style object やモバイル制約を前提にしたい場合
• SwiftUI：iOS ネイティブの対応づけが必要な場合

プラットフォーム情報がないと、有用ではあっても、そのまま使いにくい仕様になりがちです。

よくある使い方のミス

figma-designer skill で結果が弱くなりやすいのは、次のようなケースです。

• 広すぎるファイルを渡し、対象 frame を指定しない
• 仕様の明確化より先にコード生成を求める
• 静的デザインだけで隠れたインタラクションまで推定できると考える
• プラットフォーム情報を省く
• skill を入れたのに MCP tools の可用性を確認していない

figma-designer 実行後に起こること

skill metadata によると、実行後の hook によって次が動く可能性があります。

• PRD 生成時に ask-first 動作で prd-planner を起動
• バックグラウンドで self-improving-agent を実行
• session-logger を自動実行

これは、単発の分析として使うのか、それとも design-to-planning の長いワークフローに組み込むのかを考えるうえで重要です。

figma-designer skill の FAQ

figma-designer は通常のプロンプトより優れていますか？

Figma に実アクセスできるなら、たいていは yes です。優位性は文章生成のうまさではなく、ファイル構造やコンポーネントを tool ベースで調べられる点から来ます。スクリーンショットしか渡さない場合は、通常のプロンプトとの差は小さくなります。

figma-designer は初心者向けですか？

中程度です。プロンプト自体は難しくありませんが、MCP や access token が詰まりやすく、セットアップは完全に初心者向けとは言えません。すでに MCP tools が使える環境なら、試しやすい skill です。

figma-designer を使わないほうがよいのはどんな時ですか？

次のような場合は figma-designer を見送ったほうがよいです。

• デザイン抽出ではなく、創造的な UI アイデア出しがしたい
• Figma にアクセスできず、しかもスクリーンショットの品質が低い
• 実装レベルの詳細ではなく、ざっくりした要約だけで足りる
• ファイルが巨大で、対象範囲を絞れない

figma-designer はコードを生成できますか？

コード寄りの handoff を支援することはでき、reference material には生成コードの例も含まれています。ただし、安全な使い方は「まず仕様生成、その次にコード生成」です。最初からコード生成器として扱うより、まずは design-to-spec の tool として使うほうが堅実です。

figma-designer は大規模なプロダクト全体ファイルでも使えますか？

使えます。ただし、最初の使い方としては理想的ではありません。page や variant が多い大規模ファイルでは、分析が散漫になりやすいからです。最適な figma-designer usage は、page、frame、または flow を具体的に指定することです。

figma-designer を試すための最小セットアップは？

最低限必要なのは次のとおりです。

• エージェントから skill を利用できる状態
• Figma MCP 接続
• 必要な Figma MCP tools
• 自分がアクセスできる有効なデザイン URL

これらがない場合でも、スクリーンショットから近い分析はできますが、それはもはやこの skill の最も強い使い方ではありません。

figma-designer skill を改善する方法

デザインの対象範囲をもっと狭くする

figma-designer の出力を最も手早く改善する方法は、曖昧さを減らすことです。たとえば「このアプリのデザインを分析して」ではなく、次を明示してください。

• どの frame か
• どの user journey か
• どの state が重要か
• どのプラットフォーム向けに実装するか

範囲を絞ることで、token 抽出はより正確になり、component のグルーピングも整理され、勝手な推測も減ります。

作り込んだ断定ではなく、不確実性の明示を求める

良い design handoff には、「何が不明か」が含まれます。次のような指示を加えると有効です。

If spacing, states, or interactions are ambiguous in the Figma file, list them as assumptions or design questions instead of guessing.

これにより信頼性が上がり、実際の実装 planning で使いやすい出力になります。

figma-designer の出力構成を固定で指定する

再現性を重視するチーム向けの強い figma-designer guide としては、次のようなセクション構成を標準化する方法があります。

• summary
• layout specs
• tokens
• components
• interactions
• engineering risks
• unanswered questions

構造が一定になると、実行結果の比較や、product / engineering への handoff がしやすくなります。

プラットフォームと実装先を最初に伝える

チームが React Native を作っているなら、最初にそう伝えましょう。Web フロントエンド向け handoff の PRD がほしいなら、それも先に指定します。figma-designer は、ビジュアル上の判断をチームの実装語彙へ落とし込めるときに、より力を発揮します。

example reference と照らし合わせて出力を確認する

本格導入の前に references/example-output.md を読んでください。ここを見るだけで、次の点がすぐ判断できます。

• handoff スタイルが自分たちのチームに合うか
• どの程度の実装詳細を期待できるか
• より多い構造化が必要か、逆に簡略化したほうがよいか

導入判断のための repo ファイルとして、かなり情報価値が高い部類です。

まず小さく試し、あとから広げる

最初からアプリ全体を対象にしないでください。より良い進め方は次の順です。

1. 重要な 1 画面を分析する
2. プロンプト構造を調整する
3. token と component の品質を確認する
4. 隣接する画面や flow に広げる

このやり方なら、大きな実行に時間を使う前に、figma-designer install やプロンプト設計の問題を早めに見つけられます。

よくある失敗パターンを把握する

主な品質低下パターンは次のとおりです。

• 間違った frame を分析している
• スクリーンショット入力のみで出力が浅くなる
• PRD の文言が汎用的すぎて、ビジュアル固有性が足りない
• ターゲットプラットフォームを無視した出力になる
• デザインに見えていないインタラクションを過信して断定する

これらの多くは、skill の再インストールではなく、スコープ設定と明示的なプロンプト改善で解決できます。

figma-designer を後続 planning と組み合わせる

最初の出力が良ければ、次に効く改善はプロセス設計です。figma-designer で design spec を作り、それを planning skill や実装ワークフローへ渡してください。metadata に prd-planner hook があることからも、この skill は単独で完結させるより、大きな design-to-build チェーンの入口として使うと真価を発揮します。