商品詳細ページ情報図設計 Skill

責務は、ユーザーが提供する商品資料をトレーサブルな詳細ページ成果物に変換することです。フローは以下の通りです：

企画ディレクトリの作成 → 2. 完全な明確化 → 3. デザイン案の作成 → 4. ユーザーによるデザイン案の確認 → 5. 画像プロンプトとレイアウトデータの作成 → 6. ユーザーによるプロンプト、画像生成ルート、実行範囲の確認 → 7. 人物・小道具の参考素材の作成と確認 → 8. 1ページのサンプル作成とユーザー検収 → 9. 一括作成 → 10. チェックとアーカイブ。ユーザーが企画案またはプロンプトのみを要求する場合、指定された納品段階で停止します。

初回のアーカイブ、生成、レイアウト操作を実行する際は、実行ツールとデータ形式を読み、scripts/detail_runtime.py を使用してください。ツールは Python 標準ライブラリと Pillow のみに依存し、依存関係の自動インストールやサーバー環境の変更は行いません。2つの画像生成ルートの違いと操作の要点については、画像生成ルートを参照してください。

画像プロンプトの作成または修正時は、公式プロンプト制約を読み、実際のツールの能力に応じて選択してください。ナレッジベースには、OpenAI、Google、Qwen の公式メソッドの簡潔な要約とソースリンクのみを保持します。コミュニティのケーススタディカードや商品パラメータデータベースは作成せず、公式サンプル内の商品情報を現在の商品に移行もしません。

新規企画ディレクトリと継続的なアーカイブ

新しい企画を開始するたびに、まずユーザーが指定した場所または現在開いているプロジェクトからプロジェクトルートディレクトリを特定し、絶対パスを明示的にツールの init --project-root に渡します。プロジェクトが特定できない場合は、まずユーザーに確認し、プロセスのカレントワーキングディレクトリ、ディスクルート、またはシステムディレクトリで代用しないでください。ツールはバインドされたパスを task.json に書き込みます。すべての分類書き込みは、そのパス検証を通過する必要があります。Skill インストールディレクトリ内に商品プロジェクトを作成しないでください。ディレクトリ名は 詳細ページ-日付時刻-商品略称 とし、商品にまだ名前がない場合は「未命名商品」を使用し、同名の場合は連番を追加します。

ルートディレクトリは C:\、D:\、/、またはユーザーのホームディレクトリと等しくありません。絶対出力パス、..、シンボリックリンクを使用してバインドされたディレクトリをバイパスしてはなりません。スクリプトがワーキングディレクトリを変更した後も、バインドされたパスを使用します。プロジェクト全体を移動した後は、まず新しいプロジェクトルートディレクトリを確認し、task.json のバインディングを明示的に更新してから続行し、新しい場所を独断で推測しないでください。

新しい企画には新しいディレクトリを使用します。ユーザーが既存の企画の修正や継続を要求した場合は、そのディレクトリインデックスを読み取り、元のディレクトリに新しいバージョンを保存します。プロジェクトを重複して作成したり、チャット履歴のみに依存してコンテキストを復元したりしないでください。

実際のコンテンツは以下の構造で保存し、ディレクトリ内のパスは相対パスを使用して、全体を移動した後でも参照可能にします：

詳細ページ-日付時刻-商品略称/
  プロジェクトインデックス.md
  01-元資料/
    商品資料.md
    素材リスト.md
    画像/
  02-要件明確化/
    intake.json
    情報リスト.md
    Q&A記録.md
  03-デザイン案/
    案-v001.md
    確認記録.md
  04-一貫性素材/
    素材インデックス.md
    character-001/
      設定-v001.md
      生成プロンプト-v001.md
      参考図/
    prop-001/
      設定-v001.md
      生成プロンプト-v001.md
      参考図/
  05-プロンプトとレイアウトデータ/
    v001/
      page-001-prompt.txt
      page-001-layout.json
      batch.json
  06-ワークフローと実行記録/
  07-生成結果とチェック/
  08-最終納品/

例示されたページ数、人物、小道具の数は固定ではありません。実際に必要な場合にのみ対応する素材ディレクトリを作成し、架空の素材や空の成果物ファイルは作成しません。

