ui-from-image

ミッション

提供された参照画像を、視覚的な正解として扱ってください。

速度よりも正確さを優先してください。「だいたい合っている」で終わらせないでください。ページが動くだけでは完了ではありません。レンダリング結果が参照画像に視覚的に近く、明らかな不一致がなくなった時点で完了です。

検証回数は少なくするより、多くすることを優先してください。テキストに誤りがある可能性、コントロールが窮屈な可能性、あるいは1つのビューポートでは隠れているレイアウトの不具合が現実的に考えられる場合は、検証と修正を続けてください。

このスキルで必須の検証と報告がすべて完了し、明示した軽微な不確実性を除いて既知の視覚的な不一致がなくなるまで、結果を「十分良い」「リリース準備完了」などと表現しないでください。

デフォルトの出力

リポジトリで別の構成が定められていない場合は、以下を使用してください。

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

既存のフロントエンドやフレームワークに合わせる場合は、マークアップ、スタイル、動作を可能な範囲で明確に分離しつつ、リポジトリのファイル構成に従ってください。

作業モード

• 単独で作業する場合は、環境にユーザーが維持したいスタイリングシステムがすでに含まれていない限り、プレーンな HTML/CSS/JS をデフォルトとして使用してください。
• 既存の Tailwind/DaisyUI セットアップがある場合は、それを再利用してください。
• リポジトリに別の確立されたスタイリングシステムがすでにある場合、ユーザーから明示的な依頼がない限り、競合する第 2 のシステムとして Tailwind/DaisyUI を導入しないでください。
• Tailwind/DaisyUI がすでに利用可能、または明示的に指定されている場合は、デザインの基準ではなく実装ツールとして扱ってください。スクリーンショットと異なる場合は、デフォルト設定を上書きしてください。
• まず、プライマリスクリーンショットの正確な参照サイズで忠実に再現してください。
• デスクトップのウェブページでは、狭いモックアップや POC のスクリーンショットを、最終的な実ページのデスクトップ幅として扱わないでください。参照サイズでの再現が近づいた後は、スクロールバーと通常のブラウザー表示領域を考慮して、1920px ではなくおよそ 1900px の幅を想定し、実際のデスクトップビューポートに合わせて調整してください。
• 参照サイズでの表示が十分近くなってから、タブレットやモバイル向けの動作を導入してください。
• ユーザーが新しいスクリーンショットや改訂版を提供した場合は、最新のスクリーンショットを正解として扱ってください。

高い忠実度を実現するためのルール

• レイアウト、間隔、タイポグラフィ、行の高さ、文字間隔、色、枠線、枠線の不透明度、影、グラデーション、角丸、画像の切り抜きやアスペクト比、視覚的な階層をできる限り正確に合わせてください。
• デフォルト値では十分に一致しない場合は、幅、高さ、最大幅、パディング、マージン、ギャップ、角丸、フォントサイズ、行の高さ、文字間隔、影に明示的な値を指定してください。
• テキストの忠実度は、内容だけでなくレイアウトの問題としても扱ってください。テキストが切れている、窮屈である、省略されている、折り返しが不適切である、または周囲のコントロールの位置がずれている場合、ページは未完成です。
• データの可視化や比率に基づく図形は、装飾的な近似ではなく、レイアウト上重要な UI として扱ってください。チャートのプロット領域、軸、凡例、セグメント幅、地図領域、ファネル、ゲージ、タイムライン、図形の形状といった要素は、ユーザーが参照画像と同じインターフェースだと認識できる程度に、比率と位置を正確に合わせてください。
• 小さなロゴやボタンのアイコン、検索アイコン、ドロップダウンのキャレット、ページネーションの山形、選択中のナビゲーションの下線やグロー、ステータスドット、箇条書きの色、カードアイコン、お気に入りアイコン、区切り線、微妙な角丸の違い、テキストの不透明度の変化など、目に見える細部はすべて必須です。
• コントロール内の小さなアイコンやロゴが欠けている場合も、忠実度の不足であり、軽微な省略ではありません。
• レスポンシブ対応が必要な場合や、参照画像が本当に曖昧な場合を除き、UI を再設計、簡略化、装飾したり、「改善」したりしないでください。
• DaisyUI のタイポグラフィ、ボタン、入力欄、間隔のスタイルが参照画像と一致しない場合、それらを暗黙に頼りにしないでください。

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

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

• 新しい構造を作成する前に、現在のコードベースを確認してください。
• 参考画像を忠実に再現できる場合は、既存のレイアウトシェル、共有コンポーネント、ユーティリティのパターン、タイポグラフィのトークン、スペーシングのスケール、ブレークポイント、アイコンの規約、テーマ変数を再利用してください。
• 新規に一から並行して実装するよりも、近くにある既存のページやセクションを調整してください。
• ユーザーから明示的に指示されない限り、重複するコンポーネント、競合するデザイントークン、2つ目のスタイリングシステムを導入しないでください。
• スクリーンショットが確立されたデザインシステムと矛盾する場合は、ユーザーからスクリーンショットを現在のデザイン言語より優先するよう明示的に指示されない限り、現在のトークンやコンポーネントとの一貫性を可能な限り保ちながら、スクリーンショットのページレベルの構成を維持してください。

参考画像の取り込みとブレークポイントへの対応

• コーディング前に、各参考画像の正確な寸法を記録してください。
• 精度を優先する最初の作業では、可能な限り、CSS ピクセル単位で参考画像と同じビューポートサイズでページをレンダリングしてください。
• デスクトップの参考画像の幅が現代的なデスクトップのビューポートよりかなり狭い場合は、その幅を最終的な実ページのデスクトップ幅ではなく、構成やスタイルの参考として扱ってください。スクリーンショットの構造、階層、スペーシングの意図、ビジュアル表現を保ったうえで、実際のデスクトップ実装を約 1900px のビューポート幅に拡張し、検証してください。
• デスクトップ／タブレット／モバイル向けに複数の参考画像が提供されている場合は、それぞれを該当するブレークポイントの基準として扱ってください。
• デスクトップ向けの参考画像しかない場合は、新しいセクションや操作を追加せず、階層、順序、視覚的なバランスを保ちながら、タブレット／モバイルのレイアウトを推測してください。
• テキストが判読できる場合は、句読点や小さな補助ラベルも含め、正確に再現してください。
• テキストが不明瞭な場合は、最も妥当な表現を使用し、不確かな箇所を報告してください。
• スクリーンショットがページ全体ではなく一部を切り取ったものである場合は、まず表示されている範囲を再現してください。

ビューポートの忠実性とスケーリングの安全性

• ブラウザーのズーム、OS の DPI スケーリング、デバイスピクセル比は、レイアウトを歪める言い訳ではなく、実装が許容すべき環境要因として扱ってください。
• Playwright などのブラウザー自動化が利用できる場合は、明示的に指定したビューポートサイズで自動化環境からキャプチャしたスクリーンショットを、比較における主要な忠実性の基準として扱ってください。
• OS の DPI スケーリング、ブラウザーのズーム、ウィンドウの装飾、デスクトップコンポジターの動作が人間の画面上の見え方に影響する場合があるため、ピクセル単位の忠実性を判断する際に、ウィンドウ表示のブラウザーを信頼できる基準として扱わないでください。
• 特に Windows では、デスクトップのスケーリングやブラウザーのズームが既定値以外の場合、CSS ピクセル上のページレイアウトが正しくても、ウィンドウ表示のブラウザーが視覚的に誤解を招くことがあると想定してください。
• Playwright が chrome または msedge ブラウザー／チャンネルを開いたと報告した場合も、それは Playwright による検証です。実際にブラウザー自動化を中止していない限り、「Playwright の使用をやめた」と説明しないでください。
• 実装のスクリーンショットを参照画像に近づけるために、CSS の zoom、ルート要素への transform: scale(...)、合成的なラッパーによるスケーリング、その他の同様のビューポートハックを使用しないでください。
• ページ全体を縮小したり、キャンバスを拡大したりして、幅、窮屈さ、スクロール位置の不一致を「修正」しないでください。
• スクリーンショットの不一致は、実際のレイアウト変更で解決してください。
  • コンテナーの幅を正しくする
  • グリッドとフレックスのサイズを正しくする
  • ギャップとパディングを正しくする
  • フォントサイズと行の高さを正しくする
  • コントロールの高さと固有の幅を正しくする
  • レスポンシブブレークポイントを正しくする
