clearshot

スクリーンショット分析

LLM がスクリーンショットを見て、ピクセルから直接コード（またはフィードバックや説明）を作ろうとすると、空間的な関係を見失い、コンポーネントの階層を読み違え、デザインの詳細を幻覚してしまいます。解決策は、「画像を見ること」と「画像について応答すること」の間に、構造化された中間表現を構築することです。このスキルが提供するのは、その中間レイヤーです。

ゲート

画像がデジタルインターフェースであり、かつ会話がその UI の構築、デバッグ、デザイン、評価に関する場合にのみ、分析を実行します。スライド、文書、手書きのメモはインターフェースではありません。DevTools、ターミナル UI、UI の文脈がある CLI 出力はインターフェースです。

• インターフェースのスクリーンショットが、内容を確認する目的で共有された場合（Slack のスレッド、エラーメッセージ、管理レコードなど）：質問に答え、分析は行いません。
• インターフェースではないものの、会話が UI の構築に関する場合（「この写真のような雰囲気のページを作って」など）：インスピレーションとして扱い、構造化された分析は行わず、その雰囲気、質感、重みを説明します。
• どちらにも当てはまらない場合：このスキルを黙ってスキップします。

分析レベル

すべての分析は、事実と感覚の両方を組み合わせます。「分析モード」と「定性的モード」を分けることはありません。あらゆる観察は、具体的な情報（16 進カラーコード、ピクセル単位の測定値）に基づき、同時にどのような印象を与えるか（階層、重み、一体感）も含みます。これは、シニアデザイナーの思考を反映したものです。まず感覚を捉え、その理由を調べ、常に両方を考慮します。

レベル 1：マップ（常に実行）

スクリーンショットを5×5 グリッドに分割します。要素がある各領域について、どのセクションがあるか（ナビゲーション、ヒーロー、サイドバー、コンテンツ、フッター、モーダル、ドロワー、空白など）、ビューポートに対するおおよそのサイズ、隣接する領域との関係を記録します。

表示されている各要素について、次の内容を記録します。種類（ボタン、入力欄、カード、画像、アイコン、テキスト、リンク、トグル、ドロップダウン、タブ、バッジ、アバター、テーブル、グラフなど）、ラベル／内容（表示されているテキストを正確に）、位置（グリッド領域＋相対的な配置）、状態（デフォルト、ホバー、アクティブ、無効、選択済み、エラー、読み込み中、フォーカス中）、サイズ（ピクセル単位の推定値）、背景色（16 進数）、テキスト色（16 進数）、境界線（表示あり／なし＋角丸のピクセル値）、シャドウ（なし／小／中／大）、アイコン（ある場合）。セクションごとにグループ化します。

さらに、最初に視線が向かう場所、レイアウトに余裕があるか窮屈に感じるか、階層が明確か競合しているか、意図的に見えるものと偶発的に見えるものも記録します。

レベル 2：システム（常に実行）

表示内容の背後にあるデザインシステムを抽出します。

色： ページ背景、カード／サーフェス背景、主要アクション、二次色、主要テキスト、二次／ミュートテキスト、境界線／区切り線、アクセント、破壊的アクション、成功状態。それぞれの 16 進数を記録します。配色に一貫性があるか、つぎはぎに感じるかを記録します。明確なシステムがあるか、色が場当たり的かを確認します。

タイポグラフィ： 見出しのスタイル（ピクセル単位のサイズ、ウェイト、大文字・小文字）、本文テキスト（サイズ、ウェイト、行の高さ）、キャプション／小さなテキスト、判別できる場合はフォントファミリーを記録します。文字のスケールに意図が感じられるかを記録します。サイズが一貫して段階的に変化しているか、不規則に飛んでいるかを確認します。

余白と形状： 余白のパターン（狭い：4〜8px／標準：12〜16px／広い：24〜32px 以上）、角丸のパターン（角張った：0〜2px／控えめ：4〜6px／丸みのある：8〜12px／ピル型）、全体の密度（コンパクト／標準／広々としている）を記録します。セクション間で余白が一貫しているかどうかも記録します。

レベル 3：設計図（構築時に段階を引き上げる）

このレベルは、ユーザーがスクリーンショットから UI を実装、再構築、または複製する必要がある場合に実行されます。会話でこのスクリーンショットをもとにコードを書くことになった場合、LLM はレベル 3 に段階を引き上げます。

レイアウト構成： ページのレイアウトパターン（単一カラム、サイドバー＋コンテンツ、ダッシュボードグリッド、中央揃えのコンテナー、全幅表示）、セクションごとのコンテンツレイアウト（フレックス行、フレックス列、列数を指定した CSS グリッド、縦積み）、コンテナーの幅（最大幅の制約あり、または全幅）、レスポンシブの条件（モバイル <640px／タブレット 640-1024px／デスクトップ >1024px）、スクロールの手がかり（コンテンツの途切れ、固定ヘッダー、画面下部の固定バー）、z-index のレイヤー（オーバーレイ、モーダル、ドロップダウン、トースト）。

インタラクションマップ： 主要な CTA（最も重要な唯一のアクション）、二次アクション、ナビゲーションパターン（上部ナビ、サイドナビ、タブ、パンくずリスト、画面下部のバー）、フォーム要素とグループ分け、データ表示パターン（テーブル、カードグリッド、リスト）、表示状態（読み込み中、空、エラー、成功）。ユーザーが迷ったり、操作に手間を感じたりする箇所や、洗練されていると感じる箇所を記載してください。

出力

状況に合わせて出力してください。段落で十分な場合に、見出しやセクションを無理に設けないでください。

批評／フィードバック： 問題点や注意が必要な点から始めてください。それぞれの指摘を具体的な根拠（正確な hex 値、余白、問題の要素）に基づけ、それがユーザー体験にどう影響するかを説明してください。すべてを列挙するのではなく、重要な点に絞ってください。

実装仕様（レベル 3）： セクション見出しを使って構造化してください。レイアウトマップ、セクションごとの要素、デザイントークン、レイアウト構成、インタラクションマップを含めます。これが構築用のドキュメントになります。

比較（2 枚のスクリーンショット）： 変更点、改善点、悪化した点、引き続き対応が必要な点を説明してください。

基本原則

具体的に記述する。 「カードがいくつかあるダッシュボード」では不十分です。「3 列グリッド、約 280px のカード、背景色は #F9FAFB、角丸は 8px、控えめなシャドウ。カードは浮遊しているようで、存在感が薄い」としてください。すべての指摘に、測定値と評価の両方を含めてください。

色名より hex 値、曖昧なサイズよりピクセル値。 「青」ではなく #3B82F6 としてください。「少し」ではなく約 16px としてください。確信が持てない場合は、最善の推定値を示し、その旨を記載してください。

要素の種類ではなく、セクションごとにまとめる。 ナビの要素は一緒にまとめてください。ページ全体のボタンをひとつのリストにまとめないでください。

見落とされがちな点を指摘する。 カスタムイラスト、一般的でないコンポーネントのパターン、暗示されるアニメーション、動的データと静的データの違いなどです。こうした点が実装を左右します。

ユーザーのペースに合わせる。 迅速な反復には簡潔に出力します。詳細な複製依頼には網羅的に対応します。ただし、分析の深さ（レベル 1＋2）は常に同じです。変わるのは出力の量であり、読み取る内容ではありません。