akenoowww/art-direct-imagegen-plugin

Art-Direct ImageGen（アートディレクション型画像生成）

imagegen にレンダリングを依頼する前に、まず視覚的なアイデアを形にしましょう。問題を正確に定義しつつ、解決策の余地は広く保ちます。

基本原則は 「ラジカルシェル、コンサバティブセマンティクス（Radical Shell, Conservative Semantics）」 です。

• 固定するもの（LOCK）: コンテンツ、機能、ユーザーのジョブ、必須状態、重要なテキスト
• 方向性を示すもの（GUIDE）: 雰囲気、緊張感、情報階層、一つの概念的テーゼ
• 自由に委ねるもの（FREE）: 構図、ビジュアルシステム、幾何学、パレットのニュアンス、タイポグラフィの個性、補助的な詳細（コンセプトがこれらに真に依存している場合を除く）

創造性の要求を、より長いレンダリング仕様書に変えてはいけません。

ワークフロー全体を通じて、以下の2つのアーティファクトは常に分離しておいてください。

• グローバルコントラクト（global contract）：提供された全コンテンツ、機能、アクション、状態、デリバラブルセット全体にわたる正確なコピーの完全なインベントリ。
• カレントアウトプットブリーフ（current-output brief）：今生成している1つのアセットまたは状態にのみ表示されるべきもの。

グローバルコントラクトを imagegen のプロンプトにペーストしてはいけません。

関連リファレンスを読み込む

• 独創性や美的判断、評価が求められるリクエストの場合は、references/concept-planning.md を読んでください。
• UI、情報密度の高い画面、複数画面、モーダル、ドロワー、タブ、関連する状態を扱う場合は、references/flow-architecture.md も読んでください。
• imagegen のプロンプトを作成する直前に、references/prompt-compilation.md を読んでください。
• 生成結果を評価したり、反復の方法を決める前に、references/evaluation.md を読んでください。

ワークフローを選択する

以下の場合は、フルアートディレクションワークフローを使用してください。

• ユーザーが解釈、独創性、概念的な再設計、美的センス、記憶に残るデザイン、新しいビジュアルディレクション、または複数の関連するアウトプットを求める場合。

以下の場合は、システムの imagegen スキルを直接使用してください。

• ユーザーがすでに望む結果を確定しており、単に実行だけが必要な場合（例：1つのオブジェクトを変更する、名前を指定した編集以外はすべて保持する、背景を抜き出す、厳密に仕様化されたアセットをレンダリングするなど）。

ユーザーが画像を提供した場合は、計画の前にその役割をラベル付けしてください。

• 機能/コンテンツリファレンス（functional/content reference）: ジョブ、情報、アクション、状態を保持するが、レイアウトやスタイルは保持しない。
• スタイルリファレンス（style reference）: 名前の付いた視覚的特性を借用するが、コンテンツや構成は借用しない。
• 編集ターゲット（edit target）: 明示的に許可された変更以外はすべて保持する。
• ビジュアルシステムアンカー（visual-system anchor）: 確立された言語を後続のアウトプット全体で一貫して維持する。

機能リファレンスを暗黙のうちに編集ターゲットとして扱ってはいけません。

ワークフロー

1. グローバルコントラクトを抽出する

リクエストを次の4つのレイヤーに分割します。

• LOCK: 正確な機能、コンテンツ、ユーザータスク、プラットフォーム、必要なアクション、状態、ブランドの事実、リテラルなテキスト。
• GUIDE: 望ましい雰囲気、情報階層、視覚的緊張感、製品のポジショニング、記憶に残るべき品質。
• FREE: 構成、グループ化、空間的リズム、パレットのニュアンス、タイポグラフィの個性、マテリアル言語、背景、カスタムシンボル、補助的な詳細。
• FORBID: 架空の機能やコピー、誤解を招くアフォーダンス、既知のクリシェ、無関係な装飾、ユーザーによる明示的な禁止事項。

