Art

アートスキル

カスタマイズ

実行する前に、次の場所にユーザーによるカスタマイズがないか確認してください。 ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Art/

このディレクトリが存在する場合は、以下を読み込んで適用してください。

• PREFERENCES.md - 美的な好み、デフォルトモデル、出力先
• CharacterSpecs.md - キャラクターデザインの仕様
• SceneConstruction.md - シーン構成のガイドライン

これらはデフォルトの動作より優先されます。このディレクトリが存在しない場合は、スキルのデフォルト設定で進めてください。

🚨 必須：音声通知（何らかの操作を行う前に必須）

このスキルが呼び出されたら、ほかのことをする前に必ずこの通知を送信してください。

1. 音声通知を送信する：

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the Art skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. テキスト通知を出力する：

   Running the **WorkflowName** workflow in the **Art** skill to ACTION...
   

これは任意ではありません。このスキルが呼び出されたら、直ちにこの curl コマンドを実行してください。

機能

Flux、Nano Banana Pro（Gemini 3 Pro）、GPT-Image-2 を使用して、ブログヘッダー、技術図やアーキテクチャ図、フレームワーク、分類体系、タイムライン、比較図、統計カード、コミック、アイコン、壁紙、D3 チャート、Mermaid 図など、20 種類以上の形式で静的なビジュアルコンテンツを生成します。すべてのリクエストは、手法と配色を定めた名前付きワークフローを通じて処理されます。出力はレビュー用にまず $LIFEOS_DOWNLOADS_DIR（未設定の場合のデフォルトは ~/Downloads/）に保存され、ブログヘッダーには、透明なインライン版と不透明なソーシャルサムネイルの両方が用意されます。

課題

画像モデルに自由形式のプロンプトを与えるだけでは、出力に一貫性がなく、スタイルも意図に沿わなくなります。構成ルールを定めたワークフローをプロンプトに含めなかったため、あるセッションでは不採用の図が 12 点も生成されました。形式ごとに適したモデル（テキスト量の多いカードには GPT-Image-2、エディトリアルヘッダーには Nano Banana Pro）、サイズ形式、透明度の扱いが異なります。明確なルーティングとステージングの手順がなければ、サイズ違いの画像や、ページの背景に溶け込む不透明なヘッダーができたり、誰も確認していない画像がそのままリポジトリに追加されたりします。このスキルは、ワークフロー、モデルの選択、まず Downloads に保存してレビューする手順を、Markdown 上の指示だけでなくコードで必須にします。

仕組み

イラスト、図、その他の静的なビジュアルを扱うための、完全なビジュアルコンテンツシステムです。各リクエストでは、まず適合するワークフローファイルを選び、そのプロンプトテンプレートに従ってから、Generate.ts を --workflow=<name> とモデル、サイズ、出力先の各フラグとともに呼び出します。Generate.ts はワークフローに従ったことを自身で検証し、出力を必ずプレビュー用に $LIFEOS_DOWNLOADS_DIR（未設定の場合のデフォルトは ~/Downloads/）に保存します。また、ブログヘッダーでは --thumbnail を指定し、透明な PNG とセピア調の背景を付けたソーシャルサムネイルの両方を生成します。

🛑 構造上の強制 — --workflow=<name> は必須です

以前はこのルールが Markdown のみに記載されていたため、無視されることがありました。その結果、あるセッションでは不採用の図が 12 点生成されました（インシデント：2026-04-30）。現在はコードで強制されています。

Generate.ts 自体が --workflow=<name>（または明示的なオプトアウト指定 --freeform-confirmed）を渡さない限り、実行を拒否します。ワークフローの参照表を表示して、ゼロ以外の終了コードで終了します。

**正しい手順：**適合するワークフローファイルを読む → そのプロンプトテンプレートに従う → --workflow=<そのワークフロー名> とモデル、プロンプト、サイズの各フラグを付けて Generate.ts を呼び出す。--workflow=<name> フラグは、「ワークフローを読み、指示に従いました」という明示的な宣言です。

