detail-flow

DetailFlow

概要

このスキルを使うと、製品や機能のアイデアを、実用的で洗練された詳細ページに仕上げられます。製品のわかりやすい説明、実際のユーザーワークフロー、実装品質、レスポンシブな動作、そして単なる装飾ではなく製品の魅力を伝えるビジュアル素材を優先してください。このスキルは汎用的に使えるように設計されています。さまざまな画像生成ツール、フロントエンドスタック、ローカルのパイプラインに対応できますが、中心となる役割は、製品詳細ページの計画、生成、レビュー、改善です。

実行契約

画像を中心としたEC商品詳細ページの依頼では、定められたDetailFlowの手順を厳守してください。この契約は、利便性、独自の判断、ツールの優先度よりも優先されます。

• 必ず次の順序で進めてください：入力を分析する -> ページの設計図を作成する -> 最初のユーザー承認を待つ -> テキストとビジュアルのマスターを確定する -> 使用する場合は1:3画像マスターを生成し、内部で検査する -> 最初の最終スライス2枚を生成する -> 2枚を連結したプレビューを作成し、内部で検査する -> 1:3マスター、最初のスライス2枚、プレビュー、監査結果をまとめて提示する -> 2回目のユーザー承認を待つ -> 残りのスライスを生成する -> 最終監査を行う -> 出力フォルダーを保存し、報告する。
• 標準ワークフローでは、通常のユーザー承認ゲートを必ず2回だけ設けてください：承認1では、ページの設計図全体を確認します。承認2では、1:3マスター、最初のスライス2枚、それらを連結したプレビューを含むビジュアルサンプル一式を確認します。マスターと最初のスライス2枚の間に、別の確認を追加しないでください。安全な続行を妨げる重大な失敗が発生した場合、またはユーザーがワークフローの変更を求めた場合に限り、追加の確認が必要です。
• 2つの承認ゲートでは、必ず作業を停止してください。無応答、別の段階での承認、または一般的な「続けて」という依頼を、未確認の設計図やビジュアルサンプル一式への承認と解釈しないでください。
• 生成したすべてのマスターと段階的な出力を、続行する前に必ず検査してください。予定しているコピーがないのに画像にテキストがない場合、無関係な単独ポスターのように見える場合、参照スタイルを無視している場合、商品が変更されている場合、テキストが文字化けしている場合、または根拠のない主張が作られている場合は、続行しないでください。
• ユーザーの商品画像、参照画像、確認済みの事実、承認済みの設計図、承認済みのマスターを、必ず信頼できる入力として使用してください。それらを新たに考案したコンセプトや汎用的なカテゴリー用テンプレートに置き換えないでください。
• 作業範囲は、依頼されたEC画像セットに限定してください。ユーザーが明示的に求めない限り、Webサイト、動画、アニメーション、プレゼンテーション、アプリケーション、ワークフローノード、Pythonスクリプト、自動化スクリプト、その他の補助成果物を作成しないでください。
• 画像生成を模擬するためだけのコード、プレースホルダー成果物、利用できない画像生成・編集機能の迂回手段を作成しないでください。必要な機能が利用できない場合、または失敗した場合は、その制約を伝え、現在の段階で停止するか、関連する最小限の代替案を提示してください。
• 依頼された成果物の範囲を必ず維持してください。承認を得ずに、無関係な段階、出力形式、画像枚数、補助成果物を追加しないでください。ユーザーから提供された商品情報が限られている場合は、商品画像、商品カテゴリー、参照画像、一般的な購入者の懸念事項に基づいて、適切な訴求コピー、シーン案、ビジュアルモチーフ、ラベル、補足コンテンツを推定してください。合理的な創作上の推定と確認済みの事実を明確に区別してください。ユーザーまたはソース資料による裏付けがない正確な技術仕様、認証、受賞歴、医療効果、割引、ブランド提携を作り出さないでください。
• 失敗した結果を受けて、制作手順を黙って変更しないでください。修正ルーティングルールに記載された、問題のある最小限のレイヤーのみを修正し、その変更が承認済みの設計図またはマスターに影響する場合は、確認を求めてください。
• 承認済みの出力を必ず保持してください。試行中に承認済みのマスターやスライスを上書きしたり、破棄したりしないでください。修正版は、明確に区別できる代替版またはバージョンとして保存してください。
• 画像サイズの読み取り、承認済みスライスの連結、ファイルの確認、成果物の保存など、確定的な操作に必要な場合に限り、既存の軽量なユーティリティを使用してもかまいません。ユーザーが自動化を明示的に求めない限り、これらの操作のために新しいユーティリティスクリプトを作成しないでください。