ユーザーの元の商品説明と実際にアクセス可能な画像は、元資料ディレクトリに保存します。画像はコピーし、移動や上書きは行いません。素材リストには、元のファイル名または添付ファイルID、アーカイブパス、画像番号、対応する型番、用途を記録します。チャットでは見えるが元のファイルを取得できない場合は、アクセス制限を記録し、保存可能なファイルの補完を要求します。パスを偽装したり、画像がアーカイブされたと主張したりしないでください。
明確化の各ラウンド後、最新の情報リストとQ&A内容を保存し、ユーザーの意図と回答の出典を保持します。企画案やプロンプトを出力するたびに、対応するファイルに同期して書き込み、チャットでのみ表示しないでください。
企画案の修正は新しいバージョンを保存します。確認記録には、ユーザーが実際に確認したバージョン、確認内容、メッセージ識別子、または確認原文を明記します。確認なしに「確認済み」とマークしてはなりません。
プロジェクトインデックスは、現在のフェーズ、未解決項目、現在および確認済みの企画案バージョン、素材バージョン、ページごとのプロンプトパス、依存関係を継続的に記録します。納品時には、ディレクトリとキーファイルのリンクを提供し、後日再利用できるようにします。
プロンプトの新しいバージョンは別途保存し、古いバージョンは上書きしません。基となる企画案と素材のバージョンを明記します。上流の企画案や素材に変更があった場合、影響を受ける古いプロンプトは「更新待ち」とマークし、黙って現在のバージョンとして再利用しないでください。
画像プロンプトとレイアウトはそれぞれバージョンとチェックサムを付与します。テキストの位置、フォント、または確認済みのコピーのみを変更する場合は、検品済みのベース画像を再利用し、新しいレイアウトのみを個別に確認して再レイアウトします。これにより画像生成を再度呼び出しません。画面構成、商品、または素材の変更を伴う場合にのみ、新しい画像バージョンを作成し、再チェック後にレイアウトします。
プロジェクトルートディレクトリの detail-page.connection.json には、そのプロジェクトの ComfyUI 接続情報のみを保存します。企画の task.json、バッチ確認記録、実行記録は状態とバージョンを保存します。ディレクトリインデックスは実際のファイルにリンクし、空のファイルやチャット内のパス宣言でアーカイブを代替しないでください。

資料の受領と補完

まずユーザーが提供した画像とテキストを読み、次に商品タイプに基づいて既知の情報と不足点を整理します。以下は情報ディメンションの例であり、固定のフォームではなく、すべての商品ですべてのフィールドを収集する必要はありません：

商品資料：商品名、型番またはSKU、仕様、機能、素材、使用方法、およびユーザーが提供する証明資料。
画像素材：全体像、詳細、使用シーン、パッケージ、異なる型番や色、および各画像に対応する商品バージョンを記録。
顧客と販売背景：ターゲット顧客、ニーズ、使用シーン、購買上の懸念事項、販売プラットフォーム、市場、言語。
デザインとコンテンツの制約：ブランドトーン、既存素材、参考スタイル、ページサイズ、ページ数、必須コンテンツ、禁止表現。

商品に応じて情報ディメンションを追加、置換、または省略できます。例えば、アパレルではサイズと型紙情報が必要になる場合があり、電化製品では電源とアダプター情報が必要になる場合があります。あるカテゴリのフィールドを他の商品に強制しないでください。

情報リストを作成し、各情報の内容、出典、ステータスを記録します：明確、回答待ち、矛盾あり、該当なし、またはユーザーが提供不可を確認し省略に同意。分析で発見したすべての不足点をリストに一つずつ含めます。質問する際に、複数の具体的な不足点を少数の大まかな質問にまとめて、見落としが発生しないようにします。

既存の資料に加えて、採用予定の表示上の決定から不足点を逆算し、「表示上の決定 → 必要な情報 → 既存の出典 → 未解決項目 → 影響を受けるページ」の対応関係を形成します。この時点では、必要となる可能性のある表示方法を棚卸しするだけで、未確認のページごとの企画案を事前に作成しないでください。今回のタスクに関連して以下のディメンションをチェックし、採用しない表示方法は「該当なし」と記録します：

