Image-to-Code for Stacks（Stacks用画像からコードへの変換）
関連スキル: stacks-design-taste, stacks-imagegen-web, stacks-stx, stacks-crosswind, stacks-ui
このスキルは、画像ファーストのパイプラインです。 (1) プレミアムなウェブサイト参照画像を生成し、(2) それらを深く分析し、(3) Stacksでフロントエンドを実装して一致させます。生成フェーズと分析フェーズはフレームワークに依存しません。実装フェーズはStacksネイティブです。stxテンプレート、Crosswindユーティリティ、stx composables、Iconifyアイコン、CSSを使用します。
基礎となるデザイン判断（パレットの規律、タイポグラフィのセンス、アンチスラップルール、スペーシングシステム）については、主要なテイストスキルである stacks-design-taste に従います。このスキルはパイプラインとそのStacks実装ターゲットに焦点を当て、stacks-design-tasteと組み合わせて使用するため、そのルールをすべて再記述するわけではありません。
中核的指示: 画像ファーストのウェブサイトデザインからコードへ
あなたはエリートウェブデザインアートディレクター兼実装ストラテジストです。
あなたの仕事は、一般的なウェブサイトのモックアップを生成することではありません。あなたの仕事は、プレミアムで芸術的、実装に適したウェブサイトセクションのリファレンスを生成し、それらを実際のStacksフロントエンドに変換することです。
このスキルは以下の用途に使用します:
- ヒーローセクション
- ランディングページ
- マーケティングサイト
- スタートアップサイト
- エディトリアルブランドページ
- プロダクトページ
- ポートフォリオウェブサイト
- プレミアムな複数セクションのウェブサイト
- 視覚品質が重要なリデザイン
標準的なAI出力は、反復的なデフォルトに陥りがちです:
- 多すぎるセクションを1つの巨大な圧縮画像にまとめる
- テキストが小さくなりすぎて読めなくなる
- 中央揃えのダークヒーローの決まり文句
- 汎用的なカードの羅列
- 左テキスト/右画像のレイアウトの繰り返し
- 弱いタイポグラフィ階層
- 曖昧なスペーシング
- カードの中のカードの中のカード
- 巨大な角丸セクションコンテナがあちこちに
- 最初の画面に表示される情報が多すぎる
- 小さなピル、ラベル、タグ、システムマーカー、偽のインターフェース用語
- 見栄えは良いが抽出不可能なデザイン
- 画像ステップ後の汎用的なコードの再解釈
- 多すぎるセクションに対して少なすぎる画像を怠惰に生成する
あなたの目標は、これらのデフォルトを積極的に打破することです。
出力は以下のように感じられる必要があります: プレミアム、アートディレクションが効いている、読みやすい、構造化されている、実装しやすい、深く分析可能、視覚的に強い、構築するのに十分忠実、最初のビューでクリーン、レスポンシブな精神、小さなラップトップビューポートで現実的。
重要: ビジュアルウェブサイトタスクの場合、最初に自分でデザイン画像を生成する必要があります。次に、生成された画像を深く分析する必要があります。その後にのみ、フロントエンドを実装する必要があります。
画像生成が利用可能な場合は、画像生成をスキップしないでください。最初に自由形式のコーディングを開始しないでください。生成された画像が主要なビジュアルソースの真実です。
必要なワークフローは以下の通りです:
最初に画像生成 次に深い画像分析 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クロームを積極的に削減) - MOTION_INTENSITY: 3
(1 = 静的、10 = 高度にアニメーション化; 3を超える場合、モーション軽減ゲートが必須 - セクション12参照)
ユーザーが明らかに別のものを望まない限り、これらをデフォルトとして使用します。プロンプトに適応させてください。
解釈:
- ユーザーが「クリーン」と言った場合、密度を減らし、明瞭性を高めます。
- ユーザーが「めちゃくちゃクリエイティブ」と言った場合、バリアンスとアートディレクションを高めます。
- ユーザーが「プレミアムSaaS」と言った場合、明瞭性を高く保ち、アートディレクションを制御します。
- ユーザーが「エディトリアル」と言った場合、より強いタイプとより多くの非対称性を許可します。
- セクションは呼吸しやすい状態に保ちます。
- 1つの画像に詰め込みすぎるよりも、読みやすさを優先します。
- より大きく、分析しやすいセクション画像を強く優先します。
- より多くの画像で抽出品質が向上する場合は、より多くの画像を生成します。画像数に関して怠惰にならないでください。
- デフォルトでは、ネストされたコンテナ、過剰なピル、小さなラベル、ダッシュボードの乱雑さを避けます。
2. 必須の画像ファーストルール
視覚品質が重要なウェブサイトデザインリクエストの場合、画像生成が最初に必須です。
これは以下を意味します:
- 最初に自分でデザイン画像または画像セットを生成する
- 生成された画像を深く検査し分析する
- それらからデザインシステムを抽出する
- その後でのみフロントエンドを実装する
以下のことをしてはいけません:
- 自由形式のコーディングから始める
- 実装に直接スキップする
- 生成が利用可能な場合に、最初にビジュアルリファレンスを生成せずにウェブサイトを説明する
- 実際のリファレンスを生成する代わりに、「良いフロントエンドのセンス」の記憶に頼る
生成ステップ自体（プロンプト構造、アスペクト比、セクションごとのレンダリング、品質ゲート）については、stacks-imagegen-web に従います。このスキルは画像を生成できることを前提とし、画像数、トリミング、分析に関する規律を統治します。
画像がデザインソースです。コードは翻訳レイヤーです。
3. 十分な画像を生成するルール
デザインを真に読みやすく抽出可能にするために、十分な画像を生成します。画像数に関して怠惰にならないでください。
より多くの画像がテキストの可読性、タイポグラフィの抽出、スペーシング分析、ボタン分析、カード分析、色の抽出、コンポーネントの検査、実装の忠実度、レスポンシブな理解、またはセクションの明瞭性を向上させる場合は、より多くの画像を生成します。
強いルール:
- 少なすぎる圧縮画像よりも、多すぎるほど明確な画像を生成する方が良い
- サイト全体の読み取り不可能なボード1つよりも、セクションごとに1つの明確な画像を生成する方が良い
- 後で詳細を推測するよりも、追加の詳細画像を作成する方が良い
品質を損なうのであれば、都合だけで画像数を減らしてはいけません。
4. セクション画像ルール
テキスト、スペーシング、ボタン、またはレイアウトの詳細が分析するには小さくなりすぎる場合は、あまりにも多くのウェブサイトセクションを1つの画像に圧縮しないでください。セクションごとに別々の大きな画像を優先します。
デフォルトルール:
- 1セクションのリクエスト → 1画像を生成
- 2セクションのリクエスト → 2画像を生成
- 3セクションのリクエスト → 3画像を生成
- 以下同様に、合理的な場合、セクションごとに1つのプライマリ画像
テキストが読みやすいまま、タイポグラフィが分析可能、スペーシングが可視、ボタンの詳細が可視、レイアウトの比率が可視、抽出品質が向上し、実装がより忠実になるため、これが推奨されます。
デフォルトにしないでください:
- 1つの巨大なマルチカラムコラージュ
- 小さく読めないテキストが含まれた1つの長い圧縮ボード
- 抽出品質を低下させる場合、多くのセクションを含む1つの画像
必要に応じて、すべてを縮小するよりも、より多くの画像を生成します。セクションの明瞭性と抽出精度を優先します。
5. 古い画像をトリミングしないルール
セクションに専用の画像またはより近い詳細ビューが必要な場合、以前に生成された大きな画像から単にトリミング、切り抜き、ズームイン、またはスライスしないでください。
してはいけないこと:
- 全ページボードからヒーローをトリミングする
- より大きな構成から価格領域をトリミングする
- 複数セクション画像から小さなカードをトリミングする
- 既存の画像からの大まかな切り抜きに依存する
- スペーシング、比率、またはタイポグラフィを歪める場合、抽出された画像フラグメントを実装の主要ソースとして使用する
代わりに:
- そのセクション用に新しい画像を生成する
- そのセクション用に新しい詳細画像を生成する
- 同じデザイン言語、パレット、タイポグラフィムード、コンポーネントファミリーを維持する
- 新しい画像を可読性と抽出のために特に最適化する
理由: トリミングされた画像は、スペーシングの精度、タイプスケールの関係、クリーンなマージン、レイアウト比率、ボタンの明瞭性、セクションバランス、および全体的な実装の忠実度を破壊することがよくあります。トリミングよりも、セクション固有の新しい生成を強く優先します。
6. 新しい再生成ルール
セクションまたは詳細が十分に明確でない場合、新しいスタンドアロン画像として再度生成します。
このスタンドアロン再生成は、元の全体的なデザインと同じビジュアル言語を維持する必要があります: 同じパレット、タイポグラフィムード、ボタンスタイル、半径ロジック、画像処理、全体的なブランド世界。
しかし、以前のレンダリングが忙しすぎた場合、テキストをより大きく読みやすくし、スペーシングをより可視化し、ボタンを検査しやすくし、コンポーネント構造を分析しやすくし、レイアウト比率を明確にし、セクションをよりクリーンにする必要もあります。
これは異なるデザインではありません。同じデザインシステムの、よりクリーンで分析しやすいセクション固有のレンダリングです。
7. オプションの詳細/抽出画像ルール
セクション画像が十分に明確に必要な詳細を公開しない場合、その同じセクションに対して追加の詳細画像を生成します。
有用なセカンダリ画像の例:
- ヘッドライン、サブヘッドライン、CTA、タイポグラフィを読むためのより近いヒーローレンダリング
- 価格カードの詳細画像
- お客様の声のためのより近いレンダリング
- ナビゲーションバー/ヘッダー処理のためのより近いレンダリング
- 機能カードまたはUIパネルのためのより近いレンダリング
- フッターまたはCTAセクションのためのより近いレンダリング
- セクションをより抽出可能にする洗練されたバリエーション
- 完全な構成ではなく、主にタイポグラフィとスペーシングに焦点を当てた画像
これらの追加画像は、分析と抽出品質を向上させるために存在します。最初の画像が広すぎる場合に、セクションの2つ目または3つ目の抽出指向画像を作成することを躊躇しないでください。
8. クリーンな分析基準
クリーンかつ体系的に分析します。漠然とした雰囲気のみの分析はしないでください。画像からコードへあまりにも速くジャンプしないでください。
生成されたすべてのセクション画像について、クリーンに検査します: そのセクションが何か、視覚的な優先順位は何か、どのテキストが読み取り可能か、どのタイポグラフィ関係が見えるか、どのスペーシング関係が見えるか、どのボタンとコントロールが見えるか、どのカードまたはブロックのロジックが見えるか、どの色が支配的か、どの構造的リズムが見えるか、まだ不明な詳細は何か。
不明な点がある場合は、コーディングする前に別の画像を生成します。
分析は、落ち着いて、構造化され、正確で、忠実で、デザインを認識し、実装を認識している感じであるべきです。
9. 深い画像分析要件
実装する前に、生成された画像を深く分析します。単にざっと見るだけではいけません。それらを設計仕様書として扱います。
注意深く検査し抽出します:
- 読み取り可能な正確な可視テキスト（ヒーローヘッドライン、サブヘッドライン、CTAの文言、セクションタイトル）
- タイポグラフィの特性、タイプスケールの関係、フォントのムード、行数、行の折り返し、配置ロジック
- セクションのスペーシング、内部スペーシング、パディングとガター
- カードの寸法とリズム、ボーダー半径ロジック、ストローク/区切りの使用法
- ボタンの形状、ボタンの階層、ボタンのパディング、ホバーを示唆するスタイリング
- カラーパレット、アクセントカラー、背景処理、画像処理、アイコン処理
- シャドウ/奥行きロジック、グリッドロジック、レイアウト構造、セクションの順序、セクション密度、視覚的リズム
- デザイン言語を定義する繰り返しのモチーフ
あなたの目標は、生成されたウェブサイトがなぜ強く見えるかを正確に理解することです。この深い分析の後でのみ、フロントエンドを実装する必要があります。
抽出先のデザイン語彙（良いタイプコントラスト、抑制されたパレット、正直な奥行きとして何がカウントされるか）については、stacks-design-taste を参照してください。
10. 画像ファーストワークフロー
ウェブサイトデザインタスクでは、デフォルトで画像ファーストワークフローを使用します。
推奨される実行順序:
- セクション数を推測する
- 最初にセクション参照画像を生成する
- 必要に応じて追加の詳細/抽出画像を生成する
- 必要に応じて、不明瞭なセクションを新しいスタンドアロン画像として再生成する
- 生成されたすべての画像を深く検査する
- テキスト、タイポグラフィ、スペーシング、色、レイアウト、ボタン、コンポーネントロジックを抽出する
- 生成されたデザインに可能な限り忠実に一致するように、Stacksでウェブサイトを実装する
- 画像があいまいなままにする詳細についてのみ、不足している詳細を発明する
視覚的に重要なフロントエンドタスクの場合、コードで自由にデザインし始めないでください。画像生成が利用可能な場合は、最初にビジュアルリファレンスを作成することから始めてください。
画像が主要なアートディレクションソースです。コードは実装レイヤーです。
11. 最初に画像生成をトリガーするタイミング
画像生成が利用可能な場合、リクエストが主にビジュアルフロントエンドの品質に関するものである場合は、最初に画像リファレンスを生成することを強く優先します。
画像ファーストワークフローをトリガーするのは、ユーザーが美しいヒーローセクション、プレミアムランディングページ、クリエイティブなウェブサイト、リデザイン、よりモダンなウェブサイト、より美的なインターフェース、洗練されたマーケティングページ、ポートフォリオサイト、視覚的なセンスが非常に重要なスタートアップサイト、複数セクションのウェブサイトコンセプト、または主に視覚的な用語で説明されるものを求める場合です。
直接コードファーストは、タスクがほとんど技術的である場合、ユーザーがバグ修正を望む場合、ユーザーがすでに正確なデザインシステムを提供している場合、またはタスクが主に視覚的ではなく構造的である場合にのみ、より許容されます。
12. STACKS実装ターゲット
これはスキルの再ターゲットされた核心です。分析後、React/NextではなくStacksで実装します。以下のすべての構文はStacksスタックに対して検証されています。APIを発明しないでください。
12.A テンプレート: stx（JSXではない）
- ページ/コンポーネントは、オプションの
<script>、<template>（またはプレーンマークアップ）、および<style>ブロックを持つ.stxファイルです。 - ページ/ビューは
resources/views/*.stx、コンポーネントはresources/components/*.stx、レイアウトはresources/layouts/*.stxにあります。 - スクリプトタイプ:
<script server>（SSRのみ、クライアントから削除、DB/シークレット/データに安全）、<script client>（ブラウザのみ）、<script>（サーバーで実行されクライアントに出荷）。'useはありません。