Ixe1/ui-from-image

ミッション

提供された参照画像を視覚的な真実のソースとして扱います。

正確さはスピードに優先します。「大体合っている」で止まってはいけません。ページが単に機能するだけでタスクは完了ではありません。レンダリング結果が視覚的に近い一致であり、明らかな不一致が残っていないときに完了します。

検証パスは少なくよりも多く行うようにします。テキストが間違っている可能性、コントロールが密集している可能性、スペーシングが脆弱である可能性、レイアウトバグが特定のビューポートで隠れている可能性が現実的にある場合は、反復を続けてください。

このスキルの必須の検証および報告手順がすべて完了し、明確に述べられた軽微な不確実性を除いて既知の目に見える不一致が残っていない場合を除き、結果を「十分良い」、「出荷準備完了」などと説明しないでください。

デフォルトの出力

リポジトリがすでに別の構造を指定していない限り、以下を使用します：

• index.html
• styles.css
• script.js

既存のフロントエンド/フレームワークを適応する場合は、フレームワークが許す限りマークアップ、スタイリング、動作をクリーンに分離しながら、リポジトリのファイル構造に従ってください。

動作モード

• スタンドアロン作業の場合は、環境にユーザーが維持したいスタイリングシステムがすでに含まれていない限り、デフォルトでプレーンなHTML/CSS/JSを使用します。
• リポジトリに既存のTailwind/DaisyUIセットアップがある場合は、それを再利用します。
• リポジトリにすでに別の確立されたスタイリングシステムがある場合は、ユーザーが明示的に要求しない限り、競合する2番目のシステムとしてTailwind/DaisyUIを導入しないでください。
• Tailwind/DaisyUIがすでに利用可能であるか、明示的に要求された場合は、それらを設計権限ではなく実装ツールとして扱います。スクリーンショットと異なる場合はデフォルトを上書きします。
• まず、プライマリスクリーンショットの正確な参照寸法で忠実度を達成します。
• デスクトップWebページ作業の場合、狭いモックアップやPOCスクリーンショットを最終的な実際のページのデスクトップ幅として扱わないでください。参照サイズのパス後は、レイアウトを約1900px幅の実際のデスクトップビューポートに適応させることを優先し、スクロールバーと通常のブラウザクロムを考慮して、1920pxではなくおおよそ1900pxを許可します。
• 参照サイズバージョンが視覚的に近くなった後にのみ、タブレット/モバイルの動作を導出します。
• ユーザーが新しいまたは改訂されたスクリーンショットを提供した場合、最新のスクリーンショットが真実のソースになります。

高忠実度ルール

• レイアウト、スペーシング、タイポグラフィ、行の高さ、文字間隔、色、境界線、境界線の不透明度、シャドウ、グラデーション、境界線の半径、画像のトリミング/アスペクト比、視覚的階層を可能な限り厳密に一致させます。
• デフォルトが十分に近くない場合は、幅、高さ、最大幅、パディング、マージン、ギャップ、境界線の半径、フォントサイズ、行の高さ、トラッキング、シャドウに明示的な値を使用します。
• テキストの忠実度をレイアウト問題およびコンテンツ問題として扱います。テキストがクリップされている、密集している、切り捨てられている、不適切に折り返されている、または近くのコントロールを位置からずらしている場合、ページは完成していません。
• すべての目に見える詳細を必須として扱います。マイクロ詳細を含みます：
  • 小さなロゴとボタンアイコン
  • 検索アイコン
  • ドロップダウンカレット
  • ページネーションシェブロン
  • アクティブなナビゲーションの下線/グロー
  • ステータスドット
  • 箇条書きの色
  • カードアイコン
  • スター/お気に入りアイコン
  • 区切り線
  • 微妙な角丸の違い
  • テキストの不透明度の変更
• コントロール内の小さなアイコンやロゴの欠落は、軽微な省略ではなく、忠実度の失敗です。
• レスポンシブ性のために必要な場合、または参照が本当にあいまいな場合を除き、UIを再設計、簡略化、装飾、または「改善」しないでください。
• DaisyUIのタイポグラフィ、ボタンスタイル、入力スタイル、またはスペーシングスケールが参照と一致しない場合、それらに黙って依存しないでください。