ユーザーの依頼が曖昧な場合は、現在のDetailFlow段階を進めるうえで最も範囲の狭い対応を選んでください。作業範囲を広げる前に確認してください。

コアワークフロー

画像をもとにEC商品詳細ページを依頼された場合、すぐに最終画像を生成しないでください。まず、構成を整理したページの設計案を作成し、ユーザーに確認または修正を依頼します。ユーザーが計画を省略するよう明示的に求めた場合を除き、画像を生成するのはユーザーがコンテンツ案を承認した後です。

1. 商品の概要を明確にする

   商品名、対象ユーザー、主な価値、具体的な機能、制約、裏付けとなる情報、期待する行動喚起を確認します。ユーザーが商品画像や参考画像を提供した場合は、ページのセクションを書く前に、画像から読み取れる素材、形状、スタイル、カテゴリ、購入者が懸念しそうな点、差別化要因を推測します。既存のページが提供された場合は、変更案を提案する前に現在の構成を確認します。

2. ページ構成を設計する

   最初の画面での商品の紹介、実用的な価値、機能のセクション、使用例やユースケース、信頼性の根拠、関連する場合は制限や要件、明確な次のアクションからなる、流し読みしやすいストーリーを構成します。EC向けの長いページでは、各画面に主な目的を一つずつ持たせて、意図的にストーリーを分割します。ただし、画面ごとに情報量に変化をつけてください。すべての画面にキャンペーン風の見出しとサブタイトルが必要なわけではありません。小さなガイド文、説明の段落、ラベル、バッジ、補足、成分や詳細に関する注記、比較、シーンのキャプションなどを使う画面も設けます。どんな商品にも当てはまるような、ありきたりなマーケティング文言は避けてください。

   画像を主体とするEC向けの長いページでは、最初の画面で商品の主張の核となる要素を2～4点提示します。後続の画面では、関連性のない新たな訴求点を持ち出すのではなく、これらの要素を掘り下げ、裏付け、視覚化、または具体化します。後続の画面の文言が最初の画面の要素と結びつかない場合は、最初の画面で提示する要素か、後続の画面の目的のいずれかを見直します。

3. 既存プロジェクトに合わせる

   編集前に、リポジトリの構造、フレームワーク、ルーティング、コンポーネントの規約、デザイントークン、アセットの扱い方、ローカルのスタイルパターンを確認します。適合する場合は既存のコンポーネントやユーティリティを再利用します。

4. 商品が伝わるデザインにする

   最初の画面で商品そのものが伝わるようにします。適切な場合は、スクリーンショット、生成ビジュアル、商品モックアップ、デモ、またはその分野に関連する画像を使います。業務用ツールは情報量を保ちながら、落ち着いた見た目で流し読みしやすくします。より表現豊かなビジュアルを使うのは、商品カテゴリに適している場合に限ります。

5. ページを実装する

   編集するファイルは、合理的に必要な最小限にとどめます。コンテンツ、レイアウト、インタラクションの状態を十分に整え、ページが単なるプレースホルダーではなく、実際の商品画面として感じられるようにします。アクセシビリティ、レスポンシブ対応、視覚的な階層構造について、既存のフロントエンドのガイドラインに従います。

6. 実際の表示で検証する

   必要に応じてアプリを起動します。スクリーンショットまたはブラウザーでの確認を使い、デスクトップとモバイルのビューポートをチェックします。引き継ぐ前に、テキストのはみ出し、要素の重なり、メディアの空白、切り抜きやフレーミングの不自然さ、色使いの単調さ、状態の不足、レイアウトのずれを修正します。

画像生成ワークフロー

ユーザーが商品画像を提供し、EC商品詳細ページ、8画面のページ、縦長のセールス画像、またはスタイル参考画像をもとにした商品ページを依頼した場合は、このワークフローを使います。