**ブロックされる手順：**自由形式のプロンプトを作成し、それを直接 Generate.ts に渡すこと。Generate.ts は実行を拒否します。

よくある失敗パターン（繰り返さないでください）

ワークフローの警告に目を通して「ワークフローに従おう」と頭では認識しながら、より速く感じるという理由で、結局自分のプロンプトを使った Bash コマンドを作成してしまうことです。**やめてください。**ワークフローのテンプレートには、手法、配色、構成ルール、検証ゲートが定められています。これらは、何も指定しない場合にモデルが守れない要素です。これを省略した結果、文字どおり「absolute fucking ass」な図が生成されました。まずワークフローファイルを読んでください。テンプレートをもとにプロンプトを作成してください。ワークフローを確認できるよう、--workflow=<name> を渡してください。

ワークフロー → コマンド（コピー＆ペースト）

bun ~/.claude/skills/Art/Tools/Generate.ts \
  --workflow=<WorkflowName> \
  --model nano-banana-pro \
  --prompt "..." \
  --size 2K \
  --aspect-ratio 16:9 \
  --output "${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/<filename>.png

<WorkflowName> は、Workflows/ 配下のファイル名（.md を除く）と一致する必要があります。

ルーティングルール — プロンプトを作成する前に、必ず最初にワークフローを選択してください。

リクエストの種類	必須のワークフロー
ブログのヘッダー／エッセイ風の挿絵	Workflows/Essay.md — ステップ1～8を順番どおりに実行し、スキップしないでください
Mermaid 図	Workflows/Mermaid.md
技術図／アーキテクチャ図	Workflows/TechnicalDiagrams.md
フレームワーク／2x2／マトリックス	Workflows/Frameworks.md
D3 ダッシュボード／チャート	Workflows/D3Dashboards.md
分類体系／階層構造	Workflows/Taxonomies.md
タイムライン	Workflows/Timelines.md
比較	Workflows/Comparisons.md
統計カード	Workflows/Stats.md
格言／引用カード	Workflows/Aphorisms.md
コミックのコマ	Workflows/Comics.md
固定のハウススタイルによる YouTube／チャンネルのサムネイル	固定ハウススタイル専用のサムネイルスキルを使用してください — 固定スタイルを管理し、以下の Art ツールを統括します。チャンネルのサムネイルにこれらのワークフローを直接適用しないでください。
YouTube サムネイル（汎用的な仕組み。サムネイルスキルが統括）	Workflows/StyleMatchedThumbnail.md — 決定論的なテキスト＋実写の顔
YouTube サムネイル（従来版／検証用）	Workflows/AdHocYouTubeThumbnail.md または Workflows/YouTubeThumbnailChecklist.md
LifeOS パックのアイコン	Workflows/CreateLifeosPackIcon.md
ブランドロゴの壁紙	Workflows/LogoWallpaper.md
レシピカード	Workflows/RecipeCards.md
地図／概念図	Workflows/Maps.md
注釈付きスクリーンショット	Workflows/AnnotatedScreenshots.md
背景の削除のみ	Workflows/RemoveBackground.md
エンボス加工されたロゴの壁紙	Workflows/EmbossedLogoWallpaper.md
汎用的なビジュアライゼーション（上記のいずれにも当てはまらない場合）	Workflows/Visualize.md

唯一の例外： ユーザーが明示的に「freeform」／「skip the workflow」／「このプロンプトで Generate.ts を直接実行してください：...」と指示した場合です。その場合は、Generate.ts に --freeform-confirmed を渡してください（監査用に、明示的なオプトアウトが標準エラーに記録されます）。ユーザーからその明示的な指示がない限り、必ず該当するワークフローを選択して --workflow=<name> を渡してください。そうしないと、Generate.ts は呼び出しを拒否します。

リクエストに一致するワークフローがない場合は、生成を始める前に停止し、ユーザーに確認してください。次のいずれかを提案します。（a）既存の最も近いワークフローを使う、（b）汎用的な受け皿として Visualize.md を使う、または（c）まず CreateSkill スキルで新しいワークフローを作成する。独自の判断で進めないでください。

---