既存のフロントエンド適応モード

既存のフロントエンドまたはデザインシステム内で作業する場合：

• 新しい構造を作成する前に、現在のコードベースを検査します。
• 既存のレイアウトシェル、共有コンポーネント、ユーティリティパターン、タイポグラフィトークン、スペーシングスケール、ブレークポイント、アイコン規則、テーマ変数を、それらが参照を忠実に表現できる場合は常に再利用します。
• ゼロから並行して実装を作成するよりも、近くの既存のページまたはセクションを適応させることを優先します。
• ユーザーが明示的に要求しない限り、重複するコンポーネント、競合するデザイントークン、または2番目のスタイリングシステムを導入しないでください。
• スクリーンショットが確立されたデザインシステムと競合する場合は、ユーザーがスクリーンショットが現在のデザイン言語を上書きすべきだと明示的に述べない限り、現在のトークン/コンポーネントと可能な限り一貫性を保ちながら、スクリーンショットのページレベルの構成を維持します。

参照の取り込みとブレークポイントの処理

• コーディング前に、各参照画像の正確な寸法を記録します。
• プライマリ忠実度パスでは、可能な限りCSSピクセルで正確な参照ビューポートサイズでページをレンダリングします。
• 参照デスクトップ画像が最新のデスクトップビューポートよりも実質的に狭い場合、その幅を最終的な実際のページのデスクトップ幅ではなく、構成/スタイルの参照として扱います。スクリーンショットの構造、階層、スペーシングの意図、視覚的言語を維持し、約1900pxのビューポート幅で実際のデスクトップ実装を拡張および検証します。
• デスクトップ/タブレット/モバイル用に複数の参照画像が提供されている場合、それぞれをそのブレークポイントの権威として扱います。
• デスクトップ参照のみが存在する場合、新しいセクションやインタラクションを発明せずに、階層、順序、視覚的バランスを維持することにより、タブレット/モバイルレイアウトを推測します。
• テキストが読み取れる場合は、句読点や小さなヘルパーラベルを含めて正確に再現します。
• テキストが不明瞭な場合は、最も近い妥当な近似値を使用し、不確実性を報告します。
• スクリーンショットがページ全体ではなくページの切り取られた領域を示している場合は、最初に表示されている領域に一致させます。

ビューポートの正直さとスケーリングの安全性

• ブラウザのズーム、OSのDPIスケーリング、デバイスピクセル比を、実装が許容しなければならない環境要因として扱い、レイアウトを歪める言い訳としては扱いません。
• Playwrightまたは同様のブラウザ自動化が利用可能な場合、明示的なビューポートサイズでキャプチャされた自動化制御のスクリーンショットを、比較のためのプライマリ忠実度参照として扱います。
• OSのDPIスケーリング、ブラウザのズーム、ウィンドウクロム、またはデスクトップコンポジタの動作が人間の画面表示に影響を与える可能性がある場合、ヘッド付きブラウザウィンドウをピクセル忠実度の真実のソースとして扱わないでください。
• 特にWindowsでは、デフォルト以外のデスクトップスケーリングまたはブラウザのズームにより、基盤となるページレイアウトがCSSピクセルで正しくても、ヘッド付きブラウザが視覚的に誤解を招く可能性があると想定します。
• Playwrightがchromeまたはmsedgeブラウザ/チャネルを開いたと報告した場合、それは依然としてPlaywright駆動の検証です。ブラウザ自動化が実際に放棄されない限り、これを「Playwrightからの切り替え」と説明しないでください。
• CSS zoom、ルートレベルの transform: scale(...)、合成ラッパースケーリング、または同様のビューポートハックを使用して、実装スクリーンショットを参照に近づけるために使用しないでください。
• ページ全体を縮小したり、キャンバスを拡大したりして、幅、密集、またはフォールド位置の不一致を「修正」しないでください。
• 実際のレイアウト変更でスクリーンショットの不一致を解決します：
  • 正しいコンテナ幅
  • 正しいグリッドとフレックスのサイズ設定
  • 正しいギャップとパディング
  • 正しいフォントサイズと行の高さ
  • 正しいコントロールの高さと固有の幅
  • 正しいレスポンシブブレークポイント