1. 入力を分析する

   商品画像と参考スタイルを分けて説明します。画像から確認できる商品の事実、推測される訴求点、根拠なく作り出してはいけない不明点を列挙します。

   設計案を書く前に、確定済みの訴求点、仕様、機能、対象ユーザー、または避けるべき主張について、まだ提供されていない場合は、ユーザーに簡潔に確認する機会を一度設けます。必須の質問票にはしないでください。ユーザーが追加情報を提供しない場合は、商品画像から得られる根拠とカテゴリに基づく妥当な推測を用いて作業を続け、未確認の訴求点はAIによる推測であり、商用利用の前に確認が必要であることを明示します。 参照画像に印象的なキャラクター、モデル、マスコット、手、小道具、またはシーンの表現が含まれており、それがユーザーの求めるスタイルを支えている場合は、参照スタイルのDNAの一部として扱ってください。3Dのカートゥーンキャラクターの存在感、親しみやすいブランドの案内役、手持ち商品の紹介、ローアングルのライフスタイル写真、マクロの注釈スタイルなど、抽象的なレベルでそのビジュアル表現を保ちます。参照画像に含まれる元のブランド、特定の人物の本人性、テキスト、商品をコピーしてはいけません。

2. まずページの設計図を作成する

   画像を生成する前に、8画面分のページ設計図を出力します。設計図には、各画面について次のフィールドを含めてください：slice_id、buyer_question、module_type、module_label、claim_seed、screen_job、evidence_type、content_density、layout_archetype、copy_module_type、copy_structure_pattern、primary_module、secondary_modules、text_exact、hierarchy_strategy、composition_shift、top_edge_anchor、bottom_edge_anchor、visual_composition、reference_style_notes、risk_unknowns。画像を生成する前に、設計図の確認または修正をユーザーに依頼してください。

   まず、後続の画面を書く前に、画面01のclaim_seedを2〜4個定義します。目に見える素材や細部、質感への期待、使用シーン、信頼の手がかり、利便性、感情に訴える要素など、短いシードを2〜4個使います。後続の各画面では、どのシードを展開するのかを明示してください。ユーザーが新しい章を明示的に求めない限り、画面01でシードされていない訴求点を後続の画面に追加してはいけません。

   これらのフィールドは計画の管理項目として扱い、見出しとしてページ上に表示しないでください。module_type、detail、parameter_trust、FAQ、screen_jobなどの内部ラベルを、ページ上のコピーにそのまま使ってはいけません。自然な、購入者に向けた中国語のコピーに置き換えてください。

   すべての画面を同じ「見出し＋サブタイトル」の構成に無理に当てはめないでください。最も強い見出し・サブタイトルの扱いは、最初の画面や、実際にセクションの始まりとなる画面に限ります。後続の画面では、セクションの役割に応じて、説明文、小さなガイドタイトル、ラベルのまとまり、アイコン付きの注記、根拠を示すコールアウト、素材や細部への注釈、シーンのキャプション、比較行、信頼性を伝える箇条書き、締めくくりのCTAなど、適切なコピーの形式を選んでください。コピーの構成によって、レイアウトの変化と視覚的な階層を生み出してください。

   各画面には異なるcopy_structure_patternを割り当てるか、少なくとも隣り合う画面で同じパターンを繰り返さないようにします。例：hero_claim_stack、question_answer、single_line_with_labels、annotation_map、three_point_breakdown、scene_caption_cluster、mini_steps、trust_checklist、quiet_closing。パターンの違いによって、見出しと本文の構成を別の名前にするだけでなく、文のリズム、表示するテキストの項目、行数、レイアウトの動きにも変化をつけてください。

   承認を求める前に、コピーの差別化、シードの一貫性、コピー構成の多様性を確認してください。各画面は異なる購入者の疑問に答え、それぞれ固有のコピー上の役割を担いながら、最初の画面のシードにつながっている必要があります。画像なしで読んだときに隣り合う画面を入れ替えられるようなら、計画を書き直してください。後続の画面が、シードした訴求点を深掘りするのではなく、新たに独立した話題として感じられる場合も、計画を書き直してください。3つ以上の画面で「見出し＋説明文1文＋タグ3つ」のような同じ文のリズムを使っている場合は、copy_structure_patternを書き直してください。味、品質、利便性、感情に訴える要素を、わずかに言い換えながらすべての画面で繰り返さないでください。

   各画面にprimary_moduleを1つ、secondary_modulesを1〜3個組み合わせて、少なくとも画面の70％に2〜4個のコンテンツ要素を含めてください。ただし、ユーザーが意図的に情報量の少ないビジュアルを求めている場合は除きます。情報量の少ない画面では言葉を減らしてもかまいませんが、切り替え、シーンの雰囲気、信頼に関する注記、商品アイデンティティ、締めくくりの感情など、明確な役割を持たせる必要があります。