• ブラウザー固有の不一致が発生した場合は、まずユーザーの環境を疑うのではなく、実装における不適切なレイアウトの前提、オーバーフロー、スケーリングハックを疑ってください。
• ウィンドウ表示のブラウザーと、調整済みのビューポートで撮影した Playwright のスクリーンショットに不一致がある場合、忠実性の確認ではまずスクリーンショットを信頼し、その差をユーザーのマシンのせいにする前に、追加のスクリーンショットを取得して実装を調査してください。
• 忠実性の状況を報告する際は、次の項目を区別してください。
  • ユーザー／ブラウザーのズーム設定によって生じる想定内のリフローの違い
  • 水平方向のオーバーフロー、不正確な幅の計算、折り返しの不具合、不安定なブレークポイント動作など、実際のレイアウトバグ

スクロール耐性の確認

固定表示またはスティッキー表示のサイドバー、ツールパネル、インスペクター、メニュー、その他ビューポートの高さに依存する領域を含むレイアウトの場合：

• ビューポートよりコンテンツが高いすべての領域を、それぞれ個別にスクロールできることを確認してください。
• 固定／スティッキーパネルでは height: 100vh のみに依存せず、コンテンツが利用可能な高さを超える可能性がある場合は適切な overflow-y: auto を追加してください。
• 全高のサイドバーやツールパネルを含むデザインでは、少なくとも 1 種類の低いデスクトップビューポート、またはズームに似た条件でテストしてください。
• 下部のコントロール、フッターのアクション、アカウントカード、折りたたみボタン、セカンダリナビゲーションにアクセスできることを確認してください。
• パネル内のコンテンツにアクセスできない場合は、視覚的な不一致にとどまらず、機能上のレイアウトバグとして扱ってください。

固定ナビゲーションとパネル幅

固定表示のナビゲーション、サイドバー、レール、インスペクター、ツールパネルの場合：

• デスクトップと幅広／ズームに似たデスクトップ幅で、展開時のラベルが内部の水平スクロールなしで収まることを確認してください。
• document.documentElement だけでなく、パネル自体の内部で水平方向のオーバーフローを確認してください。
• ラベル、アイコン、バッジ、カウンター、アカウントコントロール、折りたたみボタン、フッターのアクションを含むパネルは、対象を絞った切り抜き画像をキャプチャしてください。
• パネルのコンテンツが押しつぶされたり、水平スクロールバーが発生したりするのを許すのではなく、パネルの固有幅を十分に確保し、ラベルには nowrap／省略表示を使用し、パネル内で個別にスクロールできるようにし、折りたたみのブレークポイントを明示してください。
• 折りたたみ状態やアイコンのみの状態への切り替えが早すぎたり遅すぎたり、テキストが収まらなくなったことだけを理由に発生したりしないことを確認してください。
• 切り詰められたラベル、パネル内部の水平スクロールバー、隠れたフッターコントロール、アイコン／バッジと衝突するラベルは、レイアウトの不具合として扱ってください。

データテーブルとパネルのフッター

カード、パネル、データテーブル、グリッド、リストモジュールについては、次の点を確認します。

• ページ全体のオーバーフローだけでなく、内部のスクロールコンテナーも確認します。ドキュメントの幅に問題がなくても、テーブルやグリッド自体に水平スクロールバーがある場合があります。
• フッターリンク、CTA、ページネーション、サマリー行、セカンダリーアクションが、カードやパネルの境界内に視覚的に収まっていることを確認します。
• 多数の列、折り返しなしのテキスト、アバター、バッジ、行メニュー、ページネーション、フッター CTA があるテーブル／リストパネルは、該当箇所に絞った切り抜きを取得します。
• 意図しないオーバーフローではなく、列幅の明示的な指定、テーブルレイアウトのルール、レスポンシブな行カードの代替表示、またはスクロール可能であることが視覚的に分かる意図的な水平スクロールを優先します。
• 意図せず発生した内部の水平スクロールバー、切り取られた行アクションのアイコン、アクションセルのオーバーフローによる不要なテキストの省略記号、パネルの枠線から下にはみ出したフッターリンクは、不合格として扱います。

実装前チェックリスト

実装を始める前に、次の項目を明示的に確認し、一覧にします。

1. ページのセクションとその順序
2. グリッド／列の構造とおおよその幅の比率
3. 主なコンテナーとカードの境界
4. すべてのテキストブロックとラベル
5. 表示されるすべてのコントロールとインタラクティブな状態
6. すべてのアイコン、ロゴ、バッジ、チップ、ステータスドット、区切り線、装飾的なマーク
7. すべての画像アセットと背景グラフィック
8. タイポグラフィのグループ分け（ヒーロータイトル、本文、ピル、ボタン、テーブルヘッダー、テーブルの行、サイドカード、通知など）
9. プライマリー、セカンダリー、ミュート、成功、警告、危険、アクセントの各色
10. 想定されるレスポンシブ表示
11. コピーの長さ、チップの数、コントロールの密度によって窮屈になりそうな領域
12. 参照ブレークポイントで1行に収める必要がある行やパネル
13. すべてのデータ可視化。そのカードの境界、プロット領域の境界、軸、ラベル、グリッド線、凡例、コントロール、マーカーの位置、系列の形状、余白を含みます。
14. すべての比例図や図表。各セグメントの相対的なサイズ、先細りの方向、配置、ラベル、塗り、線、周囲の余白を含みます。
15. ナビゲーションまたはツールバーの各アイコンを、参照画像と1つずつ照合します。アクティブ状態、バッジの配置、線の太さ、グリフ自体が同じ概念を表しているかも確認します。

視覚的に意味のある要素をすべて把握し、全体像を頭の中で整理するまで、コーディングを始めないでください。

タイポグラフィの監査

タイポグラフィは、忠実性を左右する重要な要素です。

• まず、リポジトリ内に既存のフォントソースがないか確認してください。
  • グローバル CSS
  • Tailwind の設定
  • DaisyUI のテーマ設定
  • デザイントークン
  • 既存のページコンポーネント
  • ローカルのフォントファイル
• 既存のプロジェクトフォントが参照画像に合っている場合は、それを使用してください。
• 参照画像でカスタムフォントまたは標準以外のフォントが使われているように見え、同じフォントを利用できない場合は、最も近いフォントを選び、その制約を明示的に報告してください。
• 確認せずに、DaisyUI の標準的なフォントや本文用フォントを使わないでください。
• 宣言された font-family だけでなく、実際に描画される代替フォントも確認してください。最初に指定したフォントがインストールされていない場合があり、インストール済みのフォントでも参照画像と比べて、文字幅が広い、狭い、太い、または柔らかい印象になることがあります。
• 次の各視覚グループには、それぞれ明示的にタイポグラフィを設定してください。
  • ロゴのテキスト
  • ナビゲーションリンク
  • ピル／バッジ
  • ヒーロー見出し
  • リード文
  • 統計ラベル
  • 統計値
  • 補助テキスト
  • フィルターチップ
  • フォームラベル
  • テーブルヘッダー
  • テーブル行
  • サイドバー見出し
  • 通知／タイムスタンプ
  • プライマリボタンとセカンダリボタン
• フォントファミリーだけでなく、次の点も確認してください。
  • サイズ
  • 太さ
  • 行の高さ
  • 字間
  • 見た目の字幅／文字の収まり
  • 大文字・小文字
  • 色／不透明度
• 参照画像ではっきり確認できる場合を除き、人工的なトラッキングや広い字間は避けてください。大きな数字、見出し、テーブルのテキスト、ナビゲーションラベルに余分な字間を加えると、UI が拡大表示されたように見え、不要な切り詰めが発生することがあります。
• 密度の高いダッシュボード、フォーム、テーブル、ナビゲーション、運用系 UI では、よく使われるラベルや値の横幅が参照画像と同程度か比較してください。テキストが広がりすぎている場合は、レイアウトを変える前に、より近いシステムフォントスタックを試す、不要な字間をなくす、太さを下げる、またはグループごとにフォントサイズを調整してください。
• 参照画像の幅で、テキストの折り返しと改行位置を確認してください。見出しや段落の折り返しがスクリーンショットと異なる場合は修正してください。
• コントロールや情報量の多い UI では、テキストが正しく表示されることを確認してください。
  • 意図しない切り詰めがない
  • アセンダー／ディセンダーが切れない
  • 行の高さやコントロールの高さの誤りによる縦方向の圧縮がない
  • ラベルと補助テキストが重ならない
  • プレースホルダーテキストが入力欄からはみ出さない

アイコンと完全性の監査

ページの完成を宣言する前に、参照元にある視覚的に意味のあるアイコンやマークがすべて DOM に反映されていることを確認してください。

以下が含まれます。

• ロゴマーク
• サイドバー、タブバー、ツールバー、コマンドパレットのアイコン
• ボタン内のブランドアイコン
• 検索アイコン
• ドロップダウンのキャレット
• 統計カードのアイコン
• ステータスインジケーター
• 行、テーブル、リスト、カードのアクションアイコン
• 地図／通知の箇条書き記号
• テーブルのお気に入りアイコン
• ページネーションの矢印
• 閉じる／リセット／フィルターのアイコン
• 目立たないインライン記号