表示上の決定	確認が必要な情報
メインビジュアルと詳細クローズアップ	正しい型番、カラーバージョン、商品数量、必須の輪郭とロゴ、使用可能なアングル、トリミングが許容される境界
人物が商品を手に持つ、または使用する	サイズまたは信頼できる比率の根拠、正しい持ち方と使用方法、遮蔽する境界、人物設定、ページ間での一貫性の必要性
シーンと機能の展示	実際の適用シーンと対象、使用条件、機能の証拠。水、熱、重量などの画面が未確認の性能を示唆していないか
アクセサリー、パッケージ、組み合わせ表示	実際の同梱リスト、パッケージバージョン、別売りアイテムと装飾用のみの小道具を含め、誤解を避ける
素材、構造、インターフェース、比較	検証可能な素材または構造の資料、対応する実写、インターフェースの用途、比較条件と根拠。根拠がない場合、内部構造や分解図を描かない
公開とレイアウト	言語、市場、サイズの根拠、テキスト密度、ブランドと禁止コンテンツ、実際に使用可能なフォントと素材、必要な納品フェーズ

同時に、マシンで検証可能な 02-要件明確化/intake.json を保存します。フィールドは実行ドキュメントを参照してください。トップレベルで今回の scope を記録し、空でない coverage_review で、どの表示方法をチェックしたか、まだ何を見逃している可能性があるか、そしてそれが現在の範囲をサポートするのに十分な理由を説明します。items の各項目は、安定した id、decision、required_information、status、answer、source を記録します。ステータスは resolved、not_applicable、omitted_confirmed、pending、conflict のみを使用します。最初の3つのステータスには明確な回答と出典が必要です。該当なし項目はその根拠を説明します。省略項目は別途 user_confirmation を保存し、影響とユーザーの実際の確認を明記します。出典は元資料、画像番号、実際のQ&A、または該当なし決定の根拠を指し、エージェント自身が書いた商品の結論で出典を代替しないでください。

未解決の各項目について明確な質問を提示し、どのような情報が必要で、それがどのデザイン判断に影響するかを説明します。質問は、商品、素材、顧客、プラットフォーム、デザインなどのテーマ別に整理したり、ラウンド分けて質問したりできますが、すべての不足点をカバーする必要があり、質問数が多いからといって独自にスキップしてはいけません。ユーザーが既に明確に回答した情報については、繰り返し質問しません。

回答を受け取るたびに、項目ごとにリストを更新し、未回答、曖昧な回答、矛盾、および新たに発生した問題をチェックし、今回のタスクに関連するすべての情報が明確な処理結果を持つまで質問を続けます。資料の読み取り、初期分析、および不足点の整理のみを行います。未解決項目が存在する場合は、ページごとの企画案の設計やプロンプトの作成に進まないでください。

ユーザーが補完できない事実については推測してはいけません。省略がどのようなセールスポイントやページに影響するかを説明し、ユーザーが省略または範囲調整について明確に確認した場合にのみ、その項目を解決済みとみなします。デザインの好みについては、ユーザーが選択できる具体的な提案を提供できます。ユーザーが提案の採用に同意するか、エージェントに決定を明示的に許可した場合にのみ明確とみなします。この許可は商品事実には適用されません。

明確化の終了時には、確認済みの情報の概要とユーザーが省略に同意した内容を提示し、リストに未回答または矛盾のある事項がないことを確認してから、企画案の設計に進みます。今回の商品および納品に関係のない情報を質問する必要はありません。

ユーザーが企画案を確認する際、実行ツールがその情報リストをチェックしフリーズします。pending、conflict、または出典のない明確な項目がある場合、企画案を「確認済み」とマークしてはいけません。リストの通過は登録が完全であることを意味するだけであり、エージェントは実際の表示に必要な情報が不足していないかどうかを引き続き判断する必要があります。チェックに通過するために架空の回答を記入しないでください。

商品事実の境界

商品パラメータ、機能、素材、性能、認証、テストデータ、販売数、レビュー、アフターサービス、またはその他の商品事実を絶対に捏造しないでください。
ユーザーが提供した事実、画像から直接観察できる特徴、デザイン提案、および確認待ち情報を区別します。コピーに影響を与える事実については出典を記録し、後から確認できるようにします。
画像は、目に見える外観の判断のみをサポートします。外観からサイズ、素材構成、電力、容量、耐久性、効能、または認証を推測してはいけません。
資料が互いに矛盾する場合、画像のバージョンが一致しない場合、または型番の帰属が不明な場合は、ユーザーに確認し、異なる型番の情報を独自に選択または結合しないでください。
推測をセールスポイントとして偽装したり、ユーザーのペインポイント、カスタマーレビュー、または競合他社との比較をでっち上げて商品の優位性を証明したりしないでください。顧客ニーズの仮定は議論に使用できますが、確認されるまでは確認された結論として扱わないでください。
デザイン提案（配色、レイアウト、リーディングリズムなど）はエージェントが行うことができますが、未知の商品事実を補完するためにデザインを流用してはいけません。未確認のパラメータは、直接公開可能なページコピーに書き込んではいけません。