🚨🚨🚨 必須：まず Downloads に出力 🚨🚨🚨

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️  ALL GENERATED IMAGES GO TO $LIFEOS_DOWNLOADS_DIR (default ~/Downloads/ when unset) FIRST                   ⚠️
⚠️  NEVER output directly to project directories                    ⚠️
⚠️  User MUST preview in Finder/Preview before use                  ⚠️
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

これは、このスキルのすべてのワークフローに適用されます。

🚨🚨🚨 必須：ブログヘッダーの透明性に関するルール 🚨🚨🚨

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️  INLINE (body) image → TRANSPARENT (PNG with alpha)           ⚠️
⚠️  SOCIAL THUMBNAIL (frontmatter) → SEPIA #EAE9DF (opaque)       ⚠️
⚠️  EVERY blog header MUST use --thumbnail (produces both)        ⚠️
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ブログページの背景色はセピア色の #EAE9DF です。ページ上にきれいに重ねて表示するには、本文内の画像は必ず透明な PNG にしてください。ソーシャルプラットフォーム（X、LinkedIn、RSS リーダー）は透明度を保持しないため、白や黒が透けて表示されます。そのため、thumbnail: のフロントマターには、セピア色の背景を付けたバージョンを必ず指定してください。

Generate.ts の呼び出し時の適用ルール：

• ブログヘッダーで正しいフラグは --thumbnail のみです。このフラグは暗黙的に --remove-bg を有効にし、output.png（透明）と output-thumb.png（背景色 #EAE9DF）の両方を生成します。
• 背景の削除は rembg を使ってローカルで実行されます（外部 API は使用しません）。モデルが JPEG を返した場合（Nano Banana Pro ではよくあります）、Generate.ts は rembg の処理後に出力ファイルの拡張子を .jpg から .png に自動で変更します。これにより、最終的な透明画像は、実際のアルファチャンネルを持つ本物の PNG になります。.jpg に「transparent」とラベル付けされたファイルを見かけた場合、それは透明ではありません。
• rembg が ~/.local/bin/rembg にインストールされていない場合、ツールは不透明な画像を黙って生成するのではなく、インストール手順を表示して明示的に失敗します。インストール方法：pipx install rembg（または REMBG_BIN 環境変数を設定してパスを上書きしてください）。

画像の完成を宣言する前の確認手順（必須）：

1. file "${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/[name].png → PNG image data, ... RGBA（8-bit/color RGBA）と表示される必要があります。JPEG またはアルファチャンネルのない 8-bit colormap と表示される場合、透明化に失敗しています。
2. file "${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/[name]-thumb.png → PNG image data と表示される必要があります。サムネイルはセピア色の背景を持つ不透明画像です。
3. 両方の確認に合格した場合に限り、プロジェクトディレクトリにコピーして投稿に組み込んでください。

ブログ投稿への組み込み方法：

• 本文内：[![Alt](/images/blog/[slug]/header.webp)](/images/blog/[slug]/header.webp) — .png から変換した透明な WebP を使用してください。
• フロントマター：thumbnail: https://example.com/images/blog/[slug]/header-thumb.png — 必ず -thumb.png（不透明なセピア色の画像）を指定してください。

本文内の画像に不透明なサムネイルを使い回さないでください。ソーシャル用サムネイルに透明画像を使い回さないでください。これらは、1 回の --thumbnail 実行で生成される別々の 2 つの出力です。

認められている例外（このセクションが正式な参照先です。ブログ作成スキルもここを参照します）： すべてのブログヘッダーでは、本文内画像を透明にすることがデフォルトです。唯一の例外は、細い線画や木炭画風の作品で、rembg が作品自体を削除してしまう場合です（「注意点」を参照）。その場合は、ページの背景色と一致してきれいに重なる、不透明なセピア色 #EAE9DF の本文内画像を使用できます。不透明な本文内画像は、この失敗ケースに対する、記録されたフォールバックであり、第二のデフォルトではありません。

ワークフローの振り分け

リクエストに基づいて、適切なワークフローに振り分けます。