3. 最終スライスの生成前に、ロングスクロールのマスターと構成を確定する

   最終画面を生成する前に、ロングスクロールのマスターと構成を作成するか、内容を確認してください：

   • テキストマスター：visual_master_spec、master_reference_prompt、visual_style_dna。パレット、ライティング、空間、素材、タイポグラフィ、連続性を保つモチーフ、リファレンススタイルのDNA、製品のアイデンティティに関するルール、セクションのリズム、情報密度、ページ構成を固定するために使用します。
   • 画像マスター：ワークフローで対応している場合、または効果的な場合は、1:3 の連続した縦長ページのマスターリファレンスを使用します。縦長ページの空間的な連続性、つまり背景世界、床やテーブルの遠近感、光の方向、食材や粒子の流れ、繰り返し登場するビジュアルモチーフ、製品スケールのリズム、セクション間の移行、ページ全体で見えるコピーの階層を固定するために使用します。詳細ページをテストする場合は、承認済みの text_exact の階層を反映した簡略化された中国語の可視コピー、またはテキスト用に明確に確保されたモジュールを含めます。ユーザーが純粋な空間リファレンスを明示的に求めていない限り、テキストを完全に排したマスターは作成しないでください。
   • 構成ブループリント：module_type、claim_seed、screen_job、evidence_type、content_density、primary_module、secondary_modules、text_exact、hierarchy_strategy、composition_shift、エッジアンカーを含む、順序付けられた画面項目。最終プロンプトを作成する際の最優先の情報源として使用します。

   1:3 の画像マスターは最終成果物ではなく、切り抜き元でも、承認済みの 9:21 構成の代替でもありません。連続性と階層を参照するためのものです。ピクセル単位でそのまま複製したり、切り抜いて最終画像にしたり、すべてのスライスを厳密に同じ構図にしたりしないでください。1:3 マスターが連続した EC 詳細ページではなく独立したポスターのように見える場合、詳細ページのマスターとして期待されるテキスト階層を備えていない場合、または多くの領域で製品、キャラクター、主要モチーフのヒーロー構図が繰り返されている場合は、最終的な 9:21 スライスを生成する前にマスターを修正してください。

4. 最終ページのセクションを生成する

   最終画面は、縦にスクロールする詳細ページのスライスとして順番に生成します。ユーザーが別のプラットフォーム比率を明示的に求めていない限り、プロジェクトのデフォルトである縦型の 9:21 スライス比率を優先します。各スライスは承認済みのブループリントに厳密に従う必要があります。プロンプト作成中に module_type、screen_job、evidence_type、content_density、primary_module、secondary_modules、text_exact を変更しないでください。適切な場合、各スライスには 2～4 個のコンテンツ要素を含め、承認済みの構成から 1 つの主要モジュールと複数の補助モジュールを用います。すべてのスライスを、見出し 1 つとヒーロー画像だけのポスターに簡略化しないでください。

   1:3 の空間マスターがある場合、各 9:21 スライスのプロンプトでは、これを共有する空間的連続性のアンカーとして参照してください。現在のスライス独自の構成を展開しながら、背景世界、ライティングの方向、素材の雰囲気、製品スケールのリズム、繰り返し登場するモチーフ、食材や小道具の流れ、移行のルールを引き継ぎます。そのスライスは独立したポスターではなく、同じ縦スクロール型ページシステムの一領域を詳細に展開したものとして見えるよう、明示してください。

   段階的な生成チェックを実施します。最初の 2 枚のスライスを生成したら、小さなプレビューに連結して確認します。承認済みの 1:3 マスター、2 枚の個別スライス、2 スライスのプレビュー、簡潔な監査結果をまとめて、2 回目の確認パッケージとして提示します。ユーザーがこのパッケージを確認して承認してから、残りのスライスを生成してください。初期プレビューに内部的な問題がある場合は、パッケージを提示する前に 1:3 マスターまたは該当するスライスのプロンプトを修正します。承認済みのストーリー自体に問題の原因がある場合に限り、ブループリントに戻ってください。