ルール：

• 小さな UI アイコンもアセットとして扱い、省略してはいけません。
• ナビゲーションアイコンは項目ごとに監査してください。参照元のグリフが実際に判読できない場合に限り、汎用的な代替アイコンを使用できます。それ以外の場合は、同じ視覚的メタファー、線の太さ、サイズ、配置に合わせてください。
• 繰り返し使われる行アクションアイコンは、セットとして、また個別にも監査してください。コメントと編集、開く／外部リンクとコピー、削除とオーバーフローなど、意図された意味が保たれていることを確認してください。見た目が似ていても意味が異なるコントロールに置き換えてはいけません。
• ウェブページやウェブアプリでは、既存のリポジトリ内のアイコンを優先してください。単純なインライン SVG を使うのは、グリフを正確に再現でき、参照元との一致を重点的に目視確認した場合に限ります。
• 複雑なアイコン、細部まで描かれたピクトグラム、独自に描かれたボタン、ブランド付きコントロール、バッジ、メダル、タブ、トグル、ゲーム風のコントロール、独自の UI 装飾、テクスチャのある表面など、視覚的に特徴のある UI 要素は、SVG／コードでの再現では壊れやすく、見た目が明らかに異なる場合、アセットとして扱ってください。
• 認識しやすい輪郭、抜き穴、星形の突起、曲線の弧、ブランドらしい形状、特定の視覚的メタファーを持つグリフには、アイコンを CSS の疑似要素、境界線、clip-path のトリックで表現しないでください。アイコンが参照元と同じように見えるよう、インライン SVG または既存のアイコンコンポーネントを使用してください。
• リポジトリですでに使用されている場合、またはユーザーから明示的に求められている場合を除き、新しいアイコンライブラリを追加しないでください。
• UI コントロールで使われる一般的なブランドマーク（Discord など）には、リポジトリに適切なアセットがすでにある場合を除き、整ったインライン SVG または既存のアイコンコンポーネントを使用してください。

データの可視化と図表の忠実な再現

グラフ、図表、情報量の多い分析用グラフィックには、個別に明示的な確認工程が必要です。単に「グラフのように見える」実装にまとめないでください。

グラフのような領域ごとに、次の項目を記録して再現してください。

• カードのサイズとグラフ領域のサイズをそれぞれ記録する
• プロット領域の幅、高さ、カードの端からのインセット
• 凡例の位置、凡例の色見本のスタイル、タイトルまたはプロットからの間隔
• 軸ラベルの数、軸の位置、目盛りラベルの位置、グリッド線の数
• 系列の色、線幅、破線のパターン、曲線の形状、マーカーのサイズ、データ点のおおよその軌跡
• 分割ボタン、ドロップダウン、ズームコントロール、範囲選択ボタン、ツールバーなど、グラフ周辺のコントロールの配置
• プロット下部のサマリー行／フッター行（列幅や区切り線を含む）

比率を表すグラフィックごとに、次の項目を記録して再現してください。

• 外接バウンディングボックスとカード内での配置
• セグメントの数、各セグメントの相対的な高さと幅、先細り、拡大、重なり、段状になっているかどうか
• 各セグメント内または外でのラベルの配置
• 色の順序、不透明度、境界線、影、セグメント間の間隔
• 付随するラベル、吹き出しボックス、凡例、サイド指標とグラフィックとの距離
• テキストが意図したセグメント内に完全に収まっているか、意図的に外に配置されているか。ラベルのはみ出し、クリッピング、詰め込みがないこと

ドーナツ、円グラフ、ゲージ、円形の進捗インジケーターなどの円形グラフについて：

• 中央のラベルは、グラフの形状とは別に確認してください。
• 中央ラベルのフォントサイズ、太さ、行の高さ、垂直方向の配置を参照画像に合わせてください。
• 参照時のビューポートおよびレスポンシブのブレークポイントで、ラベルが内円に無理なく収まるようにしてください。
• 中央ラベルの配置には、明示的な flex／grid の中央揃えと行の高さの指定を優先してください。
• 中央ラベルが窮屈、大きすぎる、中心からずれている、またはクリッピングされている場合は、グラフが一致したと判断する前に、タイポグラフィと内半径を調整してください。

実装ガイダンス：

• ファネル、ピラミッド、ゲージ、円形グラフ、マップ、ノードグラフ、複雑なタイムライン、アイコン風の図表など、長方形以外の比率を表すグラフィックには、通常のレイアウトボックスで参照画像と完全に一致させられる場合を除き、インライン SVG を使用してください。
• セグメントの幅、テーパー角度、区切りの間隔、ラベルの配置を忠実に再現する必要がある場合は、複雑な形状を積み重ねた div、疑似要素、ボーダー三角形、CSS の clip-path で近似しないでください。これらの手法を使用できるのは、スクリーンショットで形状とテキストの収まりが一致すると確認できた場合のみです。
• SVG の viewBox を使用する場合は、自動スケーリングや中央揃えだけに頼らず、幅、高さ、ポリゴン／パスの座標、テキストアンカー、ラベル位置を明示的に指定してください。

グラフや図表が狭すぎる、高すぎる、中央に寄りすぎている、単純化されすぎている、または周囲のカードから視覚的に浮いている場合は、形状の不一致として扱ってください。レスポンシブ対応に進む前に、コンテナのトラック、プロットのインセット、SVG の viewBox／アスペクト比、コントロールの幅、隣接する列の比率を調整してください。

レイアウトの調整と混雑に関するルール

参照ブレークポイントでは：

• レスポンシブ対応を行う前に、スクリーンショットの構成を再現します。
• 早まって主要なグループを再設計、削除、縮小、または再配置して、混雑を解消しないでください。
• CSS でページ全体を拡大縮小したり、ブラウザーのズーム設定を前提としたりして、混雑を解消しないでください。
• まず、忠実度を損なわない方法をすべて試してください：
  • 参照のビューポートサイズに合わせます
  • コンテナーの幅とサイドカラムの幅を正しく調整します
  • 間隔を実測値に合わせて広げたり狭めたりします
  • 正しいフォントサイズと行の高さを使用します
  • 正しいコントロール幅と最小幅を使用します
  • すべてを均等に配置するのではなく、各グリッド列に適したトラックサイズを設定します
  • 密度の高いコントロールには必要な幅を確保してから、隣接する要素を縮小します
  • スクリーンショットから折り返しが示されている箇所でのみ折り返します
  • 参照が実際に複数行を使用しているか確認します
• 参照ブレークポイントでコントロールを追加の行に移動するのは、次の場合に限ります：
  • スクリーンショットに複数行が明示されている場合、または
  • 更新後の構成を示すスクリーンショットをユーザーが提供した場合。
• 調整を一度行っても混雑して見える場合は、まだ比率が正しくないと考え、反復を続けます。混雑を「十分よい」として受け入れないでください。
• より狭いブレークポイントでは、階層と視覚的なバランスを保ちながら、きれいに再配置します。

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

• プライマリサーフェス、セカンダリサーフェス、ミュートサーフェス、境界線、グロー、シャドウ、グラデーション、テキストの不透明度を、できる限り正確に合わせます。
• 可能であれば、新しい値を独自に考案するのではなく、参照から色を抽出するか推定します。
• 次の点に注意します：
  • 背景のグラデーション
  • 境界線の微妙なアルファ値
  • パネルの透明度
  • 参照に見られるホバー時／アクティブ時の強調表示
  • メインコンテンツとサイドバーのカード間のコントラストの違い
  • バッジ、ライブインジケーター、ボタン、ハイライト間のアクセントカラーの一貫性

アセットの取り扱い手順

直接使用 image_gen 的规则

ラスターアセットが不足しており、それらによって実装が大きく改善される場合は、デフォルトでネイティブの image_gen ツールを直接使用してください。別途 imagegen または imagen スキルがインストールされていることを必須にしないでください。

image_gen の実行後、ユーザーが画像のみの出力を明示的に求めている場合を除き、同じターン内で作業を続けてください。生成したものを簡潔に示し、可能であれば保存先のファイルパスまたはアセットへの参照を提示し、リクエストに合致しているかを評価したうえで、保存、統合、検証まで進めてください。

image_gen を利用できない場合、または失敗した場合は、プレースホルダーに切り替え、不足しているアセットごとに単独の生成プロンプトを1つ作成してください。

直接 image_gen を使用する場合の運用ルール：