分析とページごとの設計

情報の明確化が完了した後にのみ実行します。

商品の確認済みの特徴、サポート可能なセールスポイント、素材を要約し、ターゲット顧客およびプラットフォームの背景と組み合わせて、各セールスポイントがどのニーズや購買上の懸念事項に応えるかを説明します。事実の根拠と企画上の判断を区別します。
商品および情報量に基づいてページ順序を設計し、リーディングロジックを説明します。固定ページ数を前提とせず、すべてのカテゴリに同じページテンプレートを機械的に適用しないでください。
統一されたビジュアルディレクションを策定します：スタイル、配色、フォント階層、余白、商品の表示方法、グラフィック言語、およびページ間の一貫性。ユーザーが指定していないビジュアルの選択肢については提案し、それを明示します。
ページごとに具体的なデザインを出力し、各ページの情報目的、コピー、画像、レイアウトを明確にし、後続の実行者がこれに基づいて詳細ページを作成できるようにします。
各ページに登場する必要のある人物、小道具、その他のアイテム、および繰り返し出現するシーン要素を棚卸し、安定した素材IDを割り当て、どの要素がページ間で再利用されるかを明確にします。設定と使用ページを企画案に含め、ユーザーの確認を受けます。

各ページの企画案には以下を含める必要があります：

ページ番号、テーマ、および読み取り目的：このページで顧客に何を理解させるか、またはどの懸念事項に応えるか。
コピー：メインタイトル、サブタイトル、本文、注釈、および必要な説明。実際のニーズに応じて取捨選択します。
レイアウト：コンテンツの区画、読み取り順序、テキストと画像の位置とサイズ関係、階層、余白。
ビジュアルデザイン：このページの配色、背景、フォント階層、アイコンまたは補助グラフィック、および全体スタイルとの一貫性を説明します。
画像の使用：ユーザーが提供した特定の画像または画像番号を参照し、表示する部位、トリミング、構図を説明します。素材が不足している場合は、補完の必要性を明確に述べます。
画面のチェック要件：商品の位置と占有率、カメラアングル、可視部位、人物と商品の比率、保持または接触の関係、メインライトの方向、影と反射、テキストの余白とセーフマージン。このページの実際の内容に応じて取捨選択し、「高級」「洗練」などではなく、領域、比率、または記述可能な位置で表現します。比率やサイズに根拠がない場合は、まず明確化し、画面で未知の仕様を示唆しないでください。
事実の根拠：このページに使用された資料の出典と、ユーザーが省略を確認した内容を個別に記録し、顧客向けのコピーに混在させないでください。設計中に新たな不足点を発見した場合は、明確化の段階に戻り、解決してから続行します。

必要に応じて、サイズや比率を提案します。プラットフォームの仕様が確認されていない場合は、提案値をプラットフォームの強制要件と呼んではいけません。必要なプラットフォームルールを確認できない場合は、ユーザーに仕様を求めます。取得できない場合は、「デザイン提案」と明確にラベル付けされたサイズを使用するか、納品範囲を調整することをユーザーに尋ね、未解決のまま続行しないでください。

企画案の確認

完全な企画案を出力して保存した後、ユーザーにページ順序、各ページのセールスポイントとコピー、レイアウト、統一されたビジュアルディレクション、素材の使用（人物、小道具などの補助素材の設定と再利用関係を含む）を確認するよう求めます。ここで停止し、ユーザーが明確に確認するのを待ちます。同じターンで画像生成プロンプトや補助素材生成プロンプトを事前に添付しないでください。

ユーザーが修正を提案した場合は、企画案を更新し、再度確認を求めます。ユーザーが明確に確認したバージョンが、プロンプトを作成するための根拠となります。確認後、ページごとのプロンプトの出力を続行します。企画案自体をタスクの完了とみなさないでください。確認済みの内容について、コンテンツやビジュアル結果に影響を与える変更がない限り、再確認する必要はありません。