ワークフロー	条件	ファイル
エッセイ	ブログのヘッダーまたはエディトリアルイラスト	Workflows/Essay.md
RemoveBackground	画像の背景を削除	Workflows/RemoveBackground.md
LogoWallpaper	ロゴを組み込んだブランドロゴの壁紙	Workflows/LogoWallpaper.md
EmbossedLogoWallpaper	エンボス加工ロゴの壁紙	Workflows/EmbossedLogoWallpaper.md
D3Dashboards	D3.js のインタラクティブなチャートまたはダッシュボード	Workflows/D3Dashboards.md
Visualize	ビジュアライゼーション、または形式が不明な場合	Workflows/Visualize.md
Mermaid	Mermaid のフローチャートまたはシーケンス図	Workflows/Mermaid.md
TechnicalDiagrams	技術図またはアーキテクチャ図	Workflows/TechnicalDiagrams.md
Taxonomies	分類体系または分類グリッド	Workflows/Taxonomies.md
Timelines	タイムラインまたは時系列の推移	Workflows/Timelines.md
Frameworks	フレームワークまたは2x2マトリクス	Workflows/Frameworks.md
Comparisons	比較またはX対Y	Workflows/Comparisons.md
AnnotatedScreenshots	注釈付きスクリーンショット	Workflows/AnnotatedScreenshots.md
RecipeCards	レシピカードまたはステップごとの手順	Workflows/RecipeCards.md
Aphorisms	格言または引用カード	Workflows/Aphorisms.md
Maps	概念マップまたは領域マップ	Workflows/Maps.md
Stats	統計カードまたは大きな数値のビジュアル	Workflows/Stats.md
Comics	漫画または連続したコマ	Workflows/Comics.md
YouTubeThumbnailChecklist	YouTube サムネイルのチェックリスト、YouTube サムネイル（既存アセットを使用）	Workflows/YouTubeThumbnailChecklist.md
AdHocYouTubeThumbnail	アドホックな YouTube サムネイル（コンテンツから生成）	Workflows/AdHocYouTubeThumbnail.md
CreateLifeosPackIcon	LifeOS パックのアイコン	Workflows/CreateLifeosPackIcon.md

---

基本の美的スタイル

デフォルト： エディトリアルおよび技術コンテンツに適した、プロダクション品質のコンセプトアートスタイルです。

ユーザーカスタマイズでは、次のような具体的な美的嗜好を定義します。

• ビジュアルスタイルと影響を受けた作風
• 線の表現とレンダリング方法
• カラーパレットとウォッシュ技法
• キャラクターデザインの仕様
• シーン構成のルール

読み込み元： ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Art/PREFERENCES.md

---

参照画像

ユーザーカスタマイズには、スタイルの一貫性を保つための参照画像が含まれる場合があります。

次の項目について、~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Art/PREFERENCES.md を確認します。

• 参照画像の場所
• 用途別のスタイル例
• キャラクターやシーンの参照に関するガイダンス

使用方法： 画像を生成する前に、ユーザーが提供した関連する参照画像を読み込み、好みのスタイルに合わせます。

---

画像生成

デフォルトモデル： CUSTOMIZATIONS/SKILLS/Art/PREFERENCES.md でユーザーカスタマイズを確認します フォールバック： nano-banana-pro (Gemini 3 Pro)

モデル固有のサイズ要件

モデルごとに受け付ける --size の形式が異なります。誤った形式を使うと、検証エラーが発生します。

モデル	--size の形式	有効な値	デフォルト
flux	アスペクト比	1:1、16:9、3:2、2:3、3:4、4:3、4:5、5:4、9:16、21:9	16:9
nano-banana	アスペクト比	1:1、16:9、3:2、2:3、3:4、4:3、4:5、5:4、9:16、21:9	16:9
nano-banana-pro	解像度ティア	1K、2K、4K（--aspect-ratio も別途指定可能）	2K

