Figma からフロントエンドページへの変換

Figma からフロントエンドページへ

成果と範囲

選択されたデザインを既存のプロジェクトに実装し、ブラウザで結果を検証します。Figma URL があれば通常は開始に十分です。リポジトリからプロジェクトの規約を推測します。デザインにアクセスできない場合は、提供されたスクリーンショットやエクスポートをフォールバックの証拠として受け入れます。

ユーザーの指示がこれらのガイドラインよりも優先されます。既存の変更を保持し、編集範囲を要求された範囲内に収めます。新しいページ、既存ページの更新、セクション、再利用可能コンポーネントのいずれであるかを、ファイルやルートを選択する前に特定します。コンポーネントや局所的な修正を新しいページに変えないでください。

コア制約

• 編集前に該当するリポジトリコードを読んでください。フレームワーク、ルーター、スタイリング、トークン、コンポーネント、アセット、データ規約を適宜再利用してください。
• デザインのジオメトリをレイアウトルールに変換します。通常のフロー、フレックス、グリッドを優先し、実際の重なり、装飾、オーバーレイには絶対配置を使用します。Figma グループは証拠であり、必須のコンポーネント境界ではありません。
• 同一のアセットと適切なマッピングされたコンポーネントを再利用します。特徴的な画像やアイコンは、近似の記号で代用せずに保持します。インタラクティブなセクション全体をスクリーンショットとしてレンダリングしないでください。
• 要件、プロトタイプ、または既存のプロダクト動作によってサポートされる動作を実装します。外観のみからスティッキー配置、フィルターセマンティクス、API コントラクト、ナビゲーション先を推測しないでください。
• セマンティックコントロール、アクセシブルな名前、キーボード操作、適切なフォーカス動作を保持します。OS ステータスバーなどのデバイス クロームは、要求がない限り含めないでください。
• 実装されたターゲットをデザインと比較せずに視覚的パリティを主張しないでください。ブロックされた要件や未検証の要件は明示的に報告してください。

CSS 互換性

• フレックス、グリッド、繰り返しアイテム間のスペースには margin を使用します。gap、row-gap、column-gap は使用しないでください。名前付きアイテムクラスにスペーシングを設定します。最初または最後のアイテムのマージンが異なる場合は、明示的なモディファイアクラスを付与します。gap を > * + *、:first-child、:last-child などのセレクタで置き換えないでください。
• 明示的なコンポーネントクラスに対してセレクタを記述します。WXSS にコンパイルされる可能性のあるスタイルでは、ユニバーサルセレクタや兄弟結合子（+、~）を避けてください。他の擬似クラスや結合子を使用する前に、ターゲットプラットフォームのセレクタサポートを確認してください。ブラウザの CSS サポートが WXSS サポートを意味するとは想定しないでください。
• マスクと固定パネルには、inset ではなく明示的な top、right、bottom、left 宣言を使用します。env(safe-area-inset-*) を使用する場合は、env() を使用する宣言の直前にプレーンな値のフォールバックを配置します。固定幅とパディングを一緒に適合させる必要がある場合は、box-sizing: border-box を設定します。
• Taro H5 では、組み込みの taro-button-core:active スタイルが、ホバークラスが無効になっている場合でも、押されたボタンをグレーに変更する可能性があります。デザインに押された時の色の変更がない場合、特定のボタンクラスのアクティブな背景色とテキスト色をオーバーライドし、各ボタンの通常の色を維持します。グローバルにボタンをリセットしたり、無効なスタイリングを変更したりしないでください。

証拠と判断

設計証拠を収集または更新する際は、design-evidence.md を読んでください。ターゲット、プロジェクト規約、アセットマッピング、適用可能な機能、および不確実性に関する簡潔な作業サマリーを保持します。コンテキストメモは小規模なタスクには十分です。有用または要求されない限り、仕様ファイルを生成しないでください。

判断を分類します:

• 確認済み: 明示的なユーザー要件、選択されたデザインプロパティ、プロトタイプの動作、または関連する既存のプロダクトコントラクト。
• 推測: 通常のレイアウト適応、折り返し、およびプロジェクトと一致するローカルコンポーネント境界。最小限の合理的な実装を選択し、重要な仮定を開示してください。
• 不明: 欠落している送信コントラクト、曖昧な遷移先、競合するターゲットフレーム、または重大なビジネス動作。最初に利用可能な証拠を調査し、それでも必要な場合は具体的な質問をしてください。回答を待つ間も独立した作業を続けてください。

表示されるコントロールだけでは、そのビジネス動作は確立されません。成功した送信を偽装したり、エンドポイントを発明したり、モック動作を黙って代用したりしないでください。フィクスチャは、タスクまたは既存のプレビュー規約がサポートしている場合にのみ使用し、その制限を明示してください。

実行

固定された順序を繰り返すのではなく、依存関係に従ってください。局所的な修正の場合は、有効な証拠を再利用し、変更された領域と影響を受ける共有動作を検査します。独立したリポジトリとデザインの読み取りはバッチ処理できます。

1. ターゲットとプロジェクトの特定

ファイルキーとノード ID を解析します。選択されたノードのタイプ、寸法、および周囲のコンテキストを検査します。ノード ID がない場合は、トップレベルの候補を検査します。ターゲットが明確な場合のみ選択します。