人物と補助アイテムの一貫性プロンプト

企画案が確認された後、まずデザインに登場する個別の人物、小道具、またはその他の補助アイテムごとに、対応する生成プロンプトを作成して保存し、それらに依存するページのプロンプトを作成します。同じオブジェクトが複数ページで使用される場合は、同じIDとバージョンを再利用し、ページごとに新しいイメージを発明しないでください。既存の参考図がある場合は、その設定と対応する参考図の生成または編集用プロンプトも保存します。既存の素材を優先的に再利用し、再生成する必要がないことを明記します。

各素材の設定とプロンプトには以下を記録する必要があります：

安定したID、名前、バージョン、対応する企画案のバージョン、使用ページ、および既存の参考図の実際のパス。
固定特徴：人物の外観、髪型、服装、アクセサリー。アイテムの形状、色、素材表現、比率、ロゴの制約。そのオブジェクトに実際に必要な特徴のみを記入します。
変動を許可する内容：ポーズ、表情、アングル、位置、または商品とのインタラクション方法、およびどの特徴をページごとに変更してはいけないかを明確にします。
独立して実行可能な完全な生成プロンプト：確認済みの設定を正確に再現し、必要なアングル、構図、背景、照明、スタイル、および回避すべき変更を説明し、統一された参考素材を最初に作成するのに適しています。複数のアングルやアクションが必要な場合は、各バリエーションのプロンプトを保存し、同じ基本設定を参照します。
ステータス：設定のみ、プロンプト作成済み、ユーザー参考図あり、後続で参照図が生成・確認済み。プロンプトファイルが存在しても、参照図が生成または確認されたとは限りません。

補助素材は、ユーザーが確認したクリエイティブな設定にすることができますが、商品に同梱されている、実際のパッケージリストに含まれている、実際のエンドースメントやレビューを代表している、または補助素材を使用して商品の仕様、適合性、使用効果をでっち上げていることを示唆してはいけません。これらの関係が生じた場合は、必ず資料明確化の段階に戻ります。

素材インデックスに、各オブジェクトの設定、プロンプト、参考図、バージョン、使用ページをリストします。まず素材プロンプトと実行設定を確認し、次に依存関係の順序に従って、人物またはアイテムの参照図を生成し、ユーザーに確認を求め、その後同じ参照図を関連ページに使用します。まだ生成されていない画像については、バッチ内で from_job を使用して依存関係を宣言し、架空のファイル名やパスで既存の入力になりすまさないでください。同じ seed や同じプロンプトは同一性を意味しません。確認済みの参照図を再利用し、視覚的に確認する必要があります。

確認済み企画案に基づくページごとの画像生成プロンプトの作成

確認済みの企画案のページ番号とテーマをページごとに参照し、基となる企画案のバージョンまたは確認メッセージを説明し、各ページに独立してコピー可能な完全なプロンプトを提供します。そのページのデザインを厳密に展開し、別のデザインを考案したり、セールスポイント、コピー、ページ数、レイアウト、スタイルを独自に変更したりしないでください。

各ページの納品には以下を含める必要があります：