• 生成された出力を実装に使用する場合は、プロジェクトに属するアセットとして扱ってください。組み込みツールは $CODEX_HOME/generated_images/ に保存することがあります。コードから参照する前に、選んだ最終版をワークスペースに移動またはコピーしてください。
• 組み込みツールに保存先のパスを指定できることを前提にしないでください。先に生成し、その後で選んだ出力を移動またはコピーしてください。
• ユーザーが明示的に置き換えを求めていない限り、既存のアセットを上書きしないでください。それ以外の場合は、hero-v2.png や card-thumbnail-generated.png のような別名のファイルを作成してください。
• 複数のラスターアセットが不足している場合、関連するアセットを1枚のキャンバスにきれいに収められるなら、個別に1枚ずつ生成するよりも、1つ以上のアセットシートを生成する方法を優先してください。
• アセットが多すぎる場合、見た目に関連性がない場合、異なるスタイルが必要な場合、アスペクト比が大きく異なる場合、テキスト量が多い場合、または1枚のシートから正確に切り出すには小さくなりすぎる場合は、複数のアセットシートを使用してください。
• ローカルファイルを編集する場合は、まず view_image でそのファイルを確認し、会話のコンテキストで見える状態にしてください。編集対象、スタイル参照、構図参照、補助画像など、入力画像ごとに役割を明示してください。
• プロンプトは簡潔にまとめ、アセットの種類、UI での用途、被写体や内容、構図やフレーミング、スタイルや媒体、ライティングや雰囲気、カラーパレット、正確なテキスト（該当する場合）、制約、避けるべき事項を含めてください。編集の場合は、「X のみを変更し、Y はそのまま維持する」といった不変条件を繰り返し明記してください。
• 品質、入力忠実度、マスク、出力形式、出力パスなどのフォールバック用 CLI/API 制御項目を、組み込みの image_gen ツールの引数として扱わないでください。

透明性が求められている場合は、完了前に保存した PNG に実際のアルファチャンネルがあることを検証してください。Pillow や .NET の System.Drawing などでメタデータまたはピクセルを確認してください。有効な透過 PNG は RGBA や Format32bppArgb のようにアルファ対応であり、四隅など代表的な背景ピクセルのアルファ値が 0 である必要があります。生成されたファイルにチェッカーボード模様や単色の背景が描画されている場合は、そのままにしておき、*-transparent.png のような分かりやすい名前で修正版を作成し、出力を再検証してください。

アセットシートの生成と抽出

生成が必要なラスターアセットが複数ある場合は、アセットシートのワークフローを標準とします。

1. 相性のよいアセットをまとめて、単一のシート用プロンプトを作成します。共通するスタイル、ライティング、遠近感、画材、用途ごとにまとめます。スタイルが合わないもの、細かいテキスト、正確なブランドマーク、大きく異なる比率、または詳細な表現が必要なアセットには、別々のシートを用意します。
2. クリーンなコンタクトシートまたはスプライトシートを依頼します。1セルにつき1つのアセットを配置し、セル間に十分な余白を設け、スケールを統一し、被写体は正面向き、または枠内に明確に収めます。重なりを避け、セルの境界をまたぐ影を付けず、UI アセット自体にテキストが必要な場合を除きラベルを付けません。また、アセット内に現れない、取り除きやすい単色の背景色を指定します。
3. 透明化が必要な場合は、純粋なマゼンタ、シアンなどのクロマキー色のような、コントラストの高い単色の背景を優先します。画像モデルが本物の透明表現を生成できることを前提にせず、市松模様の透明背景も依頼しないでください。
4. 生成後、選んだシートをワークスペースにコピーしてから、できれば Python Pillow を使ったローカルスクリプトで個々のアセットを抽出します。生成した元のシートには手を加えないでください。
5. 抽出時は各セルまたは検出したオブジェクトを切り抜き、キー背景または端とつながった無彩色の背景を取り除き、透明な余白をトリミングし、必要に応じて安全な余白を加え、各アセットをプロジェクトのアセットフォルダーに分かりやすいファイル名で保存します。
6. 抽出した透明 PNG が RGBA などのアルファ対応モードであり、代表的な背景／隅のピクセルのアルファ値が 0 であることを確認します。アセットを組み込む前に、抽出したアセットを目視で確認してください。
7. 実装で意図的にスプライトシートを使う場合を除き、シート全体ではなく、抽出した個別のファイルを組み込んでください。
8. 抽出によって輪郭が損なわれたり、内部のディテールが消えたりした場合は、元のシートを保持し、抽出マスクを修正するか、間隔や背景をより明確にして再生成してからアセットを使用してください。

生成されるアセットを大きく保ち、個別に切り分けられそうな場合は、アセットシートを1つ使います。1つのシートではアセットが小さくなりすぎる、判別しにくい、切り抜きにくい、またはスタイルに一貫性がなくなる場合は、複数のシートを使います。

まず、ページに必要な、表示されるすべてのアセットをリストアップします。

• ロゴ
• ヒーロー画像
• サムネイル／カード
• マップ
• アバター
• アイコン
• カスタムボタンおよびボタン用アートワーク
• カスタムコントロール、トグル、タブ、バッジ、メダル、ステッカー、カーソル、ハンドル、ノブ、UI 装飾
• デスクトップ／ゲーム／アプリ固有のクローム、HUD パーツ、メニュープレート、インベントリスロット、ツールアイコン、装飾的なインターフェースパーツ
• イラスト
• 背景グラフィック
• その他のテキスト以外の視覚要素

各アセットについて、使用する方法を1つだけ選びます。

1）ユーザーがアセットを提供した場合

• 使用前に目視で確認します。
• 適切な場所で使用します。
• 参照画像の構成に合わせて、必要に応じてトリミング、リサイズ、余白追加、切り詰め、マスク処理を行います。
• アスペクト比を維持し、変形させないでください。
• 必要に応じて object-fit: cover または contain を使います。
• アセットの解像度が低いなど、品質に問題がある場合は可能な限り近づけ、制約について記載します。

2) アセットが不足しており、生成が必要な場合

• ツールが利用可能な場合は、image_gen を直接使ってアセットを生成または編集します。
• 不足しているアセットを複数まとめて生成できる場合は、原則としてアセットシートのワークフローを使い、その後、個々のファイルをローカルで切り出します。
• 不足しているアセットが1つだけの場合、または独自の構図や詳細が必要なアセットの場合は、個別に生成します。
• WebページやWebアプリでは、見た目を一致させられる場合に限り、シンプルなUIグリフをインラインSVGまたは既存のリポジトリアイコンで実装します。一致させられない場合は、画像アセットとして生成または切り出します。
• デスクトップアプリ、ゲームのHUD、メニュー、インベントリ画面、ランチャー、高度にスキンが適用されたツールなど、Web以外のUIでは、コードによる再現が明らかに忠実で、そのことを確認できる場合を除き、多くのカスタムUI要素が画像アセットであることを想定します。
• 生成したアセットは、リポジトリで既に使用されているアセットの保存場所、または慣例がない場合は assets/generated/ のような適切なフォルダーに保存します。
• 生成したアセットを参照するよう、使用箇所のコードやマークアップを更新します。
• 切り出しまたは生成した各アセットが、レイアウトに見た目と寸法の両面で適合することを検証します。
• アセットが実際のコンテキストで機能するまで、必要に応じて再トリミング、再生成、反復を行います。
• image_gen を利用できない場合、生成に失敗した場合、または現在のターンで切り出しを修正できない場合は、明確なラベルを付けたプレースホルダーを使用し、まだ不足しているアセットごとに、独立した生成プロンプトを1つ出力します。

3) アセットが不足しているが、生成すべきではない場合

この方法は、プロプライエタリなブランドマーク、正確な実物の素材が必要なアセット、またはユーザーが画像を生成しないよう明示している場合に使用します。

• おおよその寸法、アスペクト比、角の丸み、配置、視覚的な重みが適切な、明確なラベル付きのプレースホルダーを使用します。
• 汎用的なプレースホルダーの代わりに一時的な代替画像を自分で作成または合成した場合でも、報告上は不足しているアセットとして扱います。
• 代替画像、プロキシイラスト、合成した置き換え画像を、報告せずにそのまま使ってはいけません。
• ユーザーがプロンプトを受け取らないよう明示している場合を除き、不足している各アセットについて、個別にすぐ使える生成プロンプトを用意します。
• 最終回答で、まだ不足しているアセットのプロンプトを1つにまとめた単一の text コードブロックに入れ、別のAI／LLMに簡単にコピー＆ペーストできるようにします。
• コードブロック内の各プロンプトは、「---」のような明確な区切りで分けます。
• 各プロンプトには、次の内容を含めます。
  • アセット名／推奨ファイル名
  • UIでの用途
  • 希望する題材／内容
  • 構図／フレーミング
  • スタイル／雰囲気
  • 色／ライティング
  • 目標のアスペクト比または寸法
  • 必要に応じて、透過／背景に関する要件
  • 避けるべき点

