BruceL017/post-illustration-images

記事イラスト画像

コアルール

このワークフローを「コンテンツ分析 → テンプレート選択 → 画像生成」に単純化しないでください。安定性は中間層に依存します：

コンテンツ分析
→ コンテンツタイプと表現ニーズ
→ スイートレベル スタイル仕様
→ アンカー選択
→ ショットリスト
→ 画像ごとのコンテンツ構造
→ 画像ごとの視覚的メタファー
→ 選択された視覚スタイルの制約
→ Brand Plugin有効時のブランドスロット予約
→ モデル描画のブランドやページバッジなしの単一画像プロンプト
→ ネイティブCodex画像生成
→ 選択したスタイル仕様のスロットを使用したオプションのBrand Pluginオーバーレイ
→ QAとフォールバック
→ 保存されたアセットと納品ノート

視覚スタイルを選択する前に、必ずコンテンツを読んでください。画像セット全体に1つのスイートレベルスタイルを使用してください。各画像は、そのコンテンツ構造と視覚的メタファーによってのみ変化させます。

アーキテクチャ境界

スタイル仕様は、各プラットフォームの視覚テンプレートの権威です。キャンバスサイズ、アスペクト比、固定色値、レイアウト、セーフエリア、ネガティブ制約、およびブランドスロットなどの固定コンポーネントスロットを制御します。

Brand Pluginはオプションでプラグ可能です。ブランドが有効かどうか、どのブランドアセットを使用するかを決定するだけです。キャンバスサイズ、カラーパレット、座標、プラットフォームレイアウトを決定してはなりません。有効な場合、Brand Pluginは選択されたスタイル仕様のブランドスロットに従わなければなりません。選択したスタイルにブランドスロットがない場合、グローバルな配置を即興で作成しないでください。

画像モデルは、ロゴ、TF、Tranfu、透かし、ページ番号バッジ、またはその他の固定ブランドコンポーネントを描画してはなりません。これらは省略するか、生成後の決定論的オーバーレイステップで追加します。

サポート範囲

強力なサポート：

• WeChat公式アカウント本文イラスト
• Xiaohongshuノートイラスト（カバー/コンテンツカルーセル画像を含む）
• Zhihu投稿イラスト
• 方法、ワークフロー、コンセプト、比較、チェックリスト、境界、決定フローの説明

条件付きサポート：

• 実際の製品スクリーンショットや事実データを必要とする画像セット：素材を要求するか、前提を明記します。
• 明示的なスタイル名：対応するスタイルファイルが存在する場合はそれを使用します。
• 明示的な画像数：選択したスタイルのデフォルト数を上書きします。

範囲外：

• 純粋な写真、肖像画レタッチ、製品モックアップ、またはフォトリアリスティックなブランドキャンペーン
• 画像内に正確な長文テキストが必須のタスク。ネイティブ画像生成はテキストを歪める可能性があります。短いラベルを使用し、必要に応じてテキストを減らして再試行してください。
• ユーザーが明示的に要求しない限り、他の画像生成スキルを経由するリクエストは行わないでください。

必要なリファレンス

すべてを一度にではなく、必要に応じてリファレンスを使用します：

• references/style-index.mdから始めて、プラットフォームと候補スタイルファイルを特定します。
• プロンプトをコンパイルする前に、references/styles/の下の選択したファイルを完全に読みます。
• ユーザーがBrand Pluginを明示的に無効にしない限り、references/brand.mdを読みます。
• 画像ごとの表現構造を選択するときにreferences/content-structures.mdを読みます。
• 最終生成プロンプトを作成する前にreferences/prompt-compiler.mdを読みます。
• 納品または再生成の前にreferences/qa-checklist.mdを読みます。
• このスキルを維持または拡張する場合にのみreferences/product-design.mdを読みます。

ワークフロー

1. インテーク

プラットフォーム、ソースコンテンツ、要求された出力、明示的なスタイル、明示的な数、出力場所、およびBrand Pluginが無効かどうかを特定します。

プラットフォームが推測できない場合は、簡潔な質問を一つします。プラットフォームが明確でコンテンツが利用可能な場合は、確認を求めずに進みます。

以下の場合に終了します：

• プラットフォームが既知である
• ソースコンテンツが利用可能である
• 明示的な数/スタイル/ブランドのオーバーライドがキャプチャされた

2. コンテンツ分析

ソースコンテンツ全体を読みます。メインラインを3〜5文で要約し、次に表現ニーズを分類します：

• コンセプト説明
• ワークフロー/プロセス
• ビフォーアフター比較
• 階層的フレームワーク
• 一般的な間違いや境界
• 決定木
• チェックリストまたは要約
• ストーリー/状態遷移

コアとなる主張、オーディエンス価値、視覚化可能な部分が明確になったら終了します。

3. スイートレベルスタイル仕様の選択

references/style-index.mdを使用して、セット全体に1つのスタイルを選択します。

ルール：

• ユーザーが明示的に指定したスタイルが存在する場合はそれを優先します。
• それ以外の場合は、コンテンツタイプと表現ニーズに基づいて最適なプラットフォームスタイルを選択します。
• スタイルを選択する前に、画像数、アスペクト比、パレット、セーフエリア、または固定コンポーネントスロットを決定しないでください。これらは、ユーザーが明示的にオーバーライドしない限り、スタイルファイルまたはその機械可読なスタイル仕様から取得します。
• Zhihuの場合、将来スタイルファイルが代替を追加しない限り、固定のZhihuスタイルを使用します。

1つのスタイルファイルが選択され、完全に読み込まれたら終了します。

4. アンカーの選択

画像に値するコンテンツポイントのみを選択します。割り当てを埋めるために画像を作成しないでください。

良いアンカーの例：