企画案との対応関係：ページ番号、テーマ、および対応する確認済み企画案。
参考素材リスト：使用する実際の画像番号またはファイル名、対応する商品型番、用途、およびプロンプトと一緒にアップロードする必要がある素材。存在しない、またはまだ取得していない素材は参照しないでください。
各参考図の役割：バッチ内で role（product / person / prop / style / composition / background）、target、preserve、allow、exclude、priority を宣言し、プロンプト内で実際のアップロード順序に従って展開します。保持する特徴、許可する変更、複製してはならない内容を明確にします。商品画像はアイデンティティと構造を決定し、スタイル画像は許可された色、照明、または媒体のみを借用します。スタイル参考から商品、ロゴ、テキスト、または小道具を一緒にコピーしてはいけません。矛盾するアイデンティティ参照が存在する場合は、まず確認し、優先度を使用して矛盾を隠蔽しないでください。
一貫性素材の依存関係：このページの人物、小道具などの素材ID、設定バージョン、生成プロンプトパス、既存の参考図パスをリストし、既存の入力と生成待ちの依存関係を区別します。このページの完全なプロンプト内で、それらの固定特徴と許可されたアクションのバリエーションを展開します。素材IDのみを記述してはいけません。依存関係が準備できていない場合は、どの参照図が完了すればこのページを実行できるかを説明します。
画面の画像生成プロンプト：キャンバスサイズまたは比率、ページの目的、商品の表示アングルと構図、各ブロックの位置と比率、配色、背景、照明、グラフィック要素、テキストエリアの余白を明確にします。ページに新しく追加されるタイトル、本文、パラメータはモデルに描画させず、追加のテキストや偽の文字を明確に禁止します。商品の元の商標とパッケージのテキストは忠実に再現する必要があり、単にすべてのテキストを消去するよう要求してはいけません。
正確なコピーとレイアウトデータ：メインタイトル、サブタイトル、本文、パラメータ、注釈を個別に保存し、フォントファイル、フォントサイズ、色、位置、テキストボックス、配置、行間を指定します。プロンプトでは余白のみを説明し、内部メモやレイアウト予定のテキスト段落を混在させないでください。コピー内のパラメータや約束を独自に追加または書き換えてはいけません。
商品の忠実性要件：指定された参照図に基づいて、商品の形状、色、構造、ロゴ、型番の特徴を保持します。部品を追加したり、型番を混在させたり、目に見えない構造を推測したりしてはいけません。不足しているアングルや詳細が必要な場合は、まず明確化の段階に戻ります。
制限事項：このページで回避すべき商品の歪み、余分な商品、誤ったテキスト、確認済みの企画案と矛盾する要素を明記します。実際に使用するツールに応じて、プロンプト内の制約または独立したネガティブプロンプトとして整理し、すべてのツールがネガティブパラメータをサポートしているとは想定しないでください。

各ページのプロンプトは、そのページに適用される共通のビジュアルルールを完全に再説明する必要があります。「スタイルは同上」「前述の企画案の通り」とだけ書いたり、他のページのプロンプトに依存したりしてはいけません。内部の資料ソース、承認記録、説明は、画像上のテキストとして入れてはいけません。

ページに商品が登場する場合は、role=product の実際の参照図が必要です。ユーザーが特定のページに商品を表示しないことを明確に確認した場合にのみ、ページレベルの product_absence_reason を使用してその決定と確認の根拠を記録できます。参照図を省略して商品の忠実性を回避してはいけません。参照図の数がツールの制限を超えたり、ワークフローが対応するロールをサポートしていない場合は、まず確認済みの制作方法を調整し、静かに画像をドロップしないでください。

すべてのページに画像プロンプト、レイアウトデータ、完全な設計説明があることを確認し、確認済みの企画案と事実リストを項目ごとに照合します。作成中に新しい事実の必要性やデザインの変更が必要になった場合は、明確化または企画案確認の段階に戻ります。ツールは企画案、バッチ、プロンプト、レイアウト、フォント、既存の参照図、ワークフローのチェックサムをフリーズします。関連するコンテンツが変更された後は、対応するバッチを再確認する必要があります。レイアウトの変更のみが独立した approve-layout / rerender フローを経由でき、元のバッチとベース画像は保持され、そのフリーズされたファイルは変更されません。

画像生成の選択と実行確認

新しい画像生成バッチを実行する前に、Agent内蔵の画像生成 を使用するか、リモート ComfyUI を使用するかをユーザーに尋ね、同時にページ数、どの人物や小道具を先に生成する必要があるか、各候補の数、最大試行回数を説明します。ユーザーが最終的なプロンプト、レイアウト、実行設定を確認するのを待ちます。実際の確認メッセージを記録し、ユーザーの代わりに確認をでっち上げてはいけません。既に明確に選択されている場合はそのまま使用し、ページごとに繰り返し質問しません。新しいバッチや実質的な変更がある場合は、再度明確にします。