アセット固有のガイダンス

• シンプルな UI アイコンだからといって、空白のままにしてはいけません。Web ページでは、見た目を一致させて確認できる場合、インライン SVG または既存のリポジトリ内アイコンを使ってシンプルなグリフを実装してください。
• すべてのアイコン、ボタン、カスタム UI 要素を無理にインライン SVG にする必要はありません。参照画像がカスタムイラスト、テクスチャ、複雑な形状、絵画的なディテール、影、エンボス加工風のスタイル、ゲーム／デスクトップの枠組み、またはコードでの再現が難しいほかの視覚表現に依存している場合は、ラスターアセットを使用してください。
• Web 以外のインターフェースでは、既存のプラットフォームまたはコードベースに一致するコンポーネントがすでに用意されている場合を除き、カスタム UI パーツにはインライン SVG よりも画像アセットが生成／抽出されるケースが多いと想定してください。
• 繰り返し使われるアイコンやショートカット／ナビゲーション用マークは、スクリーンショット内でそれぞれの表示を確認してください。技術的には存在していても、薄すぎる、切れている、つぶれている、または見分けがつかないアイコンは、欠落しているものとして扱います。
• 提供されていないブランドロゴや独自性の高いマークには、ユーザーが一時的な代替画像の生成を明示的に求めている場合を除き、プレースホルダーを使用してください。
• ヒーロー画像、サムネイル画像、地図など、目立つビジュアルは、トリミング、焦点位置、アスペクト比、視覚的な重みをできるだけ一致させてください。
• サムネイルカードが繰り返し表示される参照画像では、すべてのアイテムでトリミングと角丸が一貫するように注意してください。

実装ワークフロー

1. 参照画像を確認し、事前チェック用のインベントリを作成します。
2. 既存のコードベースがある場合は、関連性の高いページ、コンポーネント、デザイントークン、アイコンを優先して確認し、再利用するものを決めます。
3. 最初の実装から、すでに見た目が十分に近いものを作成します。
4. ページを実行またはプレビューします。
5. 参照画像と同じビューポートサイズで、実装のスクリーンショットを撮影します。
6. 実装のスクリーンショットと参照画像を比較します。
7. 編集前に、相違点のリストを文章で作成します。最も大きな視覚的な誤差から優先して、その後、細部を調整します。
8. 明らかな相違点がなくなるまで、スクリーンショットの撮影、相違点のリスト作成、修正を繰り返します。
9. チャート、地図、ゲージ、タイムライン、ファネル、ピラミッド、ツリー、グラフ、その他の分析ビジュアルについては、メインレイアウトが近いと判断する前に、バウンディングボックス、内部の比率、ラベル、コントロールを参照画像と比較する専用のビジュアル要素チェックを行います。
10. 情報量が多い、制約が厳しい、重要度が高い、または崩れやすいコンポーネントでは、全体のスクリーンショットだけで判断せず、コンポーネントに焦点を当てたスクリーンショットや切り抜きを撮影し、拡大して確認します。限られたスペースにテキスト、アイコン、バッジ、コントロール、チャート、凡例、テーブル、アバター、アクション行を収める必要があるコンポーネントでは、これを必ず行います。
11. 完了前に、次の項目だけに注目する「脆弱性チェック」を少なくとも一度実施します。

• 要素が密集した行
• 切れている、または押しつぶされているテキスト
• 要素の重なり
• カードやコントロールの端に十分なパディングがないまま、テキスト、ラベル、値が寄りすぎている箇所
• カード、リスト、行、ポップオーバー、ツールバーの境界など、ある要素が隣の要素にはみ出す可能性がある箇所
• 内容に対して幅が狭すぎるように見えるコントロール
• 少し異なる幅では崩れる可能性がある、間隔が不自然なほど狭い箇所
• ズーム率、DPI スケーリング、フォントサイズの拡大、またはビューポートの高さの縮小によって、内容がはみ出したり、重なったり、アクセスできなくなったりする可能性がある、固定高さのカード、行、パネル、固定領域
• ドーナツ、円、ゲージ、バッジ、カウンター、コンパクトなチャートラベルの中央のテキスト

12. カードグリッド、テーブル行、統計タイル、ナビゲーション項目、繰り返し表示されるボタンなど、UI 構造が繰り返される場合は、配置を明示的に確認し、兄弟要素間で共通のベースライン、フッター行、ボタン位置、チップ行、メディアのトリミングが一貫していることを検証します。

ブラウザーで確認できる場合は、コードの編集と lint／ビルドチェックだけで作業を終えないでください。ビルドやテストの結果は、このスキルで必須となるスクリーンショット比較の反復に代わるものではありません。

必須の視覚検証ワークフロー

ブラウザーとスクリーンショットのツールを利用できる場合、以下の検証は必須です。

ブラウザーツールを利用でき、まだ自分でスクリーンショットを撮影して確認していない場合、作業は完了していません。作業が完了済み、準備完了、または検証済みであると伝えてはいけません。スクリーンショットの確認を完了するか、実施できなかった具体的な理由を明示するまで続けてください。

ページ全体ではなく、視覚的に重要な密度の高い領域を1か所だけ変更する場合でも、少なくとも次のスクリーンショットを撮影してください。

• 変更箇所と周辺の文脈がわかるスクリーンショットを1枚
• ツールで要素のキャプチャや切り抜きが可能な場合は、変更箇所そのものを拡大したスクリーンショットを1枚

最終報告では、現在のターンで実際に撮影して確認していないスクリーンショットを確認済みであるかのように示してはいけません。

最終報告には、実際に行った視覚検証の成果物をカテゴリ別に記載してください。

• 確認した全ページまたはビューポートのスクリーンショット
• 確認したコンポーネントの拡大切り抜き
• 確認したスケーリング／耐性のスクリーンショット
• 実施できなかった必須の視覚検証と、その具体的な理由

このターンで該当する成果物を実際に撮影して確認していない場合、コンポーネントの切り抜き、スケーリングの確認、ブラウザーチェック、レスポンシブチェックを完了したと説明してはいけません。

ページが長く、1枚のスクリーンショットでは確実に確認できない場合、ページ全体を網羅する分割スクリーンショットを撮影してください。上部／中央部／下部をカバーするか、必要に応じてさらに細かく分割してください。見えていない下部のセクションが正しいと仮定してはいけません。

縦に長いページでは、次の検証方法を推奨します。

• ツールで対応している場合は、ページ全体または実用上最大の高さのスクリーンショットを1枚撮影し、文書全体の縦方向のリズム、セクション間隔、全体構成を把握します
• さらに、スクロール位置を意図的に設定して、ページの上から下までをカバーするビューポートのスクリーンショットを分割して撮影します
• 分割したスクリーンショットを自分で目視確認してください。縦長のキャプチャだけに頼って下部を確認してはいけません。縦長のキャプチャでは、詰まり、テキストの欠け、固定要素の重なり、小さな配置ずれを見落とす可能性があります
• 分割したスクリーンショットでページ全体をカバーし、未確認の間隔を残さないようにします
• 特に密度が高い、または崩れやすいセクションでは、最寄りのスクリーンショットだけで十分とせず、その領域のスクリーンショットを追加で撮影します

全ページのスクリーンショットは全体構成を把握するための補助として扱い、縦長ページの忠実性を目視確認する際は、分割したスクリーンショットを正式な確認対象としてください。

パス 0 — ビューポートの調整

• 最初の比較では、参照画像と正確に同じ寸法を使用します
• ページが正しいルート／状態で、比較可能なスクロール位置にあることを確認します
• 異なる幅で忠実性を判断しておきながら、一致していると主張してはいけません
• ビューポートの調整は正確に行ってください。構成を無理に合わせる目的で、CSS の zoom、ラッパーによる拡大縮小、スクリーンショットだけに適用する変換を使用してはいけません
• 画面上の表示を目視で判断するよりも、CSS ビューポートの寸法を明示して自動化ツールで撮影したスクリーンショットを優先します
• 利便性のために画面表示モードを使用する場合は、操作やデバッグのみに使用してください。Playwright で直接撮影できる場合、表示中の画面を忠実性の正式な確認対象として扱ってはいけません

パス 1 — 全体構成

次の項目を確認してください。

• ページ全体の幅と余白
• メイン領域とサイドバーの幅の比率
• ヒーロー領域の分割比率
• カードの幅と高さ
• カード内のグラフ、図、マップ、メディア、テーブル領域の幅の比率
• セクション間隔
• 上部ナビゲーション、ヒーロー領域、フィルター領域、テーブル、サイドバーの配置
• 水平方向のはみ出しや、ページ全体が不自然に縮小／拡大されていないこと
• 参照画像より行の密度が高い、間隔が詰まっている、または圧縮されて見える箇所がないこと

