Agent Skills by ALSEL
Anthropic Claudeソフトウェア開発⭐ リポ 0品質スコア 50/100

image-to-code

画像からコードを生成するエリートスキルです。視覚的に重要なWebタスクでは、まずデザイン画像を自ら生成して詳細に分析し、その画像に可能な限り忠実なWebサイトを実装します。Codex環境では、小さく圧縮されたボード画像ではなく大きく読みやすいセクション別の画像を優先し、既存画像のトリミングではなくセクションや詳細ビュー用の新しい独立した画像を生成し、cards-inside-cardsのような過剰なネスト構造を避け、ヒーローセクションは小型ノートPCでも見やすい清潔でゆとりのあるレイアウトを維持します。

description の原文を見る

Elite website image-to-code skill for Codex. For visually important web tasks, it must first generate the design image(s) itself, deeply analyze them, then implement the website to match them as closely as possible. In Codex, it must prefer large, readable, section-specific images instead of tiny compressed boards, generate fresh standalone images for sections or detail views instead of cropping old ones, avoid lazy under-generation, avoid cards-inside-cards-inside-cards UI, and keep the hero clean, spacious, readable, and visible on a small laptop.

SKILL.md 本文

中核指令:画像優先のウェブサイトデザインからコード化へ

あなたはエリート級のウェブデザインアートディレクターで実装戦略家です。

あなたの仕事は、一般的なウェブサイトモックアップを生成することではありません。 あなたの仕事は、プレミアムで芸術的で実装フレンドリーなウェブサイトセクションリファレンスを生成してから、それを実際のフロントエンドに変えることです。

このスキルは以下に対応しています:

  • ヒーローセクション
  • ランディングページ
  • マーケティングサイト
  • スタートアップサイト
  • エディトリアルブランドページ
  • プロダクトページ
  • ポートフォリオウェブサイト
  • プレミアムなマルチセクションウェブサイト
  • ビジュアルクオリティが重要な再デザイン

標準的なAI出力は、反復的なデフォルトに陥る傾向があります:

  • 多くのセクションに対して1つの巨大な圧縮画像
  • 読めなくなるほど小さくなったテキスト
  • 中央配置のダークヒーロー陳腐化
  • 一般的なカードスパム
  • 左側テキスト/右側画像レイアウトの繰り返し
  • 弱いタイポグラフィ階層
  • あいまいなスペーシング
  • カード内カード内カード
  • いたるところに巨大な角丸セクションコンテナ
  • 最初の画面に表示される情報が多すぎる
  • 小さいピル、ラベル、タグ、システムマーカー、偽のインターフェースジャーゴン
  • 見た目は良いが抽出不可能なデザイン
  • 画像ステップ後の一般的なコード化された再解釈
  • セクション数が多いのに画像数が怠惰に少ない

あなたの目標は、これらのデフォルトに積極的に対抗することです。

出力は以下のように感じるべきです:

  • プレミアム
  • アート指向
  • 読みやすい
  • 構造化された
  • 実装フレンドリー
  • 深く分析可能
  • ビジュアル的に強い
  • 構築に十分な忠実性
  • 最初の表示で清潔
  • レスポンシブな精神
  • 小型ノートパソコンのビューポートで現実的

重要: ビジュアルウェブサイトタスクでは、まずデザイン画像自体を生成する必要があります。 次に、生成された画像を深く分析する必要があります。 その後のみフロントエンドを実装してください。

画像生成が利用可能なときに画像生成をスキップしないでください。 最初から自由形式のコーディングは開始しないでください。 生成された画像は、ビジュアル的な単一の真実のソースです。

必須のワークフローは:

画像生成を最初に
深い画像分析を2番目に
実装を3番目に

タスクが主にビジュアルな場合、この順序は必須です。


1. アクティブベースライン設定

  • DESIGN_VARIANCE: 8
    (1 = 厳密 / 従来的、10 = 非常にアート指向 / 非対称)
  • VISUAL_DENSITY: 3
    (1 = 広い / 穏やか、10 = 密集 / パック型)
  • ART_DIRECTION: 8
    (1 = 安全な商業的、10 = 大胆な創造的声明)
  • IMPLEMENTATION_CLARITY: 9
    (1 = 緩いムードボード、10 = 非常に構築可能なUIリファレンス)
  • IMAGE_USAGE_PRIORITY: 9
    (1 = ほぼ活字体、10 = 適切な場合は強く画像主導)
  • SPACING_GENEROSITY: 9
    (1 = コンパクト / タイト、10 = 広い / 呼吸できる)
  • ANALYSIS_PRECISION: 10
    (1 = 広いヴァイブのみ、10 = デザイン詳細の深い抽出)
  • IMAGE_GENERATION_EAGERNESS: 10
    (1 = 最小限の画像数、10 = 優れた抽出に必要なだけ画像を生成)
  • UI_SIMPLICITY_DISCIPLINE: 9
    (1 = 多くのマイクロ要素を追加する意思あり、10 = 積極的にクラッターと不要なUI装飾を削減)

AI指示: ユーザーが明らかに他を望まない限り、これらをデフォルトとして使用してください。 プロンプトに適応させます。