ソースのレイアウト、現在のカード境界、コンポーネント形状、ページ境界を、ユーザーが明示的に要求しない限り LOCK に昇格させてはいけません。

ソースの視覚的な階層ではなく、意味的な重要性とワークフローの意味を保持してください。アクション、トリガー、開かれるサーフェス、システム状態は別途記録してください。アクションやトリガーのラベルだけから、サポートされていない状態、確認、開かれたサーフェスを推測してはいけません。

情報密度の高いインターフェースでは、アイデアを練る前に、意味のあるすべてのコンテンツブロックと状態をインベントリ化してください。完全な情報セットは、すべてのアウトプットにわたって存続する必要がありますが、すべてのアウトプットに、または最初の画面に必ずしも含まれる必要はありません。

2. 当然の答を遮断する

視覚的な方向性を選択する前に、最も近い予測可能なメディア固有の完成形を個人的に特定し、隔離します：ストック的な構成、流行りのサーフェス処理、一般的な象徴性、おなじみのレイアウトアーキタイプ、変更されていない構造に貼り付けられたスタイルラベル。

禁止リストをコンセプトの代用品として使用してはいけません。コンセプトは作品を組織するものを説明します。禁止事項は失敗モードを取り除くだけです。

3. メカニズムによって発散させる

創作的なリクエストに対して、意味的に異なる少なくとも3つのコンセプト候補を開発します。これらは、論理の組織化方法において異なる必要があり、単にパレット、書体、装飾が異なるだけではいけません。

各候補について、以下だけを定義します。

1. 一文のテーゼ
2. 意図する雰囲気
3. 主要な構造的または構図的なジェスチャー
4. 必要な機能/コンテンツがその中にどのように存在するか
5. なぜそれが転用可能なテンプレートではないのか
6. その最も強いユーザビリティまたは一貫性のリスク
7. レンダラーに意図的に委ねるもの

比較がユーザーに利益をもたらさない限り、内部リスト全体を公開してはいけません。目標は選択圧力であり、ポートフォリオではありません。

4. 弁証法的に選択する

各真剣な候補に対して、短いテーゼ/アンチテーゼ/ジンテーゼのパスを適用します。

• テーゼ: なぜそのコンセプトが記憶に残り、この特定のタスクに適合するのか。
• アンチテーゼ: それがどのように装飾的、混乱を招く、派生的、または実装不可能になる可能性があるか。
• ジンテーゼ: 弱点をコンセプトを殺さずに取り除くことができるか。

まず、コンテンツ、機能、可読性、発見可能性、実装可能性を失う候補を却下します。残ったものの中から、最も明確な視点と最も強い転用耐性を持つ方向性を選択します。すべての候補を平均化したり、スタイルスープにマージしたりしてはいけません。

5. 出力セットを計画する

単一の独立したアセットの場合は、コンセプトシートに進みます。

情報密度の高いUIまたは接続された状態の場合：

1. 情報をプライマリ、セカンダリ、コンテキスチュアルに分類します。
2. インタラクションの意味に基づいて、スクロール、タブ、ドロワー、モーダル、または別画面を選択します。
3. ソースの各アイテムを宛先にマッピングします。
4. 最小限の出力マニフェストを定義します。
5. すべての隠れたサーフェスが、以前の状態に発見可能なトリガーを持っていることを確認します。
6. 必要な各画面または状態を、個別の imagegen 呼び出しで生成します。
7. 最初に承認された出力を、後続の出力のためのビジュアルシステムアンカーとして使用します。

ユーザーが明示的に比較ボードを望まない限り、複数の最終画面を1つのコラージュとして要求してはいけません。references/flow-architecture.md を参照してください。

ソースの可視性を意味的な優先順位として扱ってはいけません。完全なフォーム、詳細な来歴や履歴、長い補助コンテンツは、ソースがそれらを中央のタスクの隣に表示したという理由だけでプライマリになるわけではありません。Output 1 では、すぐに必要か、同時に比較される情報のみを保持します。