• コア判断
• 認知的転換
• 入出力ループ
• ビフォーアフター対比
• 一般的な間違い
• プロセスのブレークポイント
• 役割/状態の変化
• メソッドレイヤー
• 信頼、変換、または引き継ぎ関係

選択した各アンカーが「なぜこれに画像が必要なのか？」に答えられる場合に終了します。

5. ショットリストの構築

ショットリストは必須です。各画像には以下を含める必要があります：

• 配置または順序
• トピック
• 1つのコア意味
• コンテンツ表現構造
• 視覚的メタファー
• メインアクター/オブジェクトのアクション
• 提案要素
• 短いラベル
• 選択したスタイル仕様からの固定コンポーネント予約（ある場合）
• QAリスク

各画像は正確に1つのコアアイデアを表現する必要があります。1つの画像に複数のアイデアが含まれる場合は、分割するか削除します。

6. プロンプトのコンパイル

各画像について、以下を組み合わせます：

• ユーザーコンテンツアンカー
• 選択したスイートレベルスタイルファイル
• 画像ごとのコンテンツ構造
• 画像ごとの視覚的メタファー
• スタイル仕様のセーフエリアと固定コンポーネント予約
• references/brand.mdからのBrand Pluginステータス
• ネイティブCodex生成制約
• スタイルとQAリファレンスからのネガティブ制約

画像ごとに1つのプロンプトを生成します。画像モデルに1回の呼び出しで複数画像セット全体を作成するよう依頼しないでください。

スタイルファイルに「セット全体を生成」などのバッチ言語が含まれている場合、それは数、順序、一貫性のための計画ガイダンスとして扱います。それでも1枚ずつコンパイルして生成します。

プロンプトは、モデル描画のロゴ、TF、Tranfu、透かし、ページ番号バッジを明示的に禁止する必要があります。Brand Pluginが有効な場合、選択したスタイル仕様のブランドスロットをクリアに保つようにモデルに依頼し、実際のブランドアセットを生成後にオーバーレイできるようにします。

7. 1枚ずつ画像を生成

ネイティブCodex画像生成のみを使用します。デフォルトで他の画像スキルを呼び出さないでください。

生成後：

• 画像をスキルフォルダではなく、現在のプロジェクトに保存します。
• 推奨出力パス：post-illustration-output/<content-slug>/
• Brand Pluginが有効な場合は、ネイティブ生成画像をimages/unbranded/に保存します。
• Brand Pluginが有効な場合は、オーバーレイ後の成果物をimages/branded/に保存します。
• Brand Pluginが無効な場合は、成果物をimages/に保存します。
• 順序付きファイル名を使用します。例：01-cover.png、02-process-breakpoint.png。

7.5 Brand Pluginオーバーレイの適用

Brand Pluginが有効で、選択したスタイル仕様がブランドスロットを定義している場合：

• references/brand.mdから実際のブランドアセットを使用します。
• 画像生成後にアセットをオーバーレイします。画像モデルにロゴを再描画するよう依頼しないでください。
• 選択したスタイル仕様のスロット、サイズ、セーフエアルールを使用します。
• ユーザーが明示的に交換を要求しない限り、ブランドなしの生成画像を保持します。
• Xiaohongshuジャーナルスタイルの場合、scripts/apply-brand-overlay.mjsをreferences/styles/xhs-style-journal.spec.jsonと共に使用します。
• オーバーレイスクリプトにnpm依存関係はありませんが、マシンでrsvg-convertが利用可能である必要があります。

8. QAとフォールバック

すべての画像をreferences/qa-checklist.mdに対してチェックします。

画像が不合格の場合、再試行する前に理由を特定します：

• テキストエラー：テキストを減らし、短いラベルのみを保持して再生成します。
• アイデアが多すぎる：アンカーを分割または削除します。
• スタイルの逸脱：選択したスタイルソースとネガティブ制約を強化します。
• メタファーが弱い：物理的なアクションとオブジェクトを書き直します。
• モデルがブランドを描画した：「no logo/no TF/no Tranfu」制約を強化して再生成し、Brand Pluginオーバーレイを適用します。
• ブランドオーバーレイがコンテンツをブロックする：スタイル仕様の予約ブランドスロットを使用します。コンテンツがそのスロットを占有する場合は、より明確な予約領域で再生成します。
• レイアウトが空すぎる、または混雑している：スタイル全体ではなく、構造を調整します。

9. 保存と納品

出力フォルダにmanifest.mdを作成または更新し、以下の情報を含めます：

• ファイル
• プラットフォーム
• スタイル
• Brand Plugin有効/無効
• スタイルQAステータス
• Brand Plugin QAステータス（有効な場合）
• 配置/順序
• コア意味
• 構造
• 視覚的メタファー
• QAステータス

最終応答には以下を含める必要があります：

• 出力パス
• 画像数
• 使用されたスタイル
• 各画像の使用法
• QAの結論と残存リスク

交渉不可事項

• スタイル選択前にコンテンツを分析する
• セット全体に1つのスイートレベル視覚スタイルを使用する
• ショットリストを決してスキップしない
• 各画像は1つのコア意味を表現する
• コンテンツ表現構造が情報を整理する
• 視覚的メタファーが抽象を具体的なシーンに変換する
• スイートレベルスタイル仕様がプラットフォームの外観、寸法、色、レイアウト、セーフエリア、固定コンポーネントスロットを制御する
• Brand Pluginは、選択したスタイル仕様がブランドスロットを定義する場合にのみデフォルトで有効になり、そのスロットに従わなければならず、グローバルな視覚システムとして動作してはならない
• 画像モデルはブランドロゴやページ番号バッジを描画してはならない
• 1枚ずつ画像を生成しQAする
• 生成アセットをスキルフォルダ外に保存する