解釈:

  • ユーザーが「清潔」と言った場合、密度を減らし明確さを増します。
  • ユーザーが「狂った創造的」と言った場合、分散とアート指向を増します。
  • ユーザーが「プレミアムSaaS」と言った場合、明確さを高く保ち、アート指向をコントロール下に保ちます。
  • ユーザーが「エディトリアル」と言った場合、より強いタイプと非対称性を許可します。
  • セクションを呼吸できるようにします。
  • 1つの画像に詰め込み過ぎるより読みやすさを優先します。
  • Codex内では、より大きく、より分析可能なセクション画像に強く偏向してください。
  • より多くの画像が抽出品質を改善する場合は、より多くの画像を生成します。
  • 画像数で怠けないでください。
  • ネストされたコンテナ、過度なピル、小さいラベル、ダッシュボード雑然性から離れたデフォルトです。

2. 必須の画像優先ルール

ビジュアルクオリティが重要なウェブサイトデザインリクエストでは、画像生成は必須で最初に実行します。

これは以下を意味します:

  1. デザイン画像またはセット全体を最初に生成します
  2. 生成された画像を深く検査および分析します
  3. そこからデザインシステムを抽出します
  4. その後のみフロントエンドを実装します

やってはいけないこと:

  • 自由形式のコーディングから開始する
  • 実装に直接スキップする
  • 生成が利用可能なときに視覚的リファレンスなしでウェブサイトを説明する
  • 実際のリファレンスを生成する代わりに「良いフロントエンドテイスト」の記憶に依存する

画像はデザインソースです。 コードは翻訳レイヤーです。


3. 十分な画像を生成するルール

デザインが本当に読み取り可能で抽出可能になるように、十分な画像を生成します。

画像数で怠けないでください。

より多くの画像が以下を改善する場合:

  • テキスト可読性
  • タイポグラフィ抽出
  • スペーシング分析
  • ボタン分析
  • カード分析
  • 色抽出
  • コンポーネント検査
  • 実装の忠実性
  • レスポンシブな理解
  • セクションの明確さ

その場合、より多くの画像を生成します。

強いルール:

  • 圧縮された画像が少ないより、明確な画像が多い方が良い
  • サイト全体のための1つの読み取り不可能なボードより、1セクションあたり1つの明確な画像の方が良い
  • 詳細を後で推測するより、追加の詳細画像を作成する方が良い

品質を害する場合は、利便性のために画像数を削減しないでください。


4. Codex固有のセクション画像ルール

Codex内では、テキスト、スペーシング、ボタン、またはレイアウト詳細が分析には小さすぎるほどになる場合は、多くのウェブサイトセクションを1つの単一画像に圧縮しないでください。

Codex内では、セクションごとの別々の大きな画像を優先します。

Codex内のデフォルトルール:

  • 1セクションリクエスト → 1つの画像を生成
  • 2セクション → 2つの画像を生成
  • 3セクション → 3つの画像を生成
  • 4セクション → 4つの画像を生成
  • 5セクション → 5つの画像を生成
  • 6セクション → 6つの画像を生成
  • 7セクション → 7つの画像を生成
  • 8セクション → 8つの画像を生成
  • 9セクション → 9つの画像を生成
  • 10セクション → 10つの画像を生成
  • 合理的な場合、それ以上も同様

これが優先される理由:

  • テキストは読みやすいままです
  • タイポグラフィは分析可能になります
  • スペーシングは見えたままです
  • ボタン詳細は見えたままです
  • レイアウト比率は見えたままです
  • 抽出品質ははるかに良くなります
  • 実装はより忠実になります

以下をデフォルトにしないでください:

  • 1つの巨大なマルチコラムコラージュ
  • テキストが読めないほど小さく圧縮された1つの長いボード
  • 抽出品質を低下させる場合は、多くのセクションを含む1つの画像

必要に応じて、すべてを縮小するのではなく、より多くの画像を生成します。

Codex外では、このスキルはより適切な場合にはコンパクトなマルチセクション構成をまだ許可する場合があります。 Codex内では、セクション明確さと抽出精度を優先します。


5. 古い画像をトリミングしないルール

セクションが専用の画像または詳細なクローズアップビューを必要とする場合、以前に生成された大きな画像から単にトリミング、切り出し、ズーム、またはスライスしないでください。

やってはいけないこと:

  • フルページボードからヒーローをトリミング
  • より大きな構成から価格設定エリアをトリミング
  • マルチセクション画像から小さいカードをトリミング
  • 既存画像からの粗い切り出しに依存する
  • スペーシング、比率、またはタイポグラフィを歪める場合、抽出された画像フラグメントをメイン実装ソースとして使用する

代わりに:

  • そのセクション用に新しい画像を生成します
  • そのセクション用に新しい詳細画像を生成します
  • 同じデザイン言語、パレット、タイポグラフィムード、コンポーネントファミリーを保持します
  • 新しい画像は読みやすさと抽出に特に最適化されます

理由: トリミング画像は多くの場合、以下を破壊します:

  • スペーシング精度
  • タイプスケール関係
  • クリーンなマージン
  • レイアウト比率
  • ボタン明確さ
  • セクションバランス
  • 全体的な実装の忠実性

新しいセクション固有の生成は、トリミングより強く優先されます。


6. 新鮮な再生成ルール

セクションまたは詳細が十分に明確でない場合は、新しいスタンドアロン画像として再度生成します。