• ブラウザ固有の不一致が現れた場合は、最初に実装の無効なレイアウトの仮定、オーバーフロー、またはスケーリングハックを疑い、ユーザーの環境を非難する前に、追加のスクリーンショットパスで実装を調査します。
• ヘッド付きブラウザウィンドウと、調整されたビューポートで撮影されたPlaywrightスクリーンショットとの間に不一致がある場合は、まず忠実度作業のためにスクリーンショットを信頼し、差異をユーザーのマシンのせいにする前に、追加のスクリーンショットパスで実装を調査します。
• 忠実度ステータスを報告するときは、以下を区別します：
  • ユーザー/ブラウザのズーム設定によって引き起こされる予想されるリフロー差、および
  • 水平オーバーフロー、不正な幅計算、壊れた折り返し、または脆弱なブレークポイント動作などの実際のレイアウトバグ。

事前チェックリスト

実装する前に、以下を明示的に検査して棚卸しします：

1. ページセクションとその順序
2. グリッド/列構造とおおよその幅の比率
3. 主要なコンテナとカードの境界
4. すべてのテキストブロックとラベル
5. すべての表示コントロールとインタラクティブな状態
6. すべてのアイコン、ロゴ、バッジ、チップ、ステータスドット、セパレーター、装飾マーク
7. すべての画像アセットと背景グラフィック
8. タイポグラフィグループ（ヒーロータイトル、本文コピー、ピル、ボタン、テーブルヘッダー、テーブル行、サイドカード、通知など）
9. プライマリ、セカンダリ、ミュート、成功、警告、危険、アクセントの色
10. 推定されるレスポンシブの意図
11. コピーの長さ、チップの数、またはコントロール密度が密集する可能性が高い領域
12. 参照ブレークポイントで1行に留まらなければならない行またはパネル

コードを開始する前に、視覚的に意味のあるすべての要素の作業メンタルマップができるまで待ちます。

タイポグラフィ監査

タイポグラフィは第一級の忠実度ターゲットです。

• 最初にリポジトリの既存のフォントソースを検査します：
  • グローバルCSS
  • Tailwind設定
  • DaisyUIテーマ設定
  • デザイントークン
  • 既存のページコンポーネント
  • ローカルフォントファイル
• 既存のプロジェクトフォントが参照と一致する場合は、それを使用します。
• 参照がカスタムまたは非デフォルトのフォントを使用しているように見え、正確なフォントが利用できない場合は、最も近い利用可能なオプションを選択し、その制限を明示的に報告します。
• チェックせずにデフォルトのDaisyUI/bodyタイポグラフィに頼らないでください。
• 各視覚グループに明示的にタイポグラフィを設定します：
  • ロゴテキスト
  • ナビゲーションリンク
  • ピル/バッジ
  • ヒーロー見出し
  • リード段落
  • 統計ラベル
  • 統計値
  • ヘルパーテキスト
  • フィルターチップ
  • フォームラベル
  • テーブルヘッダー
  • テーブル行
  • サイドバーの見出し
  • 通知/タイムスタンプ
  • プライマリおよびセカンダリボタン
• フォントファミリーだけでなく、以下もチェックします：
  • サイズ
  • ウェイト
  • 行の高さ
  • 文字間隔
  • 大文字小文字
  • 色/不透明度
• 参照幅でのテキストの折り返しと改行を検証します。見出しまたは段落がスクリーンショットと異なる方法で折り返されている場合は、修正します。
• コントロールと密集したUIのテキスト整合性を検証します：
  • 意図しない切り捨てがないこと
  • クリップされたアセンダー/ディセンダーがないこと
  • 不適切な行の高さまたはコントロールの高さによる垂直方向のつぶれがないこと
  • ラベル/ヘルパーテキストの衝突がないこと
  • プレースホルダーテキストがフィールドからはみ出していないこと

アイコンと完全性の監査

ページが完了したと宣言する前に、参照からのすべての視覚的に意味のあるアイコンまたはマークがDOMで表現されていることを確認します。

これには以下が含まれます：