OpenAI の画像モデルは削除済みです（2026-07-30、責任者の指示）。 gpt-image-1、gpt-image-2、およびデュアルプロバイダーの compare モードは Generate.ts から削除されています。これらを渡すと、nano-banana-pro を案内するエラーを出して終了します。OpenAI の画像生成経路を再導入しないでください。また、代替として別のベンダーを追加しないでください。いずれかのレーンに新しいベンダーを追加するには、責任者の明示的な承認が必要な、アイデンティティ／ドクトリンに関わる決定です。

モデルの選択 — 用途に応じた使い分け

Generate.ts には3つのモデルが組み込まれており、あらゆる用途でデフォルトとして nano-banana-pro が使われます。PREFERENCES.md が存在する場合は、ユーザーのデフォルトがそこに固定されます。

用途	モデル	理由
デフォルトですべての用途 — エディトリアルイラスト、ブログのヘッダー、テキスト主体の統計カード、フレームワーク、分類体系、年表、格言カード	nano-banana-pro	ユーザーのエディトリアルな美的感覚に最も忠実な構図を作成でき、テキスト主体のワークフローにも十分対応できるラベルや数値の表現力も備えています。
スタイルの幅を広げたい場合／非写実的な表現／よりシャープな技術的線画	flux	異なる美的表現が得られます。
構図が決まった後の素早い反復	nano-banana	生成はより速く、忠実度はやや低くなります。

注： nano-banana-pro では、解像度の品質に --size を使用し、アスペクト比には別の --aspect-ratio フラグを使用します（デフォルトは 16:9 です）。

🚨 重要：必ず最初に Downloads に出力してください

生成した画像はすべて、プレビューと選択のため、最初に $LIFEOS_DOWNLOADS_DIR（未設定の場合は ~/Downloads/）に保存する必要があります。

プロジェクトの public/images/ ディレクトリに直接出力しないでください。画像を使用する前に、ユーザーが Preview で確認する必要があります。

ワークフロー：

1. "${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/[descriptive-name].png に生成します
2. ユーザーが Preview で確認します
3. 承認された場合に限り、最終保存先（例：cms/public/images/）にコピーします
4. 最終保存先に WebP とサムネイル版を作成します

# CORRECT - Output to Downloads for preview
bun run ${LIFEOS_SKILL_DIR}/Tools/Generate.ts \
  --model nano-banana-pro \
  --prompt "[PROMPT]" \
  --size 2K \
  --aspect-ratio 1:1 \
  --thumbnail \
  --output "${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/blog-header-concept.png

# After approval, copy to final location (substitute your blog/site path)
cp "${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/blog-header-concept.png ~/your-site/public/images/
cp "${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/blog-header-concept-thumb.png ~/your-site/public/images/

複数の参照画像（キャラクター／スタイルの一貫性）

キャラクターやスタイルの一貫性を高めるには、複数の --reference-image フラグを使用します。

# Multiple reference images for better likeness
bun run ${LIFEOS_SKILL_DIR}/Tools/Generate.ts \
  --model nano-banana-pro \
  --prompt "Person from references at a party..." \
  --reference-image face1.jpg \
  --reference-image face2.jpg \
  --reference-image face3.jpg \
  --size 2K \
  --aspect-ratio 16:9 \
  --output "${LIFEOS_DOWNLOADS_DIR:-$HOME/Downloads}"/character-scene.png

API の上限（Gemini）：

• 人物の参照画像は最大5枚
• オブジェクトの参照画像は最大6枚
• 1リクエストあたりの参照画像は最大14枚

API キーの保存先： ${LIFEOS_DIR}/.env

例

例1：ブログのヘッダー画像

User: "create a header for my AI agents post"
→ Invokes ESSAY workflow
→ Generates charcoal sketch prompt
→ Creates image with architectural aesthetic
→ Saves to $LIFEOS_DOWNLOADS_DIR (default ~/Downloads/ when unset) for preview
→ After approval, copies to public/images/

例2：技術アーキテクチャ図

User: "make a diagram showing the SPQA pattern"
→ Invokes TECHNICALDIAGRAMS workflow
→ Creates structured architecture visual
→ Outputs PNG with consistent styling

例3：比較の視覚化