対象を絞った検索と読み取りを使用して、以下を確立します:

• 該当するリポジトリの指示と現在の変更
• パッケージマネージャー、開発および検証コマンド
• 可能性が高い宛先ファイルと最も近い既存の実装
• ルーター、スタイリング、トークン、フォント、ビューポート/ユニット処理、コンポーネント規約
• 既存の設計からコードへのマッピングと利用可能なアセット

既存のページまたはコンポーネントの作業の場合は、そのエントリポイントを保持します。新しいページの場合は、既存のルートファミリーとパラメーター規約に従い、競合を確認します。フレーム名はフォールバックの命名ヒントとしてのみ使用し、汎用的な詳細ルートを強制しないでください。

2. 十分な設計証拠の収集

メタデータ、スクリーンショット、変数、コンポーネントマッピング、アセットには、利用可能な Figma ツールを優先します。それらのツールを呼び出す前に、必要なツール固有のスキル前提条件に従ってください。アクセスに失敗した場合は、利用可能な認証済みブラウザを試し、次に提供されたスクリーンショットまたはエクスポートを試してください。実際のデザインの代わりにウェブ検索を使用しないでください。

ターゲットのスクリーンショットと構造の概要から開始し、関連するサブツリーの詳細を取得します。スクロールして表示されるコンテンツ（below-the-fold）も検査します。ファイル全体または無関係なフレームを繰り返し取得しないでください。利用できない測定値や状態は、正確な事実としてではなく、不確実性として記録します。

3. マッピングと実装

デザインを意味のあるモジュールにマッピングし、動作と外観が適合する既存のコンポーネントを選択します。再利用、独立した動作、または複雑さが正当化される場合にコンポーネントを抽出します。すべてのラッパーを分割したり、1 ページのためにデザインシステムを作成したりしないでください。

フォントと主要なアセットは早期に解決します。アセットのアスペクト比、透明度、適切な解像度を保持し、リポジトリのストレージ規約と意味のあるファイル名を使用します。ランタイムアセットがプロジェクトでサポートされている永続的な場所から読み込まれることを確認します。

提供されたバリアントと既存のプロジェクト動作から、流動的なサイジング、最大幅、折り返し、ブレークポイントを導出します。1 つのデザインサイズの場合、保守的な適応を実装し、デザイナー指定のレスポンシブレイアウトと区別します。要求されたプラットフォームでテストし、要求されていないデスクトップまたはモバイルの再設計を作成しないでください。

H5 とミニプログラムビルド間でスタイルを共有する Taro プロジェクトの場合は、ソーススタイルシートだけでなく、生成された WXSS も検査します。各ランタイムが利用可能な場合、要求されたランタイムでスペーシングと押された状態を検証します。

関連する動作ブランチのみを有効にします:

• ナビゲーション: 確立された遷移先とルーティング動作を使用します。
• フォームとコレクション: 既存のデータコントラクトを使用し、必要な検証、ローディング、空、エラー、成功状態を実装します。
• タブとフィルター: 証拠から状態の所有権と選択セマンティクスを確立します。ドラフト/コミット動作は、サポートされている場合のみ適用されます。
• テーブル: 配置と表示されている境界線を保持し、ターゲットビューポートに適したオーバーフローを提供します。
• オーバーレイまたはスティッキー UI: overlays-and-sticky.md を読んでください。
• モーションまたはメディア: 確認された動作を再現し、該当する場合はローディングとモーション削減を処理します。

4. 検証と反復

適切な実行中のサーバーを再利用するか、文書化された開発コマンドを利用可能なポートで起動します。利用可能なブラウザ自動化サーフェスを使用し、可能な場合はアプリ内ブラウザを優先し、次に認証済みの外部ブラウザまたはプロジェクトのブラウザツールを使用します。該当するルートまたは既存のコンポーネントプレビューを検査します。

視覚的な比較、該当するインタラクションチェック、完了基準については、acceptance-checklist.md を読んでください。局所的な調整の前に、大きな構造的な違いを修正します。各変更後、影響を受ける領域を検証し、最終的なターゲット全体のチェックを実行します。

該当するリポジトリチェックを実行し、最終的な差分を検査し、既存の失敗と導入された失敗を区別します。検証を実行するためだけに依存関係や広範なリファクタリングを追加しないでください。事前に存在するサーバーセッションを保持し、このタスクのために起動されたサーバーの状態を意図的なものにします。

復旧と完了

アクセスまたはランタイム検証が失敗した場合は、具体的なエラーを検査し、利用可能な関連する代替手段を試してください。新しい証拠なしに同じ失敗を繰り返さないでください。独立して完了できる作業を続け、正確なブロッカー、実装された内容、未検証のまま残っている内容を報告してください。欠落しているツールや資格情報は、検証成功の証拠ではありません。

要求されたターゲットが実装され、該当するチェックがパスし、既知の必要な欠陥が残っていない場合に完了します。軽微なレンダリングの違いは文書化される場合があります。未解決のレイアウトエラー、欠落している必要な動作、またはブロックされたブラウザチェックは、完全な完了として提示してはなりません。

簡潔に報告します:

• 実装されたターゲットとエントリポイント。該当する場合のみルートを含めます。
• 意味のある動作とコンポーネントの変更。
• プレビューの場所と実際に実行されたチェック。
• 重要な仮定、未解決の差異、またはブロッカー。