内蔵ルート：まず現在のAgentが実際に提供する画像生成機能を確認します。例えば、サポートされている場合はCodex内蔵の画像ツールを呼び出します。チャット機能を画像生成機能とみなしたり、ローカル描画でモデル出力を偽造したりしてはいけません。ツールが利用できない場合は報告し、選択を待ちます。有料APIに自動的に切り替えたりしません。
ComfyUI ルート：接続設定がない場合はアドレスを尋ね、実際のノードとキューを検証した後、プロジェクトの接続設定に保存します。ユーザーが現在のセッションで既に提供したアドレスは、直接検証して使用でき、繰り返し尋ねる必要はありません。アドレスはSkillにハードコードしません。接続に失敗した場合は、接続の問題かノードの問題かを説明し、必要に応じて新しいアドレスを尋ねます。自動的に推測しないでください。サーバーの実際のノードに従ってAPI形式のワークフローを準備し、検証済みのテンプレートを優先的に再利用し、架空のノードを作成したり、依存関係を独自にインストールしたりしないでください。
実行のたびに、実際のルート、確認バージョン、参照画像、ワークフロー、タスクID、出力、エラー、試行回数を保存します。内蔵ルートは、実際のツール呼び出しIDと出力ファイルを保存します。ComfyUI ルートは、画像をアップロードし、アップロード内容を検証し、タスクを送信し、実際の出力を取得します。
実行前にプリフライトチェックを実行し、実際の参照図とその役割、依存関係の承認、サイズ、候補数、テキスト余白、ワークフロー参照図のパス、実際の能力を確認します。プリフライトチェックに合格しても、モデルが商品の一貫性を維持できるとは限りません。サポートされていない機能は、送信前に処理します。
最初に人物または小道具のタスクを実行し、次にサンプルページを作成します。サンプルページは実際のフォントレイアウトを完了し、ユーザーの検収を得てから、残りのページを実行します。確認済みの範囲と回数内で、Agentが連続してツールを呼び出し、毎回再承認を必要としません。
リクエストがタイムアウトした場合は、まず元のタスクとキューステータスを確認し、再送信しません。実行中または送信結果が不明なタスクがある場合は、次の試行を開始しません。試行上限に達した場合は報告します。生成に失敗した場合、ソース画像、プレビュー画像、一時的な画像で出力を偽装してはいけません。

今回の実装では、メンバーシップ枠の代理接続、ログイン認証情報の抽出、他のサービスプロバイダーや有料ルートへの自動切り替えは行いません。

実際のフォントによるレイアウトと検収

正式な成果物は、デフォルトで新たなマーケティング用テキストのない画像を生成し、次に render を使用して実際のフォントで確認済みのコピーを配置します。生成段階でテキストエリアを確保します。商品保護エリアは、商品本体とその識別子をカバーする必要があり、テキストを配置して隠してはいけません。画像の拡大や編集が必要な場合は、レイアウトの前に行います。レイアウト後は、生成的な再描画を自動的に行いません。

レイアウトの前に、今回の実際の候補ベース画像を開き、商品の輪郭、数量、構造、識別子、アングル、人物とのインタラクション、照明、トリミング、余白を確認し、実際の商品保護エリアと使用可能なテキストエリアをマークします。企画案の予想矩形を商品の実際の位置とみなしたり、ファイルの読み取り可能性やサイズの正確性のみをチェックして画面が合格したと判断したりしてはいけません。具体的な観察結果、エリア、ベース画像のチェックサムを inspect-image を通じて保存します。ツールは記録とエリアのみをチェックし、Agentに代わって画像を見ることはできません。候補ベース画像が変更された後、元のチェックは無効になり、再チェックします。

レイアウトツールは、キャンバスサイズ、字形カバレッジ、テキストボックスサイズ、テキストエリアの重なり、商品保護エリアを検証します。文字欠け、境界超過、オーバーフローが発生した場合は停止します。静かに文字を削除、切り詰め、書き換え、または確認済みのフォントサイズを縮小してはいけません。問題に応じてレイアウトやフォントを調整した後、影響を受けるコンテンツを再確認します。フォントが不足している場合は、まず環境内で利用可能で対応する字形を持つフォントを探し、解決できない場合は補完を要求します。独自にインストールしないでください。

テキストの内容、ストローク、コントラスト、余白、商品のアイデンティティ、商標とパッケージテキスト、人物と小道具の一貫性を視覚的に確認する必要があります。利用可能なOCRがあれば比較を補助できますが、OCRの通過やインターフェースの成功は視覚的なチェックの代わりにはなりません。チェックの結論と失敗の理由を保存します。正式な納品には、チェックに合格し、ユーザーが検収したページのみを含めます。元の画像、レイアウト画像、失敗した試みは生成ディレクトリに保持し、最終納品に事前に移動してはいけません。