User: "visualize humans vs AI decision-making"
→ Invokes COMPARISONS workflow
→ Creates side-by-side visual
→ Charcoal sketch with labeled elements

例4：LifeOS パックのアイコン

User: "create icon for the skill system pack"
→ Invokes CREATEPAIPACKICON workflow
→ Reads workflow from Workflows/CreateLifeosPackIcon.md
→ Generates 1K image with --remove-bg for transparency
→ Resizes to 256x256 RGBA PNG
→ Outputs to $LIFEOS_DOWNLOADS_DIR (default ~/Downloads/ when unset) for preview
→ After approval, copies to ${PROJECTS_DIR}/LIFEOS/Packs/icons/

注意点

• 必ず最初に $LIFEOS_DOWNLOADS_DIR（未設定時のデフォルトは ~/Downloads/）へ出力してください。プロジェクトディレクトリへ直接出力することは絶対に避けてください。 ユーザーが使用前にプレビューする必要があります。誤った画像をリポジトリへ直接プッシュしたことによる失敗が過去に何度も発生しています。
• 完了を報告する前に、画像の寸法が用途に合っているか確認してください。 SNS のプレビュー、ブログのヘッダー、サムネイルではそれぞれ必要なサイズが異なります。ブログでは問題なく表示されるヘッダーでも、OG／SNS プレビューでは崩れることがあります。
• nano-banana-pro では解像度に --size（1K／2K／4K）を使い、アスペクト比には別の --aspect-ratio フラグを使います。 アスペクト比の値を --size に渡さないでください。
• 参照画像は、1リクエストあたり人物が最大5枚、物体が最大6枚、合計最大14枚です（Gemini API の制限）。
• 生成後、成功を報告する前に Read ツールで画像を開き、目視で確認してください。 実際に見ていない画像について「生成に成功しました」と報告しても意味がありません。
• 特定の画像 URL またはファイルを使うよう依頼された場合は、そのアセットをそのまま使用してください。 似た画像で代用しないでください。誤った画像アセットの使用により、過去に評価1の失敗が発生しています。
• --remove-bg は透明ではなく黒い背景を生成することがあります。 配置前に、透過 PNG を必ず目視で確認してください。
• --remove-bg は細い線画の技術図には安全に使えません。 rembg は明るい背景上の細い黒線を「背景」と判定して取り除くため、ほとんど何も残らないゴーストのような画像になります。この問題は2026-05-11に自由意志のフローチャートで記録されています。対策：（a）まず、rembg が明確に認識できるよう、プロンプトで太く鮮やかな線画を指定する、または（b）配置先の背景が画像の背景と一致する場合は、--remove-bg を完全に省略する（ブログページはセピア #EAE9DF なので、不透明なセピア色の図をセピア色のページに配置すれば、継ぎ目は見えず、アルファは不要です）。
• 参照画像を使っても、3D／遠近法のシーンではロゴの再現性が崩れます。 2026-06-11に UL の壁紙セットで記録されています。正面とマクロのシーンでは7回中7回、字形のトポロジーが維持されましたが、アイソメトリックな3Dシーンでは開いたマークがループ状に閉じ、独立したドットも消えました。ロゴを含む遠近法／3Dの構図では、--reference-image に加え、「形状をループ状に閉じない」「独立したドットを省略しない」のように、すべての線と端点を具体的に指定する、トポロジーを固定する否定表現をプロンプトに加えてください。また、トポロジーを重点的に目視確認してください。
• nano-banana-pro の「4K 16:9」は実際には5504×3072（43:24、16:9より約0.8%横長）で、--output に .png と指定しても .jpg として保存されます。 仕様が16:9の場合は実際の比率を明記し、Read／納品前に実際のファイル名を調べてください。
• 白い領域がクリーム色のページ上で白い四角形になる不具合（2026-06-20）：不透明な JPEG を #EAE9DF 上で平坦化しても何も変わりません。 nano-banana-pro が返すのは不透明な JPEG です。magick -background "#EAE9DF" -flatten が塗りつぶすのはアルファ部分だけなので、モデルに焼き込まれたほぼ白の背景はそのまま残り、クリーム色のブログページ上に白い四角形として表示されます（「背景が fucking white になっている」）。ブログ内のヘッダーでは、まず本物のアルファを切り抜き（bun ~/.claude/LIFEOS/TOOLS/RemoveBg.ts）、その後 WebP を作成してください。さらに identify -format "%[channels]" inline.webp の結果が srgba であることを確認してください。不透明なセピア画像をインラインで使えるのは、すでにアルファを持つ画像に限られます。Essay.md の Step 7.0.5 を参照してください。
• エッセイのヘッダーでは、プロンプトを作成する前に Step 5A の最適画像の検討を実施してください（2026-07-09 主任指示）。 主題を列挙するプロンプトでは、却下される平坦な構図になりがちです。エッセイ固有の論旨を深く考え、シーンのコンセプトを比較し、すべての要素に物語上の役割を与え、要素同士を結び付けた構図から、採用される画像が生まれます。この検討は必須のステップです。カットアウェイなどは選択肢の一例であり、ルールではありません。Essay.md の Step 5A を参照してください。
• 被写体の内部を白くしないでください（2026-07-09、「巨大な白い空間」事案）： 机、パネル、窓、紙などの広い平面は、明るい白や色の指定なしではなく、「温かみのあるクリーム色の紙のような色調」と指定してください。白く焼き込まれた内側の部分は rembg でもそのまま残り、クリーム色のページ上に巨大な白い四角形として表示されます。これは2026-06-20の白い四角形の不具合と同じく、被写体内部で発生する問題です。また、外部のスクリーンショットを埋め込む前に、白い余白を削除してください（magick -fuzz 4% -trim ＋セピア色の枠線）。
• 参照画像の編集では、否定的な指示より参照画像の内容が優先されます（2026-07-09、スタジオ背景のセッション）。 nano-banana-pro が参照写真に写っている不要な物体（例：2台目のフロアランプ）を繰り返し再現する場合、「追加／複製しないで」というプロンプトの指示は約8回中7回失敗します。モデルは、禁止された内容よりも参照画像に写っているものを優先して残します。対策：構図が修正された出力が1枚得られるまで生成し、それを残りのバリエーションの新しい --reference-image として使ってください。これにより、指示への準拠率は7回中7回に上がりました。編集内容を説明するより、参照画像を編集するほうが効果的です。
• 複数の人物が登場する場合は、肌の色に幅を持たせてください（2026-07-12 主任指示）。 画像モデルはすべての人物を白人として描く傾向があります。複数の人物が登場するシーン（エッセイのヘッダー、コミック、ビジュアライゼーションなど）では、自然な幅の肌の色を指定するプロンプトを明示してください。チャコールスタイルでは、人物ごとにウォッシュの色合いや濃淡を変えてください。さりげなく自然に表現し、形式的な配慮にしないでください。ただし、全員が白人のグループは検証不合格です。Essay.md の HUMAN FIGURES ブロックと Step 8 のチェックリストを参照してください。
• エッセイ／ブログのヘッダーには必ず「{{DA_NAME}}」の署名を入れてください（2026-06-20および2026-07-09 主任指示）。手書き風の筆記体で、小さく、構図に溶け込ませます。 Generate.ts／Essay.md の Step 7.1 でプログラムから追加してください（SignPainter-HouseScript、画像幅の約3%、半透明のチャコール色、わずかに傾け、構図の右下に配置）。モデルには署名をプロンプトで指示しないでください（文字が崩れます）。フォーマルなカリグラフィー書体（Snell-Roundhand／Apple-Chancery／Savoye）は引き続き不採用です。また、サイズが大きく印刷文字風の Bradley Hand は、2026-07-09に「もっと筆記体らしく、小さく、画像になじませる」方針で置き換えられました。

実行ログ

ワークフローを完了した後、JSONL エントリを 1 つ追加します。

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Art","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

WORKFLOW_USED を実行したワークフローに、8_WORD_SUMMARY を入力内容の簡潔な説明に、SECONDS をおおよその実時間に置き換えてください。ワークフローが失敗した場合は、status: "error" を記録してください。