プロンプトコンパイルの前に、すべてのインベントリアイテムを現在の出力に対して NOW、ELSEWHERE、UNSUPPORTED のいずれかにマークします。どのアイテムにも宛先がない状態で続行してはいけません。

UNSUPPORTED は、存在しないコンテンツ、データ、結果、または動作に対してのみ使用します。新しい表示専用のタブ、ドロワー、モーダル、拡張可能領域、スクロールの継続は、提供されたコンテンツを再配置するだけであり、新しいデータや結果を作成せず、発見可能なエントリーポイントがある場合、それは架空の製品機能ではなく情報アーキテクチャです。密度が必要な場合は、その状態を個別に導入してレンダリングします。

1つのビューポート、長文のプライマリコピー、完全なコンテキストフォームや詳細、読みやすいタイポグラフィ、そして広々としたネガティブスペースを組み合わせる場合は、生成前に出力計画を却下します。代わりに出力セットを分割します。デフォルト、閉じている、または開かれていないと説明されている状態は、その閉じたサーフェスの内部コンテンツを同時に表示してはいけません。

長いプライマリコンテンツが完全な独立フォームと詳細な補助領域と競合する場合は、複数の出力を要求します。元のキャンバスが大きい、または技術的に読み取れるからといって、これを放棄してはいけません。

6. 1つのコンセプトシートに蒸留する

レンダラープロンプトを作成する前に、以下だけを確定します。

• 1文のコンセプトテーゼ
• 意図する雰囲気と視覚的緊張感
• 1つのシグネチャームーブと、最大2つのサポートムーブ
• LOCK リスト
• 短い FORBID リスト
• 今レンダリングする出力/状態

シートに正確な座標、完全なコンポーネントツリー、多数の色値、すべての角の半径、またはすべてのセカンダリ要素の指示が含まれている場合、それはおそらくアートディレクションではなくレイアウト仕様です。コンセプトを伝えたり機能を保護したりしない詳細は削除します。

シグネチャームーブは計画に残します。レンダラー向けに1段階上に翻訳します：正確な方向、位置、数、形状、トポロジーではなく、組織化関係、知覚的結果、緊張感を記述します（ユーザーがその幾何学を明示的に固定した場合を除く）。

7. アセットごとにプロンプトをコンパイルする

個別のアセットまたは状態ごとに1つのプロンプトを準備します。ソースの役割、現在の出力目標、非幾何学的なコンセプト意図、現在の出力のロック、創造的な自由度、そして重要ないくつかの回避すべき項目のみを含めます。

発見のための完全な推論、カバレッジマップ、却下されたコンセプト、グローバルロックリストをプロンプトにペーストしてはいけません。すべての手がかりを文字通りにレンダリングするようレンダラーに要求してはいけません。この出力で必要な重要な短いテキストのみをプロンプトに入れます。長めのコピーは、ソースリファレンス、カバレッジマップ、または実装レイヤーに保持します。読みにくい密度を強制する代わりに、出力全体に分散させます。

以下の場合、プロンプトコンパイルを失敗とし、出力計画に戻ります。

• プロンプトが複数の状態を記述している、または ELSEWHERE コンテンツを含む場合。
• プロンプトが現在の出力サブセットを指定する代わりに、すべての提供アイテムを1つの出力に保持するよう指示している場合。
• プロンプトが分散されるべきだったラベルやコンテンツ領域の長いカタログを運んでいる場合。
• 構成やトポロジーがすでに固定された後に創造的な自由度が宣言されている場合。
• 1ビューポートのリクエストが、すべての長いコピー、完全なフォーム、そして広々とした可読性を同時に要求している場合。
• 回避リストが汎用的なアンチスタイルカタログになっている場合。
• アセットがシッパブルまたはプロダクションレディと呼ばれている場合（高忠実度のビジュアルディレクションではない）。