パス 2 - タイポグラフィとコピー

確認項目：

• フォントファミリーの選択
• フォントサイズ
• ウェイト
• 行の高さ
• 字間
• テキストの色／不透明度
• コピーの正確さ
• 改行／折り返しの正確さ
• テキストが途中で切れたり、クリップされたり、明らかに押しつぶされたりしていないこと
• 小さなラベル、補助テキスト、タイムスタンプ、バッジテキスト、プレースホルダー、テーブルのメタデータにコピーの不一致がないこと

パス 3 - アイコンとコントロールの完全性

確認項目：

• すべてのアイコン、ロゴ、キャレット、箇条書き、ドット、星印
• ナビゲーション、サイドバー、ツールバー、タブの各アイコンが、対応する参照項目と一致していること
• テーブル／リスト／カードで繰り返し使われるアクションアイコン。各グリフが参照と同じ意味を持つかどうかも含みます
• ボタンの先頭／末尾のアイコン
• 検索アイコンの有無と配置
• インラインの補助アイコン
• 統計カードのアイコン
• 見落としやすい細部

パス 4 - 色と表面の処理

確認項目：

• グラデーション
• 表面の色味
• 境界線
• 境界線の不透明度
• シャドウ
• グロー
• ピル型要素の塗り
• バッジの色
• テーブル行の区切り線
• 控えめなテキストの色調

パス 5 - 間隔と細かな形状

確認項目：

• パディング
• マージン
• 間隔
• 角丸
• チップのサイズ
• 入力欄の高さ
• ボタンの高さ
• 行の高さ
• 画像のトリミング範囲
• グラフのプロット領域の境界、軸／グリッド線の配置、系列の形状、マーカーの配置、凡例の間隔、グラフのフッター形状
• 比例図の境界、セグメントのサイズ、テーパー／段差の形状、ラベルの配置、隣接する指標との間隔
• 比例図内のテキストの収まり：参照でも同じである場合を除き、ラベルが意図されたセグメントの外にはみ出していないこと
• 同じ行に並ぶカードやパネルの高さ。特に、隣接するカードの高さが意図的に異なる場合
• コンポーネント内部の垂直方向のバランス：グラフ、ドーナツ、凡例、フッターリンク、CTAが参照と同じ相対的な高さに配置されていること
• レイヤーの重なり、角のクリップ、コントロール内部の圧縮がないこと
• 参照のスクリーンショットで明らかにそうなっている場合を除き、参照より幅の狭いフィールド／ボタン／セレクトがないこと
• 繰り返し使われるコンポーネント間で配置が一貫していること
• 参照で揃えることが示されている場合、同列のカード間でフッター／ボタンのベースラインが一致していること
• 参照で高さが等しく示されていない限り、同列のカードを無理に同じ高さにしないこと。参照にある高さの違いもデザインの一部です
• 参照に明確な理由がない限り、同列のカードやタイルのCTA、統計行、バッジ行、タイトルブロックが、他より明らかに高い位置や低い位置にないこと

パス 5a - コンポーネントのクロップ確認

情報量が多い、制約がある、重要度が高い、または壊れやすい UI 領域では、ページ全体または分割したスクリーンショットに加えて、個々のコンポーネントに焦点を当てたスクリーンショットを撮影して確認します。

次のものには、コンポーネント単位のスクリーンショットを使用します。

• グラフ、ドーナツチャート、ゲージ、マップ、ファネル、テーブル、データグリッド、タイムライン、分析パネル
• スティッキーサイドバー、ツールバー、インスペクター、ヘッダー、フィルターバー
• 固定表示のナビゲーションパネル、サイドバー、レール、ツールパネル。ラベルの展開状態や折りたたみ／アイコンのみの状態も含みます
• フッターの CTA、ページネーション、行アクション、折り返しなしの列、アバター、チップ、バッジを含むテーブル／リストパネル
• カード、フォーム、モーダル、ナビバー、サイドバー、タブバー、セグメントコントロール、チェックアウトブロック、料金カード、設定パネル、フィード／リスト項目、デスクトップアプリのペイン、ゲーム HUD パネル、その他の制約された領域
• コンパクトなタイポグラフィ、バッジ、チップ、カウンター、アバター、アイコン、凡例、値、タイムスタンプ、日付、アクション行を含むコンポーネント
• カードが重なる接合部、カード同士の境界、スティッキー要素とコンテンツの境界、およびコンポーネントの自然な高さが隣接要素に影響し得る箇所
• 全体表示では見落としやすい、テキストの配置、クリッピング、オーバーフロー、正確な比率の形状がある領域
• ページ全体の確認中に問題が疑われたコンポーネント

Playwright または同等のブラウザー自動化を使用する場合：

• 確認対象のコンポーネントには、要素のスクリーンショット／クロップを優先します。
• 周囲の間隔が重要な場合は、コンテキストを含めてコンポーネントを撮影します。
• コンポーネント単位で、中央のラベル、凡例、チップの行、ボタンのテキスト、アイコンの配置、行の高さ、内部のパディング、端との間隔、隣接コンポーネントとの間隔を確認します。
• 小さなタイポグラフィやグラフのラベルを判断する際に、ページ全体のスクリーンショットだけに頼らないでください。
• コンポーネント単位のクロップで問題が見つかった場合は、修正してからそのコンポーネントを再撮影し、ビジュアル確認の完了を宣言します。
• 情報量が多い、または制約のあるコンポーネントをクロップしていない場合、最終レポートでコンポーネント単位のビジュアル確認を行ったと主張しないでください。

パス 5b - モバイルナビゲーションの状態確認

モバイルナビゲーションを推測して実装、または調整した場合は、デフォルトのページだけでなく、関連する状態も撮影して確認します。

• モバイルナビゲーションの閉じた状態／デフォルト状態
• ドロワー、シート、メニュー、オーバーフロー、または展開されたタブがある場合は、その開いた状態
• ナビゲーションにラベル、アイコン、バッジ、または多くの遷移先がある場合は、狭いモバイル幅でのストレステスト

主要な遷移先にすべてアクセスできること、アクティブ状態が明確であること、ラベルが収まるか意図的に省略表示されること、タッチターゲットが使いやすいこと、メニューを開くトリガーが分かりやすいこと、オーバーレイが操作コントロールを不自然に隠さないこと、コンテンツがビューポートを超える場合にドロワー／シートをスクロールできることを確認します。

パス 6 - レスポンシブ動作

参照サイズのバージョンがほぼ完成したら、次を行います。

• デスクトップのウェブページでは、ユーザーが別のデスクトップ表示幅を明示的に指定していない限り、1900px 前後のビューポート幅でのワイドデスクトップ検証を優先して行います。
• 参照スクリーンショットの狭い幅が、本番のデスクトップ表示に適した幅だと決めつけないでください。スクリーンショットが POC の場合は、構成とデザイン言語を保ちながら、推奨されるワイドデスクトップのビューポートで安定した実ページのレイアウトに置き換えます。
• タブレットとモバイルの幅でテストします。
• 可能であれば、少し狭いデスクトップ幅やブラウザーの縮小表示など、別のデスクトップ条件でも妥当性を確認し、壊れやすいレイアウトの前提がないか調べます。
• ユーザーの環境でデフォルト以外のズームや DPI スケーリングが使用されると分かっている場合は、実用的な範囲でその条件に近い確認を 1 回行います。
• 階層とバランスを保ちます。
• オーバーフロー、コントロールのクリッピング、不自然な折り返し、メディアの歪みを避けます。
• レスポンシブ版が元のデザイン言語とかけ離れないようにします。
• 結果を報告する際は、環境に起因する表示上の差異と実際のレイアウト上の不具合を区別します。DPI スケーリングやブラウザーのズームを、目に見える形状の誤りを正当化するために一律に使わないでください。

パス 6a - ブラウザーとスケーリングへの耐性

高密度または制約のある UI では、仕上げる前にスケーリング耐性の確認を行います。

