mcpField
B
build-design

build-design

github.com/jakubkrehelデザイン・UI9.0k4.4k 回インストール3 日前に更新
リポジトリ

build-design について

build-designは、既存プロジェクトでデザインを実装し、結果を照合するスキルです。デザイン元の値、既存のトークンやコンポーネントを優先し、変更範囲を限定します。

主な機能

  1. 01Figmaや画像からデザイン値を取得
  2. 02既存トークンとコンポーネントに対応付け
  3. 03指定フレームと状態のみを実装
  4. 04デザインと描画結果を比較
  5. 05差異と未解決事項を報告

活用シーン

  1. 01既存コードベースへのFigmaフレーム実装
  2. 02明示した推定値によるスクリーンショット再現
  3. 03指定ブレークポイントでの表示確認

MCP 対応

Figmaのデザインでは、Figma MCPツールを検索して使用するようエージェントに指示します。利用できない場合は、推測で実装せず接続を求めます。

インストール

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

$npx skills add https://github.com/jakubkrehel/skills --skill build-design

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

同梱ファイルagents/openai.yamlfigma.md

詳細

デザインの実装

このスキルは、デザインに一致するコードを作成します。デザインをそのソースから読み取り、プロジェクトにすでにあるものを使って実装し、完了とする前に結果をデザインと比較します。

判断基準はデザインです。値はデザインファイルから取得し、好みや、別の場所で気に入ったパターンから決めるものではありません。デザインに示されていない変更は逸脱であり、判断するのはユーザーです。

ドメインルールは扱いません。デザインがルールに反する場合は、デザインどおりに実装し、担当者にその衝突を報告します。コントラストは better-accessibility の要件であり、better-colors で測定します。フォーカスとセマンティクスは better-accessibility、タイポグラフィは better-typography、間隔と構造は better-layout が扱います。パレットは better-colors、コピーは better-writing、サーフェス、アイコン、モーションは better-ui が扱います。完成した作業のレビューには interface-review、代替案の検討には variant、コンポーネントのストレステストには break を使います。

1. デザインをソースから読み取る

Figma のリンクがある場合は、Figma MCP を使います。利用可能なツールと保留中のツールを検索し、figma が利用できないと判断する前に探してください。サーバーが想定外の名前で登録されていることもよくあります。認証ツールしか表示しないサーバーは接続済みですが、サインアウト状態です。その場合はユーザーに認証を依頼してください。Figma ツールがまったくない場合は、ユーザーに接続を依頼し、それまでは記憶や推測に基づいて実装しないでください。figma.md に呼び出すツールと、それぞれの戻り値が記載されています。

スクリーンショットや書き出された画像からは、値を読み取れません。サイズは画像に対する比率となるため、想定したスケールを明示し、すべての測定値を推定値として扱ってください。Figma のリンクがある場合は、推定をすべて置き換えられるため、ユーザーに依頼してください。

指定されたフレームだけを対象に実行します。同じものを幅違いで示すフレームは、別々のパーツではなく、複数のブレークポイントに対応するひとつのパーツです。

このステップの完了条件は、対象となるすべてのフレームのスクリーンショットと、間隔、サイズ、角丸、色、タイポグラフィ、使用コンポーネントの各値を把握していることです。Figma ファイルから取得した値は正確です。画像から取得した値は、明示したスケールに基づく推定値です。

2. デザインをプロジェクトに対応付ける

コードを書く前に、プロジェクトのトークンとコンポーネントライブラリを確認します。そのうえで、デザインの各値を既存のものに対応付けます。

デザイン内の要素コード内の要素
変数またはスタイルへのバインド同じ名前または同じ値のトークン
トークンと一致する直接指定の値そのトークン
対応するトークンがない直接指定の値最も近い既存のトークン。レポートには丸めた値として記載
コンポーネントのインスタンスその名前のプロジェクトのコンポーネント。デザインに示されたバリアントを使用
プロジェクトに対応するものがないコンポーネントのインスタンス該当箇所にプレーンなマークアップを使用し、逸脱として記載。コンポーネントを作成すべきか確認
単発のレイヤーグループ該当箇所にプレーンなマークアップを使用し、新しいコンポーネントは作成しない

数値に合わせるために、トークン、コンポーネントのバリアント、任意の値を追加してはいけません。丸めによってデザインが目に見えて変わる場合は、どう進めるかユーザーに確認してください。目に見えて変わるのは、間隔やサイズで 2px を超える場合、または色が別の段階になる場合です。

デザインに必要なデータを確認し、既存のデータに接続します。一部のバックエンドがまだ存在しない場合は、その部分を props からデータを受け取る UI として実装し、レポートに未接続として記載します。

3. デザインに示されたものだけを実装する

フレーム、フレームで定義されたブレークポイント、そしてホバー、空、エラーなどファイルに描かれた状態だけを実装します。ファイルに描かれていない状態は、こちらでデザインするものではありません。既存コンポーネントのデフォルトに任せ、未対応として記載します。

対象箇所以外は変更せずに残します。周辺のコピー編集、アイコンの差し替え、「ついで」の整理はしません。デザインの範囲を超える差分は、最もよくある失敗の原因です。

4. デザインと比較する

各フレームの幅でビルドをレンダリングし、デザインのスクリーンショットの横に並べて、要素ごとに確認します。「デザインを元の状態で読み取る」で収集したプロパティを比較します。「間隔は12pxですが、デザインでは16pxです」は指摘です。「少し窮屈に感じます」は指摘ではありません。

ブラウザーが使える場合は、各幅でスクリーンショットを撮って比較します。使えない場合は、確認する幅とともにローカルURLを共有し、比較は未検証であることを伝えます。実際に確認していないものを一致していると報告してはいけません。

発生させた不一致をすべて修正してから、もう一度比較します。残っている差異が丸め誤差か疑問点だけになれば、このステップは完了です。

5. 報告して終了する

要素デザインビルド状態
カードのパディング20pxp-5一致
タイトルサイズ15pxtext-sm、14pxトークンに丸め
バッジ塗りつぶしのピル型テキストラベル乖離、確認済み:バッジコンポーネントが存在しない

続けて、各項目を1行ずつ記載します。該当するものがなければ、そのリストは省略します。

  • 未接続。 バックエンドが用意されるまで、propsから何がレンダリングされるか。
  • 不足している状態。 デザインに描かれていないもの。
  • ドメイン上の競合。 デザインがルールに反する箇所と、そのルールを管轄するスキル。

ビルドが実行されている場所と、比較した幅を伝えて締めくくります。

完了前の確認事項

気づいたこと対応
ツールを検索する前に「Figmaに接続されていません」と記載しているまずツールでfigmaを検索する
コード内にある値がFigmaのレスポンスにはなく、スクリーンショットにだけあるデザインコンテキストから読み取る
差分にw-[343px]などの任意のユーティリティや生の16進カラーコードがあるトークンに対応付けるか、丸めてよいか確認する
コンポーネントディレクトリに、コンポーネントではないフレーム用の新しいファイルがある通常のマークアップとしてインライン化する
デザインに描かれていないローディング分岐やエラー分岐がある削除してデフォルトの状態を維持し、不足項目として記載する
どのフレームにも関係しないファイルが差分にある元に戻す
デザインに示されていないコントラストやフォーカスの変更があるデザインの状態に戻し、管轄する所有者とともに競合を報告する
ビルドのスクリーンショットなしで比較したと主張している各フレーム幅をレンダリングするか、未検証と記載する
ハードコードされたサンプルデータがあるのに、報告に記載されていない未接続に記載する

コメント