5. 分割納品または長尺画像の連結を準備する ユーザーが画像を個別に求める場合は、同じロングスクロールシステムから連続するページスライスとして提供します。長い画像を求める場合は、スライスを順番に連結します。共通の背景、ライティング、製品のアイデンティティ、繰り返し登場するビジュアルモチーフ、タイポグラフィシステム、余白のリズム、トランジションに一貫性を持たせます。ユーザーからポスタースタイルの出力を明示的に求められない限り、各セクションを単独のソーシャルポスターにしないでください。一連の画像で製品のアイデンティティを統一し、目に見える製品の色、形状、ブランドマーク、特徴的な構成要素を変更しないでください。

   独立した画像を1枚ずつ生成する際に、テキストだけの「前のスライスから続ける」という指示に頼らないでください。前後のビジュアルコンテキストなしで生成されたスライスは、通常、独立した完結した構図にリセットされます。真の連続性を保つには、利用可能な場合はプロジェクトのロングスクロールパイプラインを使用します。構成の設計図を作成し、9:21のスライスプロンプトを作成して、端のアンカーを明示しながら順番にスライスを生成し、プレビューを連結してから、上下端がつながらないスライスを修正します。生成ツールが画像参照やアウトペインティングに対応している場合は、現在のスライスのビジュアルコンテキストとして、前のスライスの下端と次のスライスの計画を使用します。

6. 結果を監査する

   生成後、結果がひと続きのEC商品詳細ページとして読めるかを確認します。また、製品の外観が変化していないか、テキストが文字化けしていないか、レイアウトの階層が破綻していないか、裏付けのないパラメーター、認証、主張が含まれていないかを確認します。再生成を提案する前に、具体的な修正案を示します。

   連続性の監査では、連結したプレビューを2回のタイミングで確認する必要があります。最初の2枚のスライスを生成した後の早期プレビューと、全セットを生成した後の最終プレビューです。各スライスでポスターの構成が繰り返される、中央に配置されたヒーローシーンからやり直す、同じ主要ビジュアルモチーフが同じスケールで繰り返される、同一のタイトル／タグブロックが使われる、または上下端に目に見える引き継ぎがない場合は、結果を不合格とします。合格するスライスは、共通の空間ロジック、端のモチーフ、変化のある情報密度を備え、同じ長いページの隣り合う部分に見える必要があります。

   生成した1:3マスターは、次に進む前に画像を確認します。期待されるテキストモジュールまたはテキスト用の予約領域が含まれているか、独立した場面を積み重ねたものではなく長い1ページの商品詳細として読めるか、繰り返される主要モチーフが機械的に複製されず適切に制御されているか、計画した各セクションをマスターに対応付けられるかを確認します。これらの確認に失敗した場合は、9:21のスライスを作成する前に1:3マスターを再生成します。

   デフォルトでセット全体を再生成するのではなく、問題の原因となる最小のレイヤーに修正を適用します。

   • コピーまたは文言の問題：text_exactを修正し、影響を受けるスライスだけを再生成するか、そのテキスト領域を修復します。
   • 製品のアイデンティティ、向き、色、形状、ロゴ、または構成要素の問題：製品参照の制約を強化し、影響を受けるスライスだけを再生成します。
   • 単一画面の階層または煩雑さの問題：その画面のprimary_module、secondary_modules、content_density、copy_structure_pattern、またはhierarchy_strategyを修正します。
   • 隣接する画面間のトランジションの問題：影響を受ける2つの端アンカーを修正し、隣接する最小範囲のスライスを再生成します。
   • 複数の画面にわたるビジュアル文法の繰り返し：該当する画面のcomposition_shiftを修正し、承認済みのナラティブと影響を受けない画面は維持します。
   • ページ全体のスタイルまたは空間的な連続性の問題：テキストマスターまたは1:3マスターを修正し、可能な場合は変更の影響を受けるスライスだけを再生成します。
   • ページ全体のナラティブまたは主張の種の問題：ページの設計図に戻ります。承認済みのストーリーが大幅に変わる場合に限り、全体を再生成します。