references/prompt-compilation.md のレシピを使用してください。

8. システムの画像ワークフローを呼び出す

ツールの選択、入力画像の処理、保存パス、透明度、配信については、インストールされているシステムの imagegen スキルに従ってください。デフォルトではビルトインの画像生成ツールを使用します。

複数の異なるアウトプットの場合は、アセットまたは状態ごとに1回の呼び出しを発行します。最初のアウトプットを承認した後、それを後続のアウトプットのビジュアルシステムリファレンスとして提供し、重要な不変条件を繰り返します。

9. 実際の画像を批評する

プロンプトの優雅さではなく、出力を判断します。references/evaluation.md を適用します。

2種類の反復を使用します。

• 局所的な失敗（Local failure）: 1つの対象を絞った変更を行い、不変条件を再述し、承認されたコンセプトを維持します。
• 構造的または一般的な失敗（Structural or generic failure）: コンセプトの分岐または出力アーキテクチャに戻ります。失敗したコンセプトに、さらに形容詞、禁止事項、座標、スタイルリファレンス、名前付き領域、トポロジーを追加してはいけません。

構造的な再試行全体で、単調な創造的自由を維持します：新しいレンダラープロンプトは、失敗したプロンプトよりも多くのレイアウト、幾何学、方向、数、レイヤリング、配置を規定してはいけません。代わりに意味的なコンセプトを変更します。同じコンセプトが2回転用可能または一般的な結果をもたらした場合、それを破棄し、別の発散メカニズムから別の候補を選択します。

読み取れないコンセプトを、ワイヤーフレームを書き出すことで救おうとしてはいけません。正確な平面、ゾーン、露出部分、コネクタ、空間的な順序が規定された後でのみコンセプトが見えるようになる場合、そのコンセプトはこのワークフローに適していません。精度が許されるのは、ビジュアルシステムがすでに創造的なゲートを通過した後の局所的な編集の場合のみです。

出力が機能的に真実であり、概念的で読み取れ、一貫性があり、特徴的であり、意図された目的に使用可能である場合に停止します。システムの画像ワークフローで要求されるように、選択されたコンセプト、生成された出力、最終的なプロンプトセットを報告します。

譲れないガードレール

• 詳細さと創造性を混同してはいけません。
• 最初のもっともらしいコンセプトを対抗なしに勝たせてはいけません。
• パレットの入れ替えやスタイルラベルの入れ替えを独立したコンセプトと呼んではいけません。
• インタラクティブな出力では、画面をきれいに見せるためだけにプライマリ情報を隠してはいけません。
• 構成を埋めるために、コンテンツ、メトリクス、状態、コントロールを発明してはいけません。
• すべての要素を異常にしてはいけません。独創性を1つの決定的なシステムレベルのムーブに集中させます。
• 情報密度の高いインタラクティブな出力では、ソースが1ページを使用したという理由だけで、すべての情報を1つのビューポートに押し込めてはいけません。
• デフォルトまたは開かれていない状態で、閉じたサーフェスの内容を表示してはいけません。
• レンダラープロンプトに完全なグローバルコンテンツインベントリを搭載してはいけません。
• すべての可視のソースブロックを、同時タスク依存性を証明せずにプライマリとして分類してはいけません。
• 表示専用の再配置を発明された機能と呼んではいけません。
• 完全な構成を規定した後で創造的自由を主張してはいけません。
• 構造的な再試行を、失敗したプロンプトよりも幾何学的に特異にしてはいけません。
• 2回の一般的な構造的失敗の後も同じコンセプトを保持してはいけません。
• 生成されたUI画像は、構築およびテストされるまで、実装の証拠ではなくビジュアルディレクションとして扱います。
• テキストを含むビットマップ出力では、完全な長文テキストを約束してはいけません。コンテンツを分割し、重要なラベルを検証し、忠実度が重要な場合は実装アーティファクトに正確なコピーを保持します。