• 参照サイズと通常のレスポンシブブレークポイントに加えて、デスクトップで実効幅を制限した状態を 1 つテストします。参照サイズより 5〜15％狭い幅、またはタブレットより上の最も近いブレークポイントを優先してください。
• 可能であれば、ブラウザーのズーム、最小フォントサイズの変更、Windows/macOS のディスプレイスケーリング、サイドパネル、ブラウザー固有のフォントメトリクスを想定した、文字を大きくする条件、または利用可能幅を狭める条件を 1 つテストします。
• このストレス条件下で、特に凡例、テーブル、カード、ナビゲーションバー、ツールバー、フォーム、バッジ、日付／値の列、カードを積み重ねた際の接合部など、制約の厳しいコンポーネントに焦点を当てて確認します。
• テキストの折り返し、切り抜け、端への過度な接近、重なり、値の切り捨て、バッジの詰まり、コンポーネントの高さの予期しない増加は、レイアウトの不具合として扱います。
• オーバーフローの挙動と隣接コンポーネントとの間隔がストレス条件下で検証されていない限り、テキスト量の多いコンポーネントに固定高、固定グリッド行、絶対配置を使用しないでください。
• デスクトップのビューポート内でもコンポーネントが狭くなる可能性がある場合は、自然なドキュメントフロー、min-height、独立したスタック、コンテナークエリ、内在サイズ、折り返しルール、より早いブレークポイントを優先します。
• ストレス条件によって、参照デザインに忠実なレイアウトでは脆弱すぎると判明した場合は、デザイン言語を維持しつつ、より堅牢なレイアウトを選択します。これを意図的な耐性調整として報告してください。

パス 7 - 最終的な完全性の確認

完了する前に、次の項目を確認してください。

• 表示されるすべてのセクションが存在する
• 表示されるすべてのアイコンが存在する
• 表示されるすべてのテキストラベルが存在する
• 重要な表示コントロールすべてに適切な基本的な操作状態があるか、明確に意図された非操作状態になっている
• 提供されたすべてのアセットが適切に使用されている
• 生成されたすべてのアセットシートが個別ファイルに分割されているか、シート／スプライトとして意図的に組み込まれている
• 透明度が必要な場合、抽出したすべての透過アセットについて、アルファメタデータ／ピクセルが検証されている
• 残っている不足アセットすべてにプレースホルダーがあり、必要に応じて、単一のアセットプロンプトコードブロックに項目が追加されている
• テーブル／リストのパネルに、意図しない内部スクロールバー、切り抜かれた行アクション、コンテナーの外に出たフッターの CTA がない
• 検証した表示に、明らかな詰まり、切り抜け、重なり、レイアウトの脆弱性が残っていない

必要に応じて、これらのパスを超えて反復を続けてください。最初に動作するドラフトで終わらせないでください。

任意のヘルパースクリプト

このスキルに scripts/compare_screenshots.py が含まれ、Python が利用できる場合は、参照サイズで実装のスクリーンショットを撮影した後に使用します。

推奨される使用方法： python <path-to-codex-home>/skills/ui-from-image/compare_screenshots.py path/to/reference.png path/to/implementation.png --out-dir .codex-artifacts/ui-diff

注意事項：

• ヘルパースクリプトは、対象リポジトリではなく、インストール済みのスキルディレクトリにあります。ただし、リポジトリにコピーした場合は除きます。
• ベストプラクティスとして、リサイズせずに同じ寸法のスクリーンショットを比較します。
• 候補のスクリーンショットのサイズがわずかに異なり、簡単な診断が必要な場合のみ、代替手段として --fit を使用してください。
• 生成された差分画像と指標を使って差異の大きい箇所を特定しますが、数値だけを最適化しないでください。視覚的な判断も引き続き重要です。

レスポンシブ要件

• デスクトップ、タブレット、モバイルで問題なく動作する必要があります。
• オーバーフロー、崩れた折り返し、コンテンツの切り抜け、メディアの歪み、不自然な余白の変化を避けてください。
• 可能な限りデスクトップの構成を維持しつつ、小さい画面ではきれいに再配置／積み重ねを行ってください。
• インタラクティブ要素はタッチ操作しやすいサイズにしてください。
• 参照デザインで明確に示されている場合を除き、重要なコンテンツを隠さないでください。

推定されるモバイル対応

モバイル版の参考資料が提供されていない場合、デスクトップのレイアウトを機械的に縦積みにしないでください。狭いタッチ画面でも各コンポーネントを使えるようにしつつ、プロダクトの階層とビジュアル言語を保つモバイル対応を設計してください。

モバイル版を推定する場合：

• コーディングを始める前に、モバイルでの情報の順序を決めてください。
• 密度の高いテーブルやデータグリッドは、タスクを損なわない場合に限り、行カード、簡潔な概要、または横スクロールに変換してください。
• 固定サイドバーは、アプリの種類に応じた意図的なモバイルナビゲーションパターンに変換してください。サイドバーを単に非表示にしたり、デスクトップの長いナビゲーションを過度に長い横スクロール表示にしたりしないでください。
• チャートや図表は読みやすさを保ってください。必要に応じて軸、凡例、ラベルを簡略化するか、概要を先に示すカードを用意してください。
• 参考資料に反しない範囲で、セクションをタブ、アコーディオン、概要、または詳細ビューにできる場合は、極端に長いページを避けてください。
• タッチターゲット、ラベルの折り返し、カード間隔、固定ヘッダー／ナビゲーション、すべての主要アクションを確認してください。
• モバイルのビューポート全体のスクリーンショットに加え、情報量の多いモバイルコンポーネントの部分拡大スクリーンショットも取得してください。
• 最終レポートでは、モバイル版を推定したかどうかを明記し、デスクトップ版から意図的に変更した構造を列挙してください。

モバイルナビゲーションの代替

デスクトップのサイドバー、レール、トップナビゲーション、インスペクターナビゲーション、またはコマンドメニューがモバイル画面に収まらない場合：

• デスクトップ版の重要な行き先すべてにアクセスできるようにしてください。モバイル対応ではよく使う行き先を優先してもかまいませんが、残りの行き先も、見つけやすいフルメニュー、ドロワー、シート、オーバーフローメニュー、または同等の方法から引き続き利用できるようにしてください。
• パターンは意図的に選んでください。主要なアプリ領域が3～5個の場合はボトムナビゲーション、同列のビューの場合はトップタブ／セグメントナビゲーション、行き先が多い場合はドロワーまたはシートを使ってください。コンパクトな横並びナビゲーションは、すべての項目を見つけやすく、使いやすい場合に限り使用してください。
• 優先ショートカットとフルメニューを併用する場合は、ショートカットの数を絞り、メニューを開く操作を視覚的に明確にしてください。
• ドロワー／シートを使う場合は、明確なタイトルまたはコンテキスト、閉じる操作、適切にスクリーンを暗くする表示や外側をタップして閉じる動作、実用上可能な場合のキーボードで閉じる操作、長いリストをスクロールできる機能を設けてください。
• 閉じた状態と開いた状態の両方で、選択中の状態、アイコンとテキストの配置、ラベルの収まり、タッチターゲットのサイズ、メニューを開く操作の配置を確認してください。
• 非表示の行き先、途切れたラベル、到達できないドロワー項目、閉じた状態でもフォーカスできる画面外のリンク、曖昧なメニュー操作は、モバイルナビゲーションの不具合として扱ってください。

動作

• 参考資料から読み取れる可視の動作に限り、JSを追加してください。
• JSが不要な場合も、短いコメントを含む script.js を作成してください。
• 無関係な機能、アニメーション、ライブラリは追加しないでください。

暗黙的なインタラクションとアフォーダンスの忠実度

参照資料または製品のコンテキストから操作可能だと読み取れる可視コントロールには、基本的なインタラクション状態を実装してください。動作はローカルで信頼できるものにとどめ、裏付けのないワークフロー、バックエンドロジック、製品機能を創作しないでください。

Web とアプリの UI の場合：

• リンクには、画面に応じて適切なホバー、フォーカス、訪問済み、アクティブ状態のスタイルを設定してください。
• ボタンには、参照資料またはコントロールの役割から必要と読み取れる場合、ホバー、アクティブ、フォーカス表示、選択中、読み込み中、無効の各状態を設定してください。
• ドロップダウン、セレクト、セグメントコントロール、タブ、トグル、チェックボックス、ラジオボタン、アイコンボタン、行メニュー、コマンドバー、テーブル行、リスト項目は、画面上に表示されている場合、または明確に存在が示唆されている場合、基本的なローカル操作に対応させてください。
• 検索やフィルターのコントロールは、ローカルデータが画面上にある場合、軽量なクライアント側フィルタリングを実行してもかまいません。
• 参照資料から複数のモードが示唆され、製品データを創作せずにコンテンツを表現できる場合、タブまたはセグメントコントロールで表示状態を切り替えてもかまいません。
• メニュー、ポップオーバー、ドロワー、アコーディオン、ツールチップは、トリガーが存在する場合、スクリーンショットまたは周辺の製品コンテキストで裏付けられる選択肢のみを使って、開閉できるようにしてもかまいません。
• 明示的に求められていない限り、破壊的な操作、決済フロー、認証、永続化、ネットワーク呼び出し、通知、ファイルシステムへのアクセス、複雑な製品ワークフローを模倣しないでください。