7. 画像セットを納品する 生成、修正、最終監査が完了したら、保存先の確認手順を別途追加せずに、承認済みの画像一式を保存します。ユーザーが保存先をすでに指定している場合は、その場所を使用します。指定されていない場合は、現在のワークスペース内に、outputs/product-detail-page/<product-name>-<timestamp>/ のような、内容が明確に分かる納品フォルダーを作成します。使用可能なワークスペースがない場合は、作業中のソースアセットと同じ場所、または現在の作業ディレクトリ内に納品フォルダーを作成します。生成した元ファイルはそのまま保持します。

   プレビュー画像だけでなく、一式すべてを納品します。これには、使用した場合の承認済み1:3マスター、明確な連番ファイル名を付けた最終的な個別スライスすべて、初期の2スライス結合プレビュー、フル解像度の最終ロング画像結合版、必要に応じた軽量版の結合プレビューが含まれます。ユーザーが全イテレーションを明示的に求めない限り、却下されたバリエーションや以前のバージョンは含めません。

   納品フォルダーに、依頼されたファイルがすべて存在することを確認します。最後に、ユーザーがフォルダーを開いて画像を確認できるよう、納品フォルダーのパスと簡潔な完了状況を報告します。生成が完了した後に、保存先を選ぶようユーザーに尋ねてはいけません。product_master_1x3.png、product_screen_01.png から product_screen_08.png、product_first3_preview.png、product_full_long.png のような、分かりやすいファイル名を使用します。

ページの原則

• 最初の画面で、これは何か、誰を対象としているか、そして今なぜ重要なのかが分かるようにします。
• 曖昧な形容詞より、具体的な機能を示す表現を優先します。
• 例、パラメーター、スクリーンショット、比較、ワークフローで信頼性を伝えます。
• カードの多重化、装飾的な図形、ありきたりなグラデーション、実際の製品が隠れてしまうヒーローセクションは避けます。
• 見出しのサイズはコンテナに合わせます。コンパクトなパネル内で、ヒーロー向けの大きな文字を使わないでください。
• タブ、ツールバー、メディアフレーム、グリッド、カウンター、機能タイルなど、形式が固定されたUIには安定した寸法を設定します。
• モバイルを最初から重要な表示環境として設計し、デスクトップ版を単に縮小したものにしないでください。

コンテンツのチェックリスト

• 製品名とカテゴリがすぐに分かるように表示されています。
• メインのCTAが、ユーザーの意図するビジネス上の目標またはワークフローの目標に合致しています。
• 機能は、検証または認識が可能なほど具体的に示されています。
• セクションは、社内向けの機能一覧ではなく、ユーザーの意思決定の流れに沿って配置されています。
• 技術的な主張には、必要に応じて制約、前提条件、使用状況が含まれています。
• 初めて訪れた人が製品を理解するのに十分な、具体的な例が含まれています。
• 画像を中心としたEコマースページでは、生成された仕様、認証、割引、受賞歴、測定パラメーターは、ユーザーから提供されたものか、差し替えが必要なプレースホルダーとして明示されています。

実装のチェックリスト

• 新しい抽象化を追加する前に、既存のコンポーネント、ルート、スタイルを確認します。
• 製品、出力、ワークフロー、または実際の題材が分かるアセットを使用します。
• 画像、動画、キャンバス、生成されたビジュアルが正しく表示されることを確認します。
• デスクトップとモバイルの少なくとも各1つのビューポートで、はみ出しや重なりがないか確認します。
• プロジェクトに利用可能なビルド、リンター、テストがあり、変更範囲に応じて必要な場合は実行します。
• ユーザーが開けるローカルURLまたはファイルパスを報告します。

参考資料

セクションのパターンを選ぶとき、スキルを特定の製品カテゴリに適用するとき、またはページ構成が完成しているか確認するときは、references/detail-page-patterns.md を読みます。