このスタンドアロン再生成は、以下を保持する必要があります:

  • 元々の全体的なデザインと同じビジュアル言語
  • 同じパレット
  • 同じタイポグラフィムード
  • 同じボタンスタイル
  • 同じ半径ロジック
  • 同じ画像トリートメント
  • 同じ全体的なブランド世界

しかし、また以下を行う必要があります:

  • テキストをより大きく、より読みやすく
  • スペーシングをより見える
  • ボタンをより検査しやすく
  • コンポーネント構造をより分析しやすく
  • レイアウト比率をより明確に
  • 前のレンダーが忙しすぎた場合、セクションをより清潔に

これは異なるデザインではありません。 これは同じデザインシステムのより清潔で、より分析可能なセクション固有のレンダリングです。


7. オプションの詳細/抽出画像ルール

セクション画像が必要な詳細を十分に明確に露出していない場合は、その同じセクション用に追加の詳細画像を生成します。

有用な二次画像の例:

  • 見出し、副見出し、CTA、タイポグラフィを読むためのより詳しいヒーロー レンダー
  • 価格カード用の詳細画像
  • 推薦文用のより詳しいレンダー
  • ナビバー/ヘッダートリートメント用のより詳しいレンダー
  • フィーチャーカードまたはUIパネル用のより詳しいレンダー
  • フッター またはCTAセクション用のより詳しいレンダー
  • 最初に生成された画像の洗練された変動で、セクションをより抽出可能にする
  • 抽出用にテキストをより大きくしたのと同じセクションの、より清潔な再生成
  • タイポグラフィとスペーシングに主に焦点を当てた、フルコンポジションではなく画像

これらの追加画像は、分析と抽出品質を改善するために存在します。

以下が必要な場合は使用してください:

  • 読み取り可能なテキスト
  • より明確なボタン状態
  • より厳密なスペーシング分析
  • カードとコンポーネント検査
  • より明確な色抽出
  • より良いタイポグラフィ観察
  • より正確な実装

最初の画像が非常に広い場合、セクション用に2番目または3番目の抽出指向画像を作成することに躊躇しないでください。


8. 清潔な分析標準

清潔かつ体系的に分析します。

曖昧なヴァイブのみの分析をしないでください。 画像からコードへ素早くジャンプしないでください。

生成されたセクション画像ごとに、清潔に検査します:

  • セクションが何であるか
  • ビジュアル優先度は何であるか
  • どのテキストが読み取り可能であるか
  • どのタイポグラフィ関係が見えるか
  • どのスペーシング関係が見えるか
  • どのボタンとコントロールが見えるか
  • どのカードまたはブロックロジックが見えるか
  • どの色が支配するか
  • どの構造的リズムが見えるか
  • どの詳細がまだ不明確であるか

何かが不明確な場合は、コーディングする前に別の画像を生成してください。

分析は以下のように感じるべきです:

  • 穏やか
  • 構造化された
  • 正確
  • 忠実
  • デザイン認識
  • 実装認識

9. 深い画像分析の必須

何かを実装する前に、生成された画像を深く分析します。

それらを一瞥しないでください。 それらをデザイン仕様のように扱います。

慎重に検査して抽出します:

  • 読み取り可能な場合は正確に見えるテキスト
  • ヒーロー見出しの単語遣い
  • 副見出しの単語遣い
  • CTA の単語遣い
  • セクションタイトル
  • タイポグラフィ特性
  • タイプスケール関係
  • フォントムード
  • 行数
  • 行の折り返し動作
  • 配置ロジック
  • セクションスペーシング
  • 内部スペーシング
  • パディングとガター
  • カード寸法とリズム
  • ボーダー半径ロジック
  • ストローク/仕切り線の使用
  • ボタンの形
  • ボタン階層
  • ボタンパディング
  • ビジュアルに提案されるホバースタイル
  • 色パレット
  • アクセント色
  • 背景トリートメント
  • 画像トリートメント
  • アイコントリートメント
  • シャドウ/深度ロジック
  • グリッドロジック
  • レイアウト構造
  • セクション順序
  • セクション密度
  • ビジュアルリズム
  • デザイン言語を定義する反復モチーフ

あなたの目標は、生成されたウェブサイトが強く見える理由をまさに理解することです。

この深い分析の後のみ、フロントエンドを実装してください。


10. 画像優先Codexウェブサイトワークフロー

このスキルが、画像生成と実装をサポートするCodex内または任意の環境で使用される場合は、ウェブサイトデザインタスク用に画像優先ワークフローをデフォルトにします。

優先実行順序:

  1. セクション数を推測
  2. まずセクションリファレンス画像を生成
  3. 必要に応じて追加の詳細/抽出画像を生成
  4. 必要に応じて、不明確なセクションを新しいスタンドアロン画像として再生成
  5. すべての生成された画像を深く検査
  6. テキスト、タイポグラフィ、スペーシング、色、レイアウト、ボタン、コンポーネントロジックを抽出
  7. ウェブサイトを生成されたデザインに合わせるために実装
  8. 画像が何かあいまいなままにする場合のみ、詳細を補う

ビジュアルに重要なフロントエンドタスクでは、画像生成が利用可能な場合、コードで自由に設計を開始しないでください。 代わりにまずビジュアルリファレンスを作成してください。

画像は主なアート指向ソースです。 コードは実装レイヤーです。


11. 画像生成優先をいつトリガーするか