デスクトップスタイルの UI の場合：

• ツールバーボタン、ツリー行、メニュー項目、タブ、グリッド行、スプリッター、ペイン、スクロール領域、フォームコントロールには、自然なホバー、フォーカス、押下、選択、無効、サイズ変更のアフォーダンスを使用してください。
• キーボードフォーカス、コンテキストメニュー、データ密度の高いグリッド、無効なコントロール、ウィンドウ枠、ステータスバーについて、プラットフォームの慣習を維持してください。
• 参照資料自体がマーケティングスタイルの画面でない限り、デスクトップツールをマーケティングページのように見せないでください。

ゲーム UI とインタラクティブな 3D 画面の場合：

• メニュー選択、ホバー／フォーカス／押下状態、コントローラーやキーボードで操作しやすいナビゲーションの手がかり、基本的なパネル遷移、HUD フィードバック、必要と読み取れる場合の一時停止／設定画面のナビゲーションを実装してください。
• 求められていない限り、ゲームプレイシステム、インベントリの効果、戦闘ルール、物理演算、進行状況、セーブ／ロードの動作、オンライン機能を創作しないでください。
• 可読性、選択状態、入力フィードバック、安定した HUD レイアウト、重なり合わないオーバーレイを優先してください。

あらゆる UI 画面に共通する要件：

• クリック可能に見える要素には、実際に動作するローカル機能、または正しく動作しないことが明確に分かる状態のいずれかを設定してください。
• カーソル、ホバー、押下、選択、無効、フォーカス表示、ドラッグ、サイズ変更、タッチの各状態は、プラットフォームとビジュアルスタイルに合わせてください。
• アイコンのみのボタンには、コード内でアクセシブルなラベルまたは同等のセマンティクスを付与してください。
• ローカルな状態変化によって視覚的な忠実度を損なったり、レイアウトをずらしたり、必要なコンテンツを隠したり、参照資料と矛盾する状態を作り出したりしないでください。
• 自動化または UI ツールが利用できる場合、重要なコントロールについて、少なくとも 1 つのホバー、フォーカス、選択、または開いた状態を検証してください。

最終レポート

最後に、以下について簡潔に報告してください。

1. 実装した内容
2. 再利用／調整したものと、新規作成したもの
3. 使用した提供アセット
4. 生成して組み込んだアセット、および個別生成か、アセットシートからの抽出か
5. 残っているプレースホルダー
6. 不足しているアセットがある場合、残りのアセット生成プロンプトをすべて含む text のフェンス付きコードブロックを 1 つだけ記載
7. 完了したビジュアル比較パス
8. 残っている不確かな点やわずかな不一致
9. 不足アセットの代用として一時的な仮素材または合成素材を使用した場合は、その旨を明記し、不足アセットの報告と併せて列挙
10. 抽出した透過アセットについて、アルファ検証を完了したかどうか
11. モバイルナビゲーションを推定した場合、採用したモバイルナビゲーションのパターンと、確認した開いた状態／閉じた状態／狭い画面幅のスクリーンショット

単一アセットプロンプトブロックのルール

• 不足しているすべてのアセットプロンプトには、text のフェンス付きコードブロックを正確に1つだけ使用してください。
• アセット生成プロンプトが不要な場合は、ブロック全体を省略してください。
• アセットプロンプトを複数のコードブロックや通常の文章に分散させないでください。
• このブロックが必要な場合、自由形式の文章によるプロンプト、箇条書き、またはプロンプトの提案を言い換えたものに置き換えないでください。
• 不足しているアセットがある場合は、別の形式を独自に考案せず、次の構造をそのまま使用してください。
• ブロック内では、各アセットプロンプトを単独で記述し、--- で明確に区切ってください。
• ブロックの先頭には、次の文を記載してください。

Generate each asset below as a separate image file. Do not combine multiple assets into one image.

• 次に、各アセットに対して次の構造を使用してください。

---

asset_name: ... suggested_filename: ... purpose_in_ui: ... target_dimensions_or_aspect_ratio: ... background_requirements: ... prompt: ... avoid: ...

最終回答を送信する前に、次の項目を簡単にセルフチェックしてください。

• 不足しているアセットがある場合、フェンス付きの text ブロックが正確に1つだけあるか
• 不足している各アセットに、それぞれ asset_name、suggested_filename、purpose_in_ui、target_dimensions_or_aspect_ratio、background_requirements、prompt、avoid が含まれているか
• その単一ブロックの外に、余分なアセットプロンプトを追加していないか

完了の定義

以下のすべてを満たした場合にのみ、タスクは完了です。

• レンダリングされたページが、参照画像と視覚的にほぼ一致している。
• レスポンシブ対応に着手する前に、主となる参照サイズのスクリーンショットを先に再現している。
• デスクトップ、タブレット、モバイルの各レイアウトに一貫性があり、安定している。
• ツールを利用できる場合は、主となるデスクトップのスクリーンショットに加えて、少なくとも1つの表示状態を確認している。
• 情報量の多い、または制約のあるコンポーネントについて、隣接コンポーネントとの境界も含め、コンテンツの増加による重なりが起きないかを確認するためのスクリーンショットや切り抜きを撮影し、確認している。
• ツールを利用できる場合は、情報量の多い、または制約のある UI に対して、実効幅を狭める、大きな文字を近似する、または既知のユーザー環境条件を使うなどして、拡大表示やブラウザーでの表示耐性を確認している。
• 固定ナビゲーション、サイドバー、レール、インスペクター、ツールパネルがある場合は、内部の横方向のはみ出し、ラベルの収まり、独立スクロール、適切な展開・折りたたみ動作を確認している。
• デスクトップのナビゲーション形式が変わる場合は、モバイル向けのナビゲーションへの置き換え後も重要なすべての移動先にアクセスできることを確認し、閉じた状態、開いた状態、幅を狭めた状態を検証している。
• データテーブル、グリッド、リストパネルに、意図しない内部スクロールバーがないこと、行のアクションが切れていないこと、フッターリンクや CTA がカードの境界からはみ出していないことを確認している。
• 適切な箇所では、既存のプロジェクトのパターンを再利用している。
• フォントファミリー、実際に表示されるフォールバックフォント、サイズ、ウェイト、行の高さ、文字間隔、見た目の字幅を明示的に確認しており、フレームワークのデフォルト設定に頼っていない。
• 確認した表示状態で、テキストに誤りがなく、切れたり、省略されたり、押しつぶされたり、端に寄りすぎたり、重なったり、不適切に折り返されたりしていない。
• 意図的に高さを変えている同種カードも含め、カードとパネルの高さを自動的に均一化せず、参照画像と照らし合わせて確認している。
• アイコンや細部を明示的に確認し、明らかな小さな UI 要素の欠落がない。
• データの可視化や比例図について、カードの境界、内部の形状、ラベル、コントロール、周囲の余白を明示的に確認している。
• ツールを利用できる場合は、情報量が多い、重要度が高い、または崩れやすい領域について、コンポーネントに焦点を当てたスクリーンショットや切り抜きを撮影し、確認している。
• 参照画像やプロダクトの文脈から必要性が示される場合、表示される操作可能なコントロールに、プラットフォームに適した操作感と基本的なローカル動作がある。ただし、根拠のないワークフローは追加していない。
• 提供されたアセットを適切に使用している。
• 生成が必要な未提供のラスターアセットは、可能な場合に生成しており、互換性のあるグループではアセットシートを優先して使用し、個別ファイルに切り出して組み込んでいる。
• 透明度が必要な場合は、生成または切り出した透明アセットに、実際のアルファチャンネルがあることを確認している。
• 未提供のまま残っているアセットは、正確なプレースホルダーと、それらをまとめた単一の fenced text コードブロック内の単独生成プロンプトで表現している。
• 確認した表示状態に、明らかな横方向のはみ出し、要素の重なり、過密さによる新たな問題が残っていない。
• 単独で動作する実装では HTML／CSS／JS のファイルを分け、フレームワークを使うプロジェクトでは既存の構成に適切に統合している。
• ブラウザーツールを利用できた場合、最終回答では撮影して確認したスクリーンショットを正確に記載している。この確認を省略したり、視覚的でない確認を同等のものとして説明したりしていない。
• コンポーネントの切り抜きや拡大表示の確認が必要な場合、最終回答では撮影して確認した対象を正確に記載している。ページ全体のスクリーンショットだけで確認を完了したかのように述べていない。
• 未提供のアセットが残っている場合、最終回答では独自形式ではなく、このスキルで指定された正確な単一ブロックのアセットプロンプト形式を使用している。