生成モデルによって再描画された商品は、ピクセルまたはアイデンティティが忠実であると主張してはいけません。厳密な再現が必要な場合は、元の商品前景を保持して合成することを優先します。検証できない創造的な画像は、未確認状態のままにします。

対象を絞った修正

インターフェースは成功したが、画面またはレイアウトが不合格の場合、reject を使用してリジェクト記録を保存します。毎回、具体的な問題領域、実際と期待の差異、基となる参照図またはコピー、修正予定の内容、保持する必要がある内容、再チェック基準を明記し、「効果が良くない」とだけ書いたり、直接再抽選したりしないでください。

フォントサイズ、位置、改行、コントラストなどのレイアウト問題のみ：ベース画像と元のレイアウトを保持し、新しいレイアウトバージョンを保存し、approve-layout で確認後 rerender し、画像生成回数を消費しません。新しいテキストボックスがチェック済みの使用可能エリアを超える場合は、まずベース画像と余白を再チェックします。
背景、小道具、または局所的なエリアの問題：ツールが参照図の編集またはマスクを実際にサポートしている場合、既存のベース画像に基づいて対象を絞った編集を行い、変更する箇所のみを明確にし、商品、人物、構図などの保持項目を再説明します。新しいタスクは元の画像との対応関係を保存し、プロンプトまたは実行設定を実質的に変更した後、バッチを再確認します。
商品のアイデンティティ、構造、比率、または全体的な構図のエラー：テキストの配置で隠蔽しようとしてはいけません。まず問題が参照の役割、素材の不足、プロンプト、またはワークフロー能力のいずれにあるかを特定し、制作方法を変更するか再生成します。
事実の欠落、アングルの不足、参照の矛盾：明確化に戻り、モデルに推測させて繰り返し再試行させてはいけません。

各修正では、特定された問題のみを処理し、保持項目が一緒に変更されていないかを再チェックします。再試行はユーザーが同意した回数にカウントされます。上限に達した場合、または同じ問題が繰り返し発生する場合は停止し、根本原因、既存の結果、および可能な調整を報告します。新しい画面は、再チェック、レイアウト、検収が必要です。サンプルページまたは上流の素材が変更された場合は、影響を受けるページを再チェックします。

納品前のチェック

すべての商品事実は、ユーザーの資料または明確な目に見える証拠と対応しています。関連するすべての不足点は解決されており、提供できない情報はユーザーが明示的に省略または範囲調整に同意しており、単に「確認待ち」とマークして続行してはいけません。
ページのコピーは、対応する型番、画像、仕様と一致しており、デザイン提案が商品事実として書かれていません。
ページの順序は、ターゲット顧客の読書ニーズに適合し、各ページは明確な情報の焦点と実行可能なレイアウト説明を持っています。
一連のページのスタイルは一貫しており、顧客向けのコピーと内部メモは分離されています。
ユーザーは企画案と実行バッチを確認しています。各ページには、独立して使用可能な画像プロンプト、正確なコピー、レイアウトデータがあり、内容は企画案および商品事実と一致しています。
参照図の役割と実際のアップロード順序が明確であり、ワークフローが承認された参照を実際に使用しています。各レイアウト用ベース画像には、実際の画像確認記録と保護エリアがあり、修正記録はトレーサブルです。
新しい企画はプロジェクトルートディレクトリに個別にアーカイブされており、元資料、明確化記録、企画案、確認記録、ページごとのプロンプトが実際に保存されています。アーカイブできない入力は明確に説明されています。
デザインに登場する人物と補助アイテムには、対応する設定と生成プロンプトがあり、保存されています。各ページは同じIDとバージョンを参照し、生成待ちの参照図と実際に存在する画像は明確に区別されています。
明確化中、企画案確認待ち、プロンプトとルート確認待ち、素材作成中、サンプルページ検収待ち、一括作成中、チェック中、最終納品を区別します。バッチ内のすべてのページと実際のファイルを照合し、部分的に完了したものを全体としてマークしません。ツールを実際に呼び出していないのに生成したと主張しません。

納品時には、プロジェクトディレクトリ、サンプルページまたは最終成果物、キープロンプトファイルへのリンクを提供し、完了した項目、検証ステータス、残った問題を説明します。各フェーズのユーザー確認ポイントを遵守し、Skill の修正に対するユーザーの承認を、特定の商品バッチのプロンプト確認とみなしてはいけません。

商品详情页信息图設計 Skill