import

このワークフローを使って、Subframe で既存のビジュアルシステムを再現します。design は単一ページの再現に使用し、develop は Subframe のデザインをコードに移す際に使用します。

手順

1. インポートする前に、依頼されたソースの内容を確認します。Tailwind の設定、グローバル CSS、トークンモジュール、フォント宣言、アイコンアセット、再利用可能なコンポーネント、およびそれらの使用例を読みます。ウェブサイトの場合は、ホストのブラウジングツールを使って、レンダリングされた状態とアクセシブルなスタイルやアセットを確認します。スクリーンショットだけでは、トークンシステムやコンポーネントライブラリの全体像を把握できません。観察した値と推測した値を区別してください。
2. その一覧を移行先のテーマ、フォント、アイコン、コンポーネントと照合します。ソース名から Subframe の名前や ID への対応表を作成します。作業を始める前に依頼された一覧の総数を確定し、進捗を「いくつかのコンポーネント」ではなく「M 件中 N 件」のように報告できるようにします。ソースの一部にしかアクセスできない場合は、一覧が不完全であることを明記します。
3. テーマより先に必要なフォントを、コンポーネントより先に必要なアイコンをインポートします。コンポーネントを依頼された場合は、ビジュアルの基盤が整ってから依存関係の順に再現します。早い段階で代表的なコンポーネントを 1 つ検証して、翻訳に系統的な誤りがないか確認してから、依頼された一覧全体に進みます。
4. インポートした結果をソースと比較します。ライトモードとダークモードの表示、タイポグラフィ、寸法、アイコンの形状、依頼されたバリエーションや状態を確認します。誤ったパターンをライブラリ全体に広げる前に、不一致を修正します。
5. トークン、フォント、アイコン、コンポーネントの件数を個別に報告し、名前が変わった場合はソースから移行先への対応関係も示します。失敗した項目、未対応の詳細、近似した箇所、残っている項目を列挙します。妨げられない限り、依頼された範囲を最後まで進めます。最初のバッチが成功しても、ライブラリ全体のインポートが完了したことにはなりません。

フォントとアイコン

アップロードする前に、list_fonts を使ってソースのフォントファミリー、ウェイト、スタイルを照合します。不足しているファイルは create_asset_upload で準備し、ホストのファイル／ネットワークツールを通じてアップロードしてから、add_fonts または add_icons を実行します。アップロード結果を一覧と関連付け、失敗したファイルをインポート済みとして数えないようにします。

必要に応じて、アイコンコンポーネントやスプライトから SVG アートワークを抽出します。UI グリフには色を変更できるアイコンを選び、ブランドアートワークの作成時の色は保持します。インポート前に、未対応の SVG 機能を使用しているアートワークを確認します。見た目を保てる場合に限り簡略化し、それ以外の場合は制限事項として報告します。忠実度に不安がある場合は、get_icon_info を使って保存された結果を比較します。

名前の衝突には意図的に対処します。同一の移行先アセットは再利用し、既存アセットを置き換える意図がない限り、異なるアートワークには別の名前を付けます。ファイル名がそのまま正確な名前になると仮定せず、返されたインポート名をコンポーネントの参照に使用します。

テーマのマッピング

ソースのトークン名、エイリアス、グループ、モード値の記録を保持してください。目に見える色をいくつか抽出するのではなく、セマンティックな関係を維持してください。参照画面に表示されていないトークンも含め、要求されたトークンセット全体をインポートしてください。

対応している Tailwind CSS または設定ソースは、変更せずに import_theme に渡してください。適用する前にドライランを実行し、マッピングとスキップされた宣言を確認してください。それ以外の形式では、ソースのマッピングを保持しながら、インベントリを対応形式のソースまたは edit_theme の操作に変換してください。好みのパレットや文字サイズに合わせて値を再設計しないでください。

タイポグラフィを再インポートする前に、不足しているフォントを解決してください。スキップされた宣言をすべて確認してください。対応していないスペーシングトークン、解決されていない値、不足しているフォントは、正常にインポートされたものではなく、対処すべき不足項目です。可能な場合は、対応していない測定値をコンポーネントのスタイリングに保持し、編集可能なテーマトークンではないことを報告してください。

ライトモードの値を基本値に、ダークモードの値をダークオーバーライドにマッピングしてください。edit_theme でオーバーライドを書き込む前に、ダークモードを有効にしてください。両方のモードでエイリアスを確認してください。ダークモードの値を基本パレットに平坦化したり、独立したブランドテーマをダークモードと混同したりしないでください。

ソーステーマが複数ある場合は、list_themes を確認し、それぞれを明示的な移行先にマッピングしてください。共通のトークンIDには、テーマ間で一貫した意味を持たせてください。対応している場合は色のグループ分けを保持し、直接表現できないコレクションやグループの構造は報告してください。影響を受ける各テーマを get_theme で読み戻し、値、エイリアス、ダークオーバーライドを比較してください。同等の役割を統合する際は、既存のトークン参照を紐付けたままにしてください。トークンを削除または置換する前に、確認用の具体的なマッピングを用意してください。

コンポーネント

各コンポーネントの実装、スタイル、依存関係、代表的な使用例を確認してください。ソースコードは、ビジュアル構造、バリエーション、スロット、状態のスタイリングを維持するよう指示を添えて、コード参照として design_component に渡してください。利用できる場合はレンダリング済みの参照も含めてください。未解決のインポートが残るコードだけでは不十分です。

複合コンポーネントより先にプリミティブを構築してください。後続の参照や概要では、新しくインポートした Subframe コンポーネントを使用してください。移行先に一致するコンポーネントがすでに存在する場合は、まず比較し、既存のものを更新する意図があるなら別のコピーを作成せず edit_component を使用してください。

実行時のロジックではなく、ビジュアル上の契約を再現してください。API 呼び出しとアプリケーションの状態はソースアプリに残します。ビジュアルの状態は、コンポーネントのバリエーションまたは例として表現してください。不足している動作や対応していないスタイリングは、損失のない変換ができたと主張せず、インポートレポートに明記してください。

wait_for_jobs の完了後、各コンポーネントを読み戻し、screenshot_component を確認してください。インポートによって共有アセットまたはトークンが変更される場合は、screenshot_page で代表的な既存ページの使用例を確認してください。コンポーネントが存在する場合にのみ、インポート済みとして数えてください。ビジュアルで検証できなかったものは別途明記してください。曖昧な失敗が発生した後に再試行する場合は、重複を避けるため、先に移行先を確認してください。