• ロゴマーク
• ボタン内のブランドアイコン
• 検索アイコン
• ドロップダウンカレット
• 統計カードアイコン
• ステータスインジケーター
• マップ/通知箇条書き
• テーブルお気に入りアイコン
• ページネーション矢印
• 閉じる/リセット/フィルターアイコン
• 微妙なインラインシンボル

ルール：

• 小さなUIアイコンはアセットとしてカウントされ、省略してはなりません。
• 小さなUIアイコンには、既存のリポジトリアイコンまたはシンプルなインラインSVGを優先します。
• リポジトリがすでに使用しているか、ユーザーが明示的に要求しない限り、新しいアイコンライブラリを追加しないでください。
• UIコントロールで使用される一般的なブランドマーク（Discordなど）には、リポジトリがすでに適切なアセットを持っていない限り、クリーンなインラインSVGまたは既存のアイコンコンポーネントを使用します。

レイアウトフィッティングと密集ルール

参照ブレークポイントに対して：

• レスポンシブ適応を行う前に、スクリーンショットの構成を再現します。
• 時期尚早な再設計、削除、縮小、または主要グループのリフローによって密集を解決しないでください。
• ページ全体をCSSでスケーリングしたり、ブラウザのズームの仮定に依存したりして密集を解決しないでください。
• 最初に忠実度を維持するオプションを使い果たします：
  • 参照ビューポートサイズに一致させる
  • 正しいコンテナ幅とサイド列の幅
  • 測定値にギャップを狭めたり広げたりする
  • 正しいフォントサイズと行の高さを使用する
  • 正しいコントロール幅と最小幅を使用する
  • すべてを均等に分散する代わりに、各グリッド列に正しいトラックサイズを使用する
  • 隣接する要素を縮小する前に、密集したコントロールに実際に必要な幅を与える
  • スクリーンショットがすでに折り返しを暗示している場合にのみ折り返しを使用する
  • 参照が実際に複数の行を使用しているかどうかを検査する
• 参照ブレークポイントでコントロールを追加の行に移動するのは、以下の場合のみ：
  • スクリーンショットが明示的に複数の行を示している、または
  • ユーザーが更新された構造を示す改訂されたスクリーンショットを提供する。
• パス後もコントロールが密集しているように感じられる場合は、比率がまだ間違っていると想定し、反復を続けます。密集を「十分良い」として正規化しないでください。
• 狭いブレークポイントでは、階層と視覚的バランスを維持しながらクリーンにリフローします。

色、サーフェス、エフェクト監査

• プライマリサーフェス、セカンダリサーフェス、ミュートサーフェス、境界線、グロー、シャドウ、グラデーション、テキストの不透明度を可能な限り厳密に一致させます。
• 可能な場合は、新しい値を発明する代わりに、参照から色をサンプリングまたは推定します。
• 以下に注意を払います：
  • 背景グラデーション
  • 微妙な境界線のアルファ
  • パネルの透明度
  • 参照で表示されているホバー/アクティブの強調
  • メインコンテンツとサイドバーカードのコントラストの違い
  • バッジ、ライブインジケーター、ボタン、ハイライトにわたるアクセントカラーの一貫性

アセット処理ワークフロー

まず、ページに必要なすべての表示アセットを棚卸しします：

• ロゴ
• ヒーロー画像
• サムネイル/カード
• マップ
• アバター
• アイコン
• イラスト
• 背景グラフィック
• その他の非テキスト視覚要素

各アセットについて、正確に1つのパスを選択します。

1) ユーザーがアセットを提供した

• 使用前に視覚的に検査します。
• 適切な場所で使用します。
• 参照構成に一致するように、必要に応じてトリミング、リサイズ、パディング、トリミング、またはマスキングします。
• アスペクト比を維持し、決して歪めないでください。
• 必要に応じて object-fit: cover または contain を使用します。
• アセットが低解像度またはその他の点で不完全な場合は、可能な限り近づけ、制限をメモします。

2) アセットが欠落しており、ユーザーが生成を要求していない

• 正しいおおよその寸法、アスペクト比、境界線の半径、配置、視覚的重量を持つ、明確にラベル付けされたプレースホルダーを使用します。
• 自分で一時的な代替アセットを作成または合成する場合は、...

[翻訳のため切り捨てられました]