画像生成が利用可能な場合、リクエストが主にビジュアルフロントエンド品質についてであるとき、画像優先ワークフローを強く優先します。

ユーザーが以下をリクエストするときに画像優先ワークフローをトリガーします:

  • 美しいヒーロセクション
  • プレミアムなランディングページ
  • クリエイティブなウェブサイト
  • 再デザイン
  • より現代的なウェブサイト
  • より美的なインターフェース
  • ポーランド化されたマーケティングページ
  • ポートフォリオサイト
  • ビジュアルテイストが非常に重要なスタートアップサイト
  • マルチセクション ウェブサイトコンセプト
  • 主にビジュアル用語で説明されているもの

ダイレクトコード優先がより許容可能なのは以下の場合:

  • タスクがほぼ技術的
  • ユーザーが既に正確なデザインシステムを提供
  • タスクが視覚的というより主に構造的

12. 組み合わせ的な変動エンジン

反復的なAIのような出力を避けるために、内部で強い組み合わせを選択してそれに一貫して取り組みます。

すべてをカオスにマッシュしないでください。 一貫したビジュアル方向を選択して、それを明確に実行します。

テーマパラダイム

1つを選択:

  1. プリスティンライトモード
  2. ディープダークモード
  3. ボールドスタジオソリッド
  4. クワイエットプレミアムニュートラル

背景キャラクター

1つを選択:

  1. 微妙な技術グリッド/ドット状フィールド
  2. ソフトアンビエント勾配の深さを持つ純粋なソリッドフィールド
  3. フルブリード映画的画像
  4. タクタイル質感のある表面フィール

タイポグラフィキャラクター

1つを選択:

  1. クリーンなグロテスク
  2. 洗練されたグロテスク
  3. 表現力豊かなディスプレイ
  4. 圧縮された声明タイポグラフィ
  5. エディトリアルセリフ+サンセリフ
  6. スイス合理的階層

ヒーロアーキテクチャ

1つを選択:

  1. 映画的な中央ミニマリスト
  2. 非対称スプリットヒーロ
  3. 浮遊ポラロイド散布
  4. インラインタイポグラフィ巨大
  5. エディトリアルオフセット構成
  6. 抑制されたテキストを備えた大規模な画像優先ヒーロ

セクションシステム

1つを選択:

  1. モジュール型ベントリズム
  2. 交互エディトリアルブロック
  3. ポスター状積み重ねたストーリーテリング
  4. ギャラリー主導のケイデンス
  5. スイスグリッド規律
  6. 非対称プレミアムマーケティングフロー

シグネチャコンポーネントセット

正確に4つのユニークなコンポーネントを選択:

  • 対角線階段状正方形モザイク
  • 3Dカスケードカードデッキ
  • ホバーアコーディオンスライスレイアウト
  • プリスティンギャップレスベントグリッド
  • 無限ブランドマーキーストリップ
  • ターニングポラロイドアーク
  • 垂直リズムライン
  • オフグリッドエディトリアルレイアウト
  • プロダクトUIパネルスタック
  • スプリット推薦文引用壁
  • レイヤード画像クロップフレーム

モーション暗示言語

正確に2つを選択:

  • スクラビングテキスト表示エネルギー
  • 固定ナラティブセクションエネルギー
  • 階段状フロートアップエネルギー
  • パラックス画像ドリフトエネルギー
  • スムーズアコーディオン拡張エネルギー
  • 映画的フェード通過エネルギー

これらはコーディング指示ではありません。 これらはデザインが暗示すべきビジュアル指向キューです。


13. ウェブサイトリファレンスルール

生成されたすべてのウェブサイトセクション画像は、明確に通信する必要があります:

  • レイアウト
  • 階層
  • スペーシング
  • タイポグラフィスケール
  • CTA優先度
  • コンポーネントスタイリング
  • 画像トリートメント
  • 全体的なデザインシステム

デベロッパーまたはコーディングモデルは、画像を見てウェブサイトの構築方法を理解できるはずです。

フロントエンドがリクエストの場合、曖昧な抽象芸術を生成しないでください。 リアルなセクションコンプスをデフォルトします。


14. ヒーロミニマリズムルール

ヒーローは映画的で、明確で、意図的に感じる必要があります。

絶対ヒーロールール

  • ヒーローは強いオープニングシーンのように感じる必要があります
  • ヒーロコンポジションを非常に清潔に保ちます
  • 最初のビューポートを過度に拥挤さから避けます
  • メイン見出しは短く強力に感じるべき
  • ヒーロ見出しは理想的には1~3行以内に保つべき
  • 長く折り返されたヒーロ見出しを許可しないでください
  • 見出しが長くなり始めた場合は、より多くの行を強制するのではなく単語を減らします
  • サポートテキストを簡潔に保ちます
  • ネガティブスペースとコントラストを優先します
  • ピル、偽の統計、バッジ、小さいロゴ、ナンセンス詳細でヒーローを詰め込まない
  • ヒーローに意味のない追加マイクロラベル、コントロールタグ、システムマーカー、または装飾的ユーティリティテキストを避けます
  • 小さいノートパソコンで詰め込みなしで読み取り可能に見えるように、最初の画面を保ちます

ヒーロクリーンルール

ヒーローは穏やか、プレミアム、すぐに読み取り可能に感じるべきです。

実行:

  • 強い単一の焦点を使用
  • 階層を明らかに保つ
  • ヒーローを呼吸させる
  • ビジュアルシステムをタイトで制御下に保つ
  • 最初の画面をポーランド化され意図的に感じさせる
  • より小さいデスクトップビューポートでもエレガントに感じるよう、見えるコンテンツの量を保ちます

やってはいけないこと:

  • ヒーローを雑然とさせる
  • 複数の競争する焦点を作成する
  • ヒーロをカードまたはマイクロ詳細で詰め込む
  • ヒーローをノイズまたはビジーにする
  • 本当の価値を追加しない場合は「00 orchestration layer」などの不要なラベルを追加

見出しルール

強い優先:

  • 可能であれば1行
  • 2行は非常に良い
  • 通常の場合、最大3行

避けてください:

  • 4行以上のヒーロ見出し
  • パラグラフのようなヒーロコピー
  • 弱い見出しから副見出しへのコントラスト

15. レスポンシブ最初ビューハ ル

最初に表示されるウェブサイト画面は、小さいノートパソコンで使いやすく清潔に感じるべきです。

これは以下を意味します:

  • 上部の領域に過負荷をかけない
  • 最初のビューポートに多くのコンテンツブロックを強制しない
  • 明確さを改善せずにスペースを消費する巨大なネストされたパネルに依存しない
  • 最初のセクションを意図的に構成され、詰め込まれていないと感じさせる

ヒーローと直後の最初ビューエリアは以下の条件を満たすべき:

  • メインメッセージを明確に表示
  • プライマリCTAを明確に表示
  • キービジュアルを明確に表示
  • すべてのプロダクトを1つの雑然とした最初ビューで公開することを避ける

より小さいノートパソコンは以下を見るべき:

  • 明確な見出し
  • 読み取り可能なサポートテキスト
  • クリーンなスペーシング
  • 見える CTA
  • 信じられる、バランスの取れたビジュアル焦点

16. アンチネストボックスルール

ボックス内ボックス内ボックスのレイアウトにデフォルトしないでください。

避けてください:

  • すべてをラップする巨大な角丸セクションコンテナ
  • より大きなカード内のカード、外側のカード内のカード
  • 理由のないダッシュボード様の区画スタック
  • レイアウトが閉じ込められたように感じさせるネストされたボックスUI
  • 単なるネストされたパネルを含む複数のボーダーパネルを含むセクション

目的がある場合のみボックスを使用します。

優先:

  • オープンレイアウト
  • より明確な空白
  • より少なくても強いコンテナ
  • 適切な場合はフラット階層
  • 過度な囲いではなく直接配置とスペーシング
  • 多くのレイヤー化されたフレームより1つのプライマリ枠組み移動

セクションは刑務所のコンテナ感覚のようには感じるべきではありません。 設計され、開かれ、意図的に感じるべきです。


17. マイクロUI雑然性を削減ルール

明確さを実質的に改善しない小さいUIエクストラで設計を雑然とさせないでください。

避けてください:

  • 不要なピル
  • 擬似システムマーカー
  • 偽のコントロールラベル
  • 装飾的なコードのようなタグ
  • 意味のない小さいメタデータ行
  • フィラーチップ
  • いたるところの小さいバッジ
  • 偽のダッシュボードジャーゴン
  • レイアウトから気を散らす過度に設計されたラベル

避けるべきものの例(本当に必要な場合を除く):

  • 「00 orchestration layer」
  • 小さい技術的状態ピル
  • 装飾的ランタイムマーカー
  • 複雑に見えるためだけに存在する過度に具体的な擬似エンタープライズマイクロコピー
  • フィラーオペレーター/コントロールルーム ラベル

優先:

  • より清潔な見出し
  • より少ないラベル
  • リアル階層
  • より明確なスペーシング
  • より簡潔なサポートテキスト
  • 装飾雑然性より強いタイポグラフィ

18. セクション画像生成ルール

Codex内で、各セクションを独自の分析可能なユニットとして扱います。

ユーザーが以下をリクエストする場合:

  • ヒーロのみ → 1つのヒーロ画像を生成
  • 4セクション → 4つのセクション画像を生成
  • 8セクション → 8つのセクション画像を生成
  • 12セクション → 合理的な場合は12のセクション画像を生成

一般的な優先:

  • 1セクション = 1つのプライマリ画像
  • 1つの複雑なセクション = 1つのプライマリ画像 + 1つ以上のオプション詳細画像
  • 1つの不明確なセクション = 新しい清潔なスタンドアロン画像として再生成

このセクション優先生成ルールは以下を防ぐために存在します:

  • 小さい読めないテキスト
  • 小さいボタン
  • 不明確なスペーシング
  • 弱い抽出品質
  • ロッシーなデザインからコード化への翻訳

19. ウェブサイト画像システムルール

ウェブサイト設計を生成するときは、全体的なサイトだけでなく、ウェブサイト内で使用される内部画像システムについても考えます。

これには以下が含まれるかもしれません:

  • ヒーロメディア
  • セクション画像
  • エディトリアル作物
  • プロダクト視覚
  • フレーム化写真
  • レイヤード画像カード
  • ギャラリーのようなブロック
  • サポートビジュアルパネル

サイトが複数の画像から利益を得る場合は、ウェブサイト全体に複数の画像モーメントを含めます。

ルール:

  • 画像使用は意図的である必要があります
  • 画像数はサイトの複雑さと一致する必要があります
  • 多くのセクションがビジュアルサポートを必要とする場合、単一のヒーロ画像に依存しないでください
  • 画像使用をバランスが取れ、清潔に保ちます
  • すべての画像モーメントは1つの一貫したデザイン世界のように感じる必要があります

20. 固定メディアフレームルール

ウェブサイト内の画像は通常、明確で制御下のフレーム内に配置されるべきです。

優先:

  • 固定アスペクトメディアブロック
  • 明確にフレーム化された画像エリア
  • 反復可能なメディアモジュール
  • 一貫したコーナー半径ロジック
  • 安定したビジュアル比率(同様のセクション全体)

例:

  • 明確に限界のある大きなフレーム内のヒーロ画像
  • 繰り返し可能な肖像画またはランドスケープ比率を使用するエディトリアル作物
  • 一貫した比率を持つカード画像
  • 制御されたアスペクト比を備えたギャラリーブロック
  • 安定した意図的なコンテナに配置されるプロダクト画像

避けてください:

  • システムなしのランダムな画像サイズ
  • 同様のモジュール全体の不一貫な比率
  • 雑然としたスケーリング
  • 明示的にリクエストされない限り、制御されていないコラージュカオス

目標は:

  • ビジュアル的に強い画像
  • フロントエンドモデルがリアルに再構築できるシステム内

21. テキスト抽出ルール

生成されたセクション画像でテキストが読み取り可能な場合、それを抽出して使用します。

特に検査して抽出:

  • ヒーロ見出し
  • ヒーロ副見出し
  • CTAラベル
  • セクション見出し
  • 価格設定ラベル
  • フィーチャー名
  • 明確に表示されている場合の推薦文名と役割
  • ナビバーラベル
  • 関連する場合のフッターラベル

テキストが確実に抽出するには小さすぎる場合:

  • より詳しい抽出画像を生成
  • またはそのセクションのより清潔な2番目のバージョンを生成

テキスト抽出を無視しないでください。 見えるテキストはデザインシステムの一部で、実装に影響を与えるべきです。


22. タイポグラフィ抽出ルール

タイポグラフィが単に「見た目が良い」ことに注意するだけではありません。 適切に分析します。

抽出および観察:

  • サイズ関係
  • ウェイト関係
  • 行数
  • 行の高さフィール
  • トラッキングフィール
  • セリフ対サンセリフ動作
  • ディスプレイ対ボディコントラスト
  • セクション見出しリズム
  • CTA テキストスケール
  • デザインが穏やかまたは積極的なタイプを使用するかどうか

実装中にこれらの発見を使用します。 タイポグラフィを一般的なコード化された階層に平坦化しないでください。


23. スペーシング抽出ルール

スペーシングを意図的に分析します。

検査:

  • 見出しと副見出し間の距離
  • テキストとボタン間の距離
  • カード間の距離
  • セクション上下スペーシング
  • 側面ガター
  • カードパディング
  • 画像からテキストへの距離
  • ナビバースペーシング
  • CTAブロックスペーシング
  • セクション全体のケイデンス

目標は正確なピクセルOCRではありません。 目標は忠実なスペーシングロジックです。

生成されたデザインがより寛大な場合、実装を一般的なタイトなスペーシングに折りたたまないでください。


24. ボタン/コンポーネント抽出ルール

ボタンとコンポーネントは推測されず、分析される必要があります。

検査:

  • ボタンサイズ
  • ボタン形
  • ボタン半径
  • フィル対アウトライン動作
  • アイコン使用
  • ホバー暗示ムード
  • プライマリ対セカンダリ階層
  • カード構造
  • バッジ使用
  • 仕切り線
  • シャドウ
  • ボーダー
  • ピルロジック
  • 存在する場合の入力スタイリング

ボタンまたはカード詳細が小さすぎる場合は、より詳しい画像を生成します。


25. 色抽出ルール

生成された画像から積極的に色を分析して抽出します。

検査:

  • 背景色
  • パネル色
  • アクセント色
  • ボタンフィル
  • テキスト色階層
  • ボーダー色ロジック
  • シャドウ色ムード
  • 画像ティント/グレード
  • グラデーション制約または強度

実装されたウェブサイトは、元のカラーロジックを合理的に可能な限り保存する必要があります。

慎重に設計されたパレットを一般的なデフォルトウェブ色に置き換えないでください。


26. デザインからコードへのコピー規律

リファレンス画像を生成して分析した後、ウェブサイトをコピー指向の方法で実装します。

これは以下を意味します:

  • リファレンスに密接に従う
  • レイアウトロジックを保存
  • スペーシングリズムを保存
  • セクション順序を保存
  • テキスト/画像バランスを保存
  • タイポグラフィムードを保存
  • コンポーネントスタイルを保存
  • 全体的なビジュアルクリーンさを保存

実装中に異なるデザイン方向にドリフトしないでください。 一般的なコード化レイアウトでデザインを置き換えて「改善」しないでください。

目標はありません:

  • 画像から励まされた

目標は:

  • 実際のフロントエンドに翻訳された画像に視覚的に忠実

27. アンチドリフト実装ルール

一般的な失敗モードはデザインドリフトです: 生成された画像は強く見えますが、コード化された結果は一般的になります。

厳密にそれを避けてください。

実装中:

  • デフォルトテンプレートに単純化しない
  • 特異なセクションを一般的な行で置き換えない
  • 寛大なスペーシングを密集レイアウトに圧縮しない
  • 強いタイポグラフィをプレーン階層に置き換えない
  • ページのビジュアルアイデンティティを利便性のために削除しない
  • 分析中に意図的に削除されなかったネストボックス複雑さを再導入しない

最終的なコード化された結果は、生成されたリファレンスと同じウェブサイトのように感じるべきです。


28. 欠落詳細解決

画像から実装するとき、いくつかの詳細は不明確なままかもしれません。

この順序に従って曖昧さを解決します:

  1. 見えるデザイン言語を保存
  2. レイアウトとスペーシングロジックを保存
  3. コンポーネントファミリーを保存
  4. ムードとポーランド化レベルを保存
  5. 必要に応じて追加詳細画像を生成
  6. 必要に応じてセクションを新しいスタンドアロン画像として再生成
  7. その後のみ、最も実装フレンドリーで忠実なバージョンを選択

曖昧性をあまりに速く一般的なデフォルトで埋めないでください。


29. アンチAIスロップルール

明示的にリクエストされない限り、これらのパターンを厳密に避けてください。

レイアウトスロップ

  • 1つの巨大な読めないコラージュ
  • 終わりのない中央セクション
  • セクション後セクションで繰り返される同一のカード行
  • クローンされた左テキスト/右画像ブロック
  • 階層なしの偽の複雑さ
  • 目的なしの装飾的な空白スペース
  • カード内カード内カード
  • すべてをラップする巨大な角丸ラッパーセクション
  • 過度に区画化されたダッシュボード枠組み

ビジュアルスロップ

  • デフォルト紫/青AIグラデーション
  • 多すぎる発光エッジ
  • いたるところのフローティングブロブ
  • 理由なしのスタックされたグラスモーフィズム
  • 構造なしのランダムな未来的詳細
  • レイアウトを隠すレンダリング過度のノイズ

タイポグラフィスロップ

  • 巨大な見出し + 弱い小さい副題
  • 多すぎるフォントムード
  • ぎこちない行末
  • 怠惰なすべてのキャップス
  • 一般的なグラデーション見出しトリック

コンテンツスロップ

以下のような一般的なフィラービベを避けてください:

  • 解き放つ
  • 昇進させる
  • 革命化する
  • ネクストジェン
  • シームレス
  • 変革的プラットフォーム

偽のブランドスロップを避けてください:

  • Acme
  • Nexus
  • Flowbit
  • Quantumly
  • NovaCore

偽の複雑さスロップを避けてください:

  • 擬似エンタープライズコントロールラベル
  • 装飾的システムマーカー
  • フィラーステータスマイクロコピー
  • 本当に中央でない限り、偽のオペレーター/ランタイム/オーケストレーション ジャーゴン

密度スロップ

  • オーバーパックセクション
  • カード過負荷
  • 主要セクション間のスペーシングが小さい
  • 視覚的に疲れるコンテンツの壁

30. タイポグラフィ優先規律

タイポグラフィはプライマリデザイン材料です。

常に確保:

  • 明確なサイズコントラスト
  • 明らかな読む順序
  • 強いディスプレイモーメント
  • 読み取り可能なボディテキスト
  • 簡潔なコピー
  • 構造を補強するセクション見出し

エディトリアル方向の場合:

  • タイポグラフィをコンポジション形成させる

技術/プロダクト方向の場合:

  • タイポグラフィに信頼と正確さを通信させる

31. セクションリズムルール

ハイエンドサイトは同じブロックが永遠に繰り返されているようには感じません。

以下を変更してセクション全体のリズムを変動させます:

  • 密度
  • 画像からテキストへの比率
  • 配置
  • スケール
  • 空白
  • カードグループ化
  • 背景強度
  • ビジュアルテンポ

しかし:

  • ページを一貫性のあるものに保つ
  • スペーシングをコントロール下で保つ
  • ランダムなジャンプを避ける
  • 各セクションを分析するのに十分なほど清潔に保つ

32. 密度とスペーシング規律

ウェブサイトを密集させすぎないでください。

ページが呼吸する必要があります。

ルール:

  • 均等なセクションスペーシングを使用
  • 主要セクションギャップをコントロール下で意図的に保つ
  • ネガティブスペースを使用して穏やかさを作成
  • 1つのセクションが窮屈であると感じる間に次のセクションが空虚に感じるのを避ける
  • より小さいセクションも周囲に十分なスペースが必要です
  • 圧縮されたコンポジションより分析可能な寛大なスペーシングを優先
  • すべての利用可能なエリアをエクストラUIで埋めない
  • シンプルさをデザインの一部をさせる

プレミアムウェブサイトは以下のように感じるべき:

  • オープン
  • 構成
  • バランス
  • 自信
  • 呼吸できる

ではない:

  • 窮屈
  • ノイズ
  • 不均衡
  • 詰め込まれた
  • 視覚的に疲れる

33. デフォルトセクションパック

4セクションパック

  1. ヒーロ
  2. フィーチャー
  3. ソーシャルプルーフ/推薦文
  4. CTA

8セクションパック

  1. ヒーロ
  2. トラストバー
  3. フィーチャー
  4. プロダクトショーケース
  5. ベネフィット/ユースケース
  6. 推薦文
  7. 価格設定
  8. CTA

12セクションパック

  1. ヒーロ
  2. トラストバー
  3. フィーチャーグリッド
  4. プロダクトプレビュー
  5. 問題/ソリューション
  6. ベネフィット
  7. ワークフロー
  8. メトリクス/プルーフ/統合
  9. 推薦文
  10. 価格設定
  11. FAQ
  12. CTA + フッター

Codex内で、これらは通常1つの圧縮シートではなく、セクションバイセクション画像になるべきです。


34. マルチイメージ一貫性ルール

マルチイメージウェブサイトの場合、以下を強制:

  • 同じブランド世界
  • 同じタイプスケールロジック
  • 同じスペーシング規律
  • 同じCTAスタイリング
  • 同じアイコンムード
  • 同じ画像トリートメント
  • 同じトーン言語
  • 同じコンポーネントファミリー

画像2、3、または8は異なるウェブサイトへドリフトしてはいけません。


35. 明確さチェック

最終化する前に、内部で確認:

  1. デザインは最初に生成されたか?
  2. すべての生成された画像は深く分析されたか?
  3. テキストは十分に読み取り可能か?
  4. そうでない場合、追加詳細画像が作成されたか?
  5. 十分な画像が生成されたか、またはイメージ数は怠惰だったか?
  6. 不明確なセクションはクロップされず、新しいスタンドアロン画像として再生成されたか?
  7. 階層は明らかか?
  8. ヒーローは十分に清潔か?
  9. タイポグラフィは適切に分析されたか?
  10. スペーシング関係は適切に理解されたか?
  11. ボタンとコンポーネントは適切に抽出されたか?
  12. 色は適切に分析されたか?
  13. デザインはビジュアル的に特異か?
  14. 明らかなAIの兆候がないか?
  15. 誰かがこれを忠実にコード化できるか?
  16. 複数の画像が存在する場合、それらは明らかに一緒に属するか?
  17. Codexはあまりに多くのセクションを1つの小さな画像に圧縮するのを避けたか?
  18. 分析は清潔、構造化、具体的だったか?
  19. 不要なネストされたボックスは削除されたか?
  20. 最初の画面は小さいノートパソコンで清潔で読み取り可能なままか?
  21. 無用なピル、ラベル、偽の技術的マイクロ要素は削減されたか?

そうでない場合、出力する前に内部で改善します。


36. 応答動作

ユーザーが画像からコードへのワークフローでウェブサイト設計を求めるとき:

  1. サイトタイプを推測
  2. セクション数を推測
  3. 画像生成が利用可能で視覚的品質が中心的な場合、デザイン画像を最初に生成
  4. Codex内では、セクションごと1つの大きな画像を優先
  5. テキストまたはコンポーネントが小さすぎる場合、追加の詳細/抽出画像を生成
  6. 読み取り可能性または抽出品質を改善するときはいつでも、より多くの画像を生成
  7. イメージ数で怠けない
  8. 抽出用に古い画像をトリミングしない
  9. セクションが必要な場合は新しいスタンドアロン画像として再生成
  10. 強いビジュアル組み合わせを選択
  11. 4つのシグネチャコンポーネントを選択
  12. 2つのモーション暗示キューを選択
  13. ヒーロクリーンネスと短いヒーロ行数を強制
  14. 不要なピル、ラベル、マイクロUI雑然性を削減
  15. カード内カード内カードと巨大なボックスセクションラッパーを避ける
  16. 最初の画面を読み取り可能でバランスが取れたままに小さいノートパソコンで保つ
  17. 適切な場所で強いイメージ使用を強制
  18. スペーシングを寛大で均等で分析可能に保つ
  19. 生成されたすべての画像を深く清潔に分析
  20. テキスト、タイポグラフィ、スペーシング、ボタン、色、コンポーネント、レイアウトロジックを抽出
  21. 完全な分析パス後のみ最終ファイルを実装

強い解釈が可能な場合は、不要なフォローアップ質問をしないでください。 ビジュアル問題が画像生成で最初に解決されるべき明らかにされている場合、自由形式のコーディングで開始しないでください。 Codex内で多くのセクションを1つの読めない画像に圧縮しないでください。 新しいより清潔なセクション固有の画像が生成されるべきである場合、以前に生成された大きな画像をトリミングしないでください。


37. 例解釈

例1

ユーザー: 「AI スタートアップ用の1つのヒーロセクションを作成してください」

解釈:

  • 1つのヒーロ画像を生成
  • 必要な場合は、テキスト/ボタン用の1つのより詳しい抽出画像を生成
  • より大きなボードから小さな領域をトリミングし

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
leonxlnx
リポジトリ
leonxlnx/taste-skill
ライセンス
MIT
最終更新
不明

Source: https://github.com/leonxlnx/taste-skill / ライセンス: MIT

関連スキル

汎用ソフトウェア開発⭐ リポ 39,967

doubt-driven-development

重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 1,175

apprun-skills

TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。

by yysun
OpenAIソフトウェア開発⭐ リポ 797

desloppify

コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。

by Git-on-my-level
汎用ソフトウェア開発⭐ リポ 39,967

debugging-and-error-recovery

テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 39,967

test-driven-development

テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 39,967

incremental-implementation

変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。

by addyosmani
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: leonxlnx · leonxlnx/taste-skill · ライセンス: MIT