figma-to-swiftui

Figma から SwiftUI へ

要求された Figma デザインに一致し、既存のアプリに適合するネイティブ SwiftUI を提供します。生成された Web コードは、移植するコードではなく、デザインの証拠として扱ってください。要求された変更以外の部分では、プロジェクトのアーキテクチャ、コンポーネント API、および動作を維持します。

スコープを選択する

ユーザーのリクエストと、あればブリーフを使用して、対象の画面、アクション、状態、およびサポートするデバイスを確定します。ブリーフは動作とスコープを定義し、Figma はそのスコープ内のビジュアルを定義します。ブリーフをデザインと突き合わせて調整する必要がある場合は、source-document.md を参照してください。

• 画面またはコンポーネントを実装する: 関連するデザインの証拠とプロジェクトのコンテキストを収集し、完了まで実装します。
• 既存の UI を更新する: 影響を受けるビューと依存関係を調査し、adaptation-workflow.md を使用して、動作を維持しながら視覚的な差異を解消します。
• 計画、トークンのマッピング、またはアセットのエクスポート: 画面を自動的に実装したり、共有デザインシステムを変更したりすることなく、その成果物を提供します。

定型的な選択は、コードベースとデザインから解決します。未解決の選択がスコープ、動作、または対象のデザインを大きく変える場合は質問してください。それが明確になるまで、独立した作業は続けてください。計画や差異のチェックリストは作業コンテキストであり、必須の承認ゲートではありません。

必要な証拠を収集する

利用可能な Figma ツールを、その現在のスキーマに従って使用してください。すべてのサーバーが同じツールやパラメータを公開していると想定しないでください。

• /design/ または従来の /file/ リンクの場合は、ファイルキーを抽出し、node-id=3166-70147 を 3166:70147 に正規化します。サポートされている場合、デスクトップでの選択から対象を取得できます。プロトタイプまたはボードのリンクの場合は、可能であれば基になるデザインフレームを解決します。そうでなければ、デザインリンクを要求してください。
• 明確な画面またはコンポーネントの場合は、デザインコンテキストとビジュアルリファレンスを取得します。提供された、またはすでに取得済みの証拠が十分かつ最新である場合は、それを再利用してください。
• ルート、ページ、または曖昧なフローの場合は、メタデータを使用して詳細なコンテキストを取得する前に関連するフレームを特定します。screen-discovery.md を参照してください。
• 大きすぎる、または切り詰められたコンテキストは、同じ失敗したリクエストを繰り返すのではなく、意味のある子ノードに分割してください。ツールの選択とキャッシュのスコープについては、fetch-strategy.md を参照してください。
• 既存のコンポーネント、トークン、アセット、デプロイターゲット、および関連する依存関係を調査します。利用可能で有用な場合は Code Connect のマッピングを読み、マッピングされた SwiftUI コンポーネントが要求されたバリアントに適合することを確認してください。

Figma へのアクセスが失敗した場合は、figma-mcp-setup.md を使用してください。利用可能な証拠に基づいて作業を続け、不足しているデザインの詳細をでっち上げるのではなく、何がブロックされたままかを明らかにしてください。

設計とプラットフォームの動作を維持する

• 利用可能な場合は正確な設計値を使用し、ネイティブレンダリングの差異を考慮してください。同じ意図を表現するプロジェクトのトークンとコンポーネントを優先し、要求された視覚的な変更を不一致なトークンで黙って置き換えたり、共有トークンをグローバルに変更したりしないでください。
• 作成されたアイコン、ロゴ、イラストには実際の Figma アセットを使用してください。ユーザーの指示なしに SF Symbols、テキスト、または近似の描画で代用しないでください。構造的なジオメトリは SwiftUI で構いませんが、データ駆動型の画像はアプリの画像パイプラインを使用します。
• キーボード、ステータスバー、ホームインジケーターなどのシステムクロームは iOS にレンダリングさせてください。設計に合致する範囲で、ネイティブのナビゲーション、コントロールのセマンティクス、セーフエリア、アクセシビリティを維持してください。
• 画像の読み込み、ローカライズ、状態、アニメーションについては、関連するプロジェクトの規約に従ってください。規約が存在しない場合は、スコープ内で適切なネイティブ実装を選択してください。ライブラリの追加は前提条件ではありません。

現在の作業に必要な参照のみを読み込んでください:

必要事項	参照
エクスポートされたアートワーク、PNG の検証、アセットカタログのスケールとティント	asset-handling.md
Figma 変数、セマンティックトークン、タイポグラフィのメトリクス	design-token-mapping.md
Auto Layout、サイジング、エフェクト、トランジション	layout-translation.md
複数のデバイスフレームまたは適応型コンテナレイアウト	responsive-layout.md
コンポーネントの状態、サイズ、スタイル、オプションのコンテンツ	component-variants.md
正確な値の抽出または視覚的な不一致の診断	visual-fidelity.md

要求された作業を完了する

実装については、指定されたローディング、エラー、空、無効の状態を含め、要求された UI、アセット、動作を完成させてください。関連するローカルチェックを続けて実行し、変更によって生じた問題を修正してください。作業に見合った検証を選択してください。利用可能な場合はコード変更に対するビルド、プレビューまたはシミュレーターが利用可能な場合は視覚的な変更に対するレンダリング比較を行います。チェックを省略するという明示的な要求を尊重してください。検証方法の選択を日常的な質問にしないでください。

視覚的な比較には、同じ画面状態、外観、デバイス/コンテナサイズを使用してください。要求された動作が機能し、観察された重大な不一致が解消されたら、反復を停止してください。何をチェックしたか、および残っている制限事項を述べてください。コードの検査だけでは視覚的な忠実性は確立されません。

Code Connect のマッピングの登録または更新は、その外部変更がユーザーの要求または既存の承認の一部である場合にのみ行ってください。実装タスク自体は、マッピングの公開を必要としません。