illo

Illo

事前確認 — このコピーは移行済みです（最初にお読みください）

このインストールは tmchow/agent-skills から行われましたが、ここでは illo の更新が提供されなくなりました。正規の配布元は tmchow/illo-skill で、すでに新しいバージョンが公開されています。セッションごとに一度、illo に関する作業を始める前に、このコピーは 0.19.x で更新が止まっていることをユーザーに伝え、新しい配布元からの再インストールを提案してください。ユーザーの明示的な許可なしに、再インストールしてはいけません。 許可を得たら、現在のランタイムに合った手順を実行し、続行する前に新しいコピーが有効になっていることを確認してください。

• skills CLI（Claude Code、Cursor、Codex、…）： npx skills add tmchow/illo-skill --skill illo
• Hermes：hermes skills uninstall illo を実行してから、 hermes skills install tmchow/illo-skill/illo （対話型セッションの場合：/skills install tmchow/illo-skill/illo を実行し、その後 /reload-skills）
• OpenClaw：openclaw skills install illo

ユーザーが辞退した場合は、このコピーを使って通常どおり続行してください。問題なく動作しますが、更新されないだけです。同じセッションで提案を繰り返さないでください。

文章コンテンツ向けに、独創的で個性のあるエディトリアルイラストを制作します。1枚の画像で1つのアイデアを説明します。重要な判断、流れ、ビフォーアフター、落とし穴、ループなどです。繰り返し登場するマスコットが、すべての場面でアイデアを実演します。主役であり、飾りではありません。1つのアイデアが段階を追って展開する場合は、1枚の画像に2～4コマを収めたミニコミックにできます。また、パイプライン、ファンアウト、タイムライン、ループなど、アイデア自体が追跡可能な構造である場合は、同じマスコットと画風で、矢印や吹き出しを添えた手描きのスケッチ図として構造を描く解説図にできます（references/composition.md の「Two registers」を参照。エディトリアルシーンが常にデフォルトです）。

これは設定可能なハウススタイルであり、汎用画像ジェネレーターではありません。手法は固定で、キャラクターパックとパレットがパラメーターです。また、キャラクターパックには画風も含まれます。バンドルされた画風ライブラリ（リソグラフ — 粒状のハーフトーン、インク層のずれ、紙の質感、太く柔らかな丸みのある輪郭線。ほかにブループリント、木版画、ピクセル、粘土、マニラ紙、チョーク、フォスファー、エナメル、ガッシュ）から1つ選ぶか、カスタムのスタイルファイルを使用します。デフォルトのマスコットは、リソグラフ画風の無表情なインクのしずく、Blotです。パレットはプリセット、ユーザー独自のパレットファイル、または1色から導出したものを使用できます。どのようなパラメーターを使う場合も、写真でも、ロゴでも、企業向けインフォグラフィックでも、正式なフローチャートでも、UI モックアップでもありません。

ユースケース — リクエストを振り分ける

ユーザーの希望	パス
記事／投稿／ニュースレター／URLをイラストにする	ステップ 0–7：まずソースを振り分けます（主旨 → カバー範囲：ヒーロー／ヒーロー＋セット／セット／ミニコミック — references/composition.md、「Source routing」）。次にショットリスト（ヒーロー行＋アンカー）を作成し、アンカーごとに画像を 1 枚作り、配置に応じて交互に挿入します。
単一のコンセプトを表す画像 1 枚	ステップ 1 のコンセプト分岐（アイデアが曖昧な場合は、手短な質問を最大 3 つほど）を経て、画像を 1 枚作成します。
一連の流れ — プロセス、変化前→変化後、失敗→修正	展開が同じ場所で完結する場合は、ミニコミック 1 本です（references/composition.md の形状の振り分け — 形状を選ぶのはアイデアであり、行き先ではありません）。
構造を追える表現 — 「流れを見せる」「パイプラインを図解する」「手順をマップする」「解説形式で」	解説レジスター（references/composition.md、「The explainer register」）：現在のルックで、手作りのフロー／分岐／タイムライン／ループ／スタック／システムの一部を描き、マスコットをその中で機能する要素として表現します。ユニットの主旨が構造そのものである場合は、これらのフレーズがなくても利用できます（レジスターの判定）。
ソーシャルメディア向けのアート	16:9（または 1:1）、大胆な ink-punch、設定済みまたは指定された場合は x ハンドルの透かし。
ブログ／ブランド／サイトに合わせたアート	名前付きまたはカスタムのパレットを使うか、主となる色 1 色からパレットを導きます（references/palettes.md）。
独自のマスコット — 「キャラクターを作って」「自分たちのマスコットを使って」「Blot を置き換えて」	キャラクタービルダーを使います。references/character-builder.md を最後まで読み、最初から最後まで手順に従ってください。
コミュニティのキャラクター — 「使えるキャラクターは？」「blip をインストールして」「mole を更新して」「自分のキャラクターを公開して」	references/pack-sharing.md — エンジンの packs list/show/install/update を使い、GitHub PR で公開します。
別のルック — 「設計図風で」「木版画風で」「blip をピクセル版にして」	スタイルはキャラクターパックと一緒に引き継がれます。references/character-builder.md の「Style variants」に従って、スタイルバリアントパックを作成します。
選択肢、または「どのモデルが最適？」	ステップ 5b：--count でバリエーションを作成するか、モデルを順に試し、推奨とともに gallery を表示します。
既存の画像を修正する（余計なタイトル、色の変更、マスコットが装飾的すぎる）	references/prompt-recipe.md の編集用プロンプトを使い、画像を --ref として渡します。

前提条件

• OpenRouter API キー。 生成は scripts/illo.py（インストール不要の Python 標準ライブラリ）を介して、OpenRouter の画像 API に直接リクエストします。キーはユーザーの設定ファイルに保存されます。これは唯一の認証情報の経路であり、ユーザーが実行する init によって一度だけ書き込まれます（モード 600）。エンジンは環境変数からシークレットを読み取らず、コマンドライン引数としても受け付けません。
• python3 とネットワークアクセス。それ以外にインストールするものはありません。
• エンジンでは モデルを選択できます（--model）。デフォルトモデルは英語のラベルを安定して描画し、キャラクターの一貫性を保つために参照画像を尊重します。

セットアップはユーザーが行います（キーを自分で入力しないでください）

API キーを入力するのはユーザーです。ユーザーのキーを入力、貼り付け、表示、保存してはいけません。初期設定の方法を案内してください。

• 初期設定（ユーザーが実行）： python3 "$SKILL_DIR/scripts/illo.py" init — 非表示の入力欄でキーを求め（入力内容は表示されません）、YAML 設定 ${XDG_CONFIG_HOME:-~/.config}/illo/config.yaml（モード 600）を書き込みます。シークレットではないデフォルト値も保存できます：--model、--palette、--aspect、--character、--watermark。保存済みのキーに触れずに設定を更新するには --no-key を使います。（設定ファイルは PyYAML がインストールされている場合に PyYAML 経由で読み取られます。ない場合も、組み込みの簡易パーサーで apiKey、model などのフラットなキーを読み取れるため、生成にインストールは必要ありません。watermark などのネストされた設定に限り、PyYAML が必要です：python -m pip install 'PyYAML==6.0.2'。）
• シークレットではない設定は、同じコマンドと --no-key を使ってユーザー用に設定できますが、キー自体はユーザーが入力します。

Hermes Agent のみ：バイナリアセットの修復に関する事前確認

一部の Hermes バージョンでは、GitHub から複数ファイルのスキルをインストールする際にバイナリファイル（同梱のキャラクターシート）が破損します。テキストファイルは残りますが、バイナリは残らず、シートが破損するとキャラクターの一貫性がひそかに崩れます。Hermes Agent の場合、初回使用の前に一度（また、doctor が assets: CORRUPTED と報告したときにも）実行してください。

bash ${HERMES_SKILL_DIR}/scripts/repair-hermes-assets.sh

同梱されているすべてのバイナリを既知の正常な SHA256 ハッシュ（assets/checksums.txt）と照合し、不一致のファイルのみを固定された不変の URL から再ダウンロードします。すべて正常な場合は何も行いません。Claude Code、Codex、OpenClaw、または忠実にインストールするランタイムでは、これをスキップしてください。doctor はあらゆる環境でアセットの整合性を確認し、修復が必要な場合は通知します。

必要に応じて以下のリファレンスを参照してください

一度にすべてを読み込まないでください。手順に合ったファイルを参照してください。

• references/visual-style.md — デフォルトの作風であるリソグラフ印刷の技法、線の表現、紙とインク、厳守すべき禁止事項と推奨事項。
• references/styles/<name>.md — キャラクターパックで使用する、その他の作風ライブラリ（blueprint、woodcut、pixel、clay、manila、chalk、phosphor、enamel、gouache）。生成前に、使用するキャラクターの作風ファイルをすべて読んでください。
• references/character.md — キャラクターのルール（根幹となるテスト、複雑さを抑えるためのガードレール、パレットに沿った明度）、デフォルトのキャラクター Blot、カスタムパックの形式。キャラクターに関する作業の前に読んでください。
• references/character-builder.md — ユーザー独自のマスコットをデザインしてインストールするためのガイド付き手順。キャラクターを作成または置き換える前に、すべて読んでください。
• references/pack-sharing.md — コミュニティリポジトリからキャラクターをインストールする方法と、PR 経由でパックを公開する方法。インストールまたは公開の依頼を受ける前に読んでください。
• references/palettes.md — 名前付きプリセット、デフォルトの解決方法、カスタムパレット、1 色からパレットを導き出すアルゴリズム。パレットを選択または導出する前に、すべて読んでください。
• references/composition.md — 2 つの表現形式（エディトリアルシーン／解説図）、解説図の構造タイプと予算、構図、アイデアを動きに変換する方法、構図の再利用禁止ルール、ショットリストの形式。
• references/models.md — モデル一覧：表示名から OpenRouter ID への対応表、特性、アスペクト比に関する注意点、404／フォールバック時の処理。--model を渡す前に読んでください。
• references/prompt-recipe.md — 生成用プロンプトテンプレートと編集・再配色用プロンプト。
• references/quality-bar.md — 生成後のチェックリストと反復のルール。納品前に読んでください。

assets/character-reference.webp はデフォルトキャラクターの正式なモデルシートで、一貫性の基準としてエンジンで使用されます（後述）。カスタムパックには独自のシートが含まれます。作風の調整例は同梱されていません。各作風ファイルに記載された URL から必要に応じて取得し、線の密度、ネガティブスペース、アクセントの抑制を確認してください。構図をそのまま模倣してはいけません。現在の作品に合った新しいメタファーを考案してください。

ワークフロー

0. 事前確認

生成する前に、エンジンの準備ができていることを確認してください。

python3 "$SKILL_DIR/scripts/illo.py" doctor

単独で実行し、決して && で連結しないでください。表示される終了コード自体が準備状況を示します（0 = 準備完了）。連結したコマンドのいずれかが失敗すると、問題のないチェックまでエラーとして表示されます。

python、設定ファイルのパス、解決されたモデル／パレットのデフォルト値、カスタムキャラクターパックまたはカスタムパレットファイルが存在するかどうか、キーが見つかったかどうか（キー自体は表示しません）を報告します。終了コード 0 = 準備完了です。キーが見つからないと判断する前に、表示された設定ファイルのパスを確認してください。Hermes でマルチプロファイルを設定している場合、HOME／XDG_CONFIG_HOME が別のプロファイルのホームを指すことがあり（例：…/profiles/<name>/home/.config/illo/…）、存在するキーが見つからないように見えることがあります。パスが誤ったプロファイルを指している場合、キーが見つからないと判断せず、適切な HERMES_HOME／HOME／XDG_CONFIG_HOME を指定して再実行してください。キーが本当に存在しない場合は、そこで止めて、ユーザー自身に python3 "$SKILL_DIR/scripts/illo.py" init を実行してもらってください。ユーザーに代わってキーを入力してはいけません。チャットセッションではユーザーがその場でコマンドを実行できないため、まずユーザー側の作業を減らします。自分で init --no-key を実行してください（これは許可されています。デフォルト値とコメントアウトされた # apiKey: プレースホルダーを含む設定ファイルを、キーに一切触れずにモード 600 で作成します）。その後、ユーザーに、エージェントが実行されるマシン（そのマシンはユーザーのものです。エージェントをインストールした場所です）で一度だけ実行する、同等の方法を2つ提示してください。python3 <resolved absolute $SKILL_DIR>/scripts/illo.py init を実行する（入力時は非表示になります）か、~/.config/illo/config.yaml を開いて apiKey: の行に入力する方法です。キーをチャット経由でやり取りしてはいけません。ユーザーが誤って貼り付けた場合も、そのキーは使用せず、openrouter.ai でそのキーを失効させ、ホスト上で新しいキーを設定するよう伝えてください（貼り付けたキーはチャット履歴およびプラットフォームのサーバーに残るためです）。環境変数やその他の保存場所からキーを自分で設定ファイルにコピーしてはいけません。その行に書き込めるのはユーザーだけです。ただし、範囲を限定した例外が1つあります。Claude Code web、Codex cloud、CI などの一時的なクラウドワークスペースで、ユーザーがプラットフォームのシークレット機能を通じて OPENROUTER_API_KEY を設定した場合です。その設定自体が、ユーザーによるワークスペース限定の明示的な同意にあたります。また、その環境には対話式プロンプトも init 用の永続的なホームもありません。その場合に限り、ワークスペースのシークレットから一度だけ設定ファイルを作成してください（README.md の「Cloud & CI」にある1行のコマンドを使います）。個人のマシンでは、環境変数が設定されていても、ユーザーの意図を証明するものではありません（他のツール用かもしれません）。したがって、キーをコピーしてはいけないというルールは変わりません。

1. 入力を読み取り、曖昧なコンセプトを簡潔に明確化する

入力には、扱い方が異なる2種類があります。

• URL／記事／貼り付けた文章／長文投稿には、それ自体に文脈があります。ただし、最初に目を引く詳細から生成を始めないでください。まずルーティングを行います（references/composition.md の「Source routing」）。ソースの形式とジャンルを分類し、ソースの修辞的な役割と、絵にしやすい最も目立つ詳細を切り分け、主旨を1文で確定します（ヒーロー画像が捉えるのはソースの役割であり、最も目立つ証拠ではありません。各ジャンルで何をヒーロー画像にするかは、ジャンルごとのガードレールで定められています）。次に、カバー範囲を選びます。ヒーロー画像、ヒーロー画像＋セクションごとのセット（記事全体の役割を網羅）、セット、ミニコミック、または先にショットリストを作成します。セットには配置が必要です。短いソース（ツイートや1つのコンセプト）からセットを作ることはありません。複数の展開がある形式はミニコミックです。重要な場面、つまり判断、ループ、入力→出力、前後の変化、落とし穴が明らかになる数少ない箇所を抽出します。段落ごとに1枚の画像を作ることはありません。文章にはすでにテーマが書かれているため、ユーザーに質問しないでください。ただし、例外が1つあります。複数の展開があるソース（長い記事、事後検証、複数の主張を含むローンチ）について、複数画像を使う前に、カバー範囲について1つだけ質問します。ただし、ユーザーがすでにカバー範囲を指定している場合は除きます。複数の展開があるソースから画像を1枚だけ作る場合は、ヒーロー画像として、その旨を伝えて提供します。記事全体をカバーしたかのように提供してはいけません。

• 単独のコンセプトや一言の指示（例：「ボトルネックになっているのはあなたです」をイラストにする）は、通常、絵の内容を決めるには情報が足りません。**出力に影響するものに限って、簡単な質問を最大3つほど尋ねてから作成します。**次の点を確認してください。

  • 伝えるべき唯一の要点（読者に何を結論づけてほしいか）。
  • 掲載先（ブログ／X／スライド資料 → 配色、アスペクト比、透かしが決まります）。
  • 形式：画像1枚（デフォルト）、ミニコミック（1枚の画像に2～4コマ。アイデア自体が段階的に展開する場合に限る）、または複数の個別画像。必ず含める要素や制約も確認します。形式はアイデアに応じて決め、掲載先によって決めてはいけません（references/composition.md）。

  短いやりとりは1回だけにして、その後は作成に進みます。ユーザーがすでに十分な情報を伝えている場合、「そのまま作って」「1枚で」「おまかせ」などと言っている場合、または文脈から答えが明らかな場合は、質問をすべて省略します。明確な依頼を質問で妨げてはいけません。

2. キャラクターを決める

インストール済みのパックは ${XDG_CONFIG_HOME:-~/.config}/illo/characters/ にあります（形式と保存場所の詳細は references/character.md）。インストール済みのパックは doctor で確認できます。ユーザーは複数のパックを保持し、実行ごとに選べます。次の順に照合し、最初に一致したものを使います。

1. 明示的な指定 — 「を使って」「として」などの指定があれば、そのパックを使います。名前を指定してデフォルトを求められた場合は、同梱のデフォルトである blot を使います。
2. 設定のデフォルト — 設定されている場合は、ユーザー設定の defaultCharacter を使います。
3. 同梱のデフォルト — Blot（仕様は references/character.md、モデルシートは assets/character-reference.webp）。

決定したら、そのパックの character.md を読み、デフォルトを使う箇所すべてで、そのパックのプロンプト仕様、値のルール、reference.png を使用します。

ユーザーが新しいキャラクターを希望する場合は、キャラクタービルダーを使います（references/character-builder.md）。他の人のキャラクターを希望する場合は、コミュニティリポジトリからパックをインストールします（references/pack-sharing.md）。どちらの場合も、まずインストールしてから、ここに戻って続けます。

3. 計画する（ショットリスト）— 計画を求められた場合、または複数画像を作成する場合

ユーザーが計画（「どこにイラストを入れるべきか」「ショットリスト」）を希望した場合は、生成前にショットリストを出力します。各画像について、配置、伝える唯一のアイデア、トーン（説明ゲートを通過した項目を除き、エディトリアル）、演出（または構成タイプ）、マスコットが何をしているか、配色、短い英語のラベルを記載します（トーンごとの上限は references/composition.md）。アンカーの数に応じて画像の枚数を決めます（範囲と水増し禁止のルールは references/composition.md）。文章の一部分が同じ場所で段階的に展開する場合は、複数の画像ではなく、その部分にミニコミック画像を1枚計画します。ミニコミックと個別画像の使い分けは references/composition.md に記載されています。

4. パレットを解決する（キャラクターらしさを決めるのはスタイルです）

スタイルは個別には解決できません。有効なキャラクターのパックに含まれており、その character.md の Style: 行で、同梱のルック（references/styles/<name>.md、riso の場合は visual-style.md）または ${XDG_CONFIG_HOME:-~/.config}/illo/styles/<name>.md にあるカスタムスタイルを指定します。行がない場合は riso です。Blot は riso です。riso 以外のスタイルでは、そのファイルを最初から最後まで読みます。ファイルには STYLE と LINE LANGUAGE のプロンプトブロック、パレットのマッピング、キャラクターの描写方法、追加の QA チェックが記載されています。同じキャラクターを別のルックで使うリクエストは、バリアントパックのビルド（ルートテーブル）として扱います。その場でスタイルを変更してはいけません。

パレット：references/palettes.md を最初から最後まで読み、そこに記載された手順で解決します。解決順（明示的なリクエスト、次にユーザーのパレットファイルによる出力先のヒント、次に設定のデフォルト、最後に標準の ink-punch）、名前付きプリセット、カスタムパレット、単色からパレットを導出するアルゴリズムが記載されています。最後に具体的な16進数の値を確定し、パックのスタイルが riso 以外の場合は、そのスタイルのパレットマッピングを適用します。

5. 生成 — 参照画像に忠実に、1画像につき1つのメタファー

references/prompt-recipe.md に従って画像ごとに完全なプロンプト（シーン＋構成＋スタイル＋有効なキャラクターの仕様＋解決済みのパレットの16進数値＋ラベル最大3つ）を作成し、ファイルに書き込んでレンダリングします。毎回、有効なキャラクターのモデルシートを --ref として渡してください。この参照による条件付けがマスコットをモデルどおりに保ちます。スタイルとパレットはプロンプトで指定するため、どちらも差し替え可能です。パックのシートはそのパック独自のスタイルで作られているため、シートとスタイルは常に一致し、異なるスタイルの参照画像を組み合わせる必要はありません。（Hermes Agent では、最初に --ref を使う前に、上記のアセット修復の事前チェックを実行しておく必要があります。シートが破損していると、すべてのレンダリングが不正な情報に基づいて条件付けされます。）

SKILL_DIR="<path to this skill>"           # contains scripts/illo.py + assets/
REF="$SKILL_DIR/assets/character-reference.webp"   # or the active pack's reference.png

python3 "$SKILL_DIR/scripts/illo.py" generate \
  --prompt-file /tmp/shot-01.txt \
  --ref "$REF" \
  --aspect 16:9 \
  --out "assets/<slug>-illustrations/01-topic.png"
  # --model <id> to override the config/default model for this image

illo.py generate は画像ごとに JSON 行（{path, model, id, cost, width, height, label, prompt}）を出力し、同じレコードを <out-dir>/manifest.jsonl に追記します。--cost を渡さない限り cost は null です（gallery が後から補完します）。 .path を確認してください。--out と異なる場合があります。エンジンは実際のエンコーディングに基づいてファイル名を付けるためです（一部のモデルは JPEG バイト列を返すので、.png を指定しても .jpg になります）。16:9 を指定したのに正方形になっていないか確認するには .width/.height を使います（その場合は再生成します）。 各画像は個別に生成し、複数のアイデアを1つのキャンバスにまとめてはいけません。デフォルトのアスペクト比は 16:9 です。ソーシャル用には 1:1、縦長には 9:16／4:5 を使います。ギャラリーに表示するキャプションを指定するには --label を渡します。

セット全体を1人のアーティストが描いたように仕上げます。 複数画像のセットでは、品質基準をすべて満たした最初の画像（未確認のレンダリングは使いません。たとえば、パレットに合わない地色のような不合格の画像を基準にすると、セット全体にその問題が波及します）が、そのセットのスタイルアンカーになります。後続のセット内の画像すべてと、セット内の画像を再生成するたびに、キャラクターシートの後ろに2つ目の --ref として渡してください。これにより、線の太さ、ハーフトーンの密度、平面的な表現と立体的な表現のバランスをセット全体で統一できます。同じ方法で、単発の画像でもスタイルを固定できます。完成済みの画像を2つ目の --ref として追加します。

モデルの選択。 --model を渡す前、またはユーザーが平易な言葉でモデルを指定した場合や「最高品質」／「最安」を求めた場合は、references/models.md を最初から最後まで読みます。フレンドリー名から OpenRouter ID への対応表、モデルごとの特性、アスペクト比に関する注意点、404／フォールバック時の処理が記載されています。解決順は --model、設定の model、組み込みのデフォルトです。

ウォーターマーク／クレジット表記（任意、デフォルトではオフ）。 スキルにはデフォルトのウォーターマークがありません。テキストはユーザーの watermark 設定マップ（設定ファイルから読み込み）または明示的なリクエストからのみ取得されるため、インストールした人が他人のハンドル名を引き継ぐことはありません。解決順、追加するプロンプト行、2回レンダリングする際の注意点は references/prompt-recipe.md に記載されています。

5b. バッチ処理と比較（役立つ場合に限る）

デフォルトは画像1枚です。 ユーザーが選択肢や比較を求めた場合、または重要度が高く、複数枚作成する価値がある場合に限って並行生成します。その際は、先にユーザーの OpenRouter アカウントに請求されること（モデルによって異なりますが、通常は画像1枚あたり10セント未満）を伝えてください。 Nは小さく保ち（2～4）、エンジンのプリミティブを使ってループを制御します。

RUN=$(python3 "$SKILL_DIR/scripts/illo.py" newrun)      # -> /tmp/illo/<runid>
# record the user's VERBATIM request (URL, pasted text, concept) — the
# gallery shows it as provenance so anyone can tell what the run was for:
printf '%s' "<the verbatim request>" > "$RUN/request.txt"
# (a) VARIATIONS — same prompt+model, pick-the-best:
python3 .../illo.py generate --prompt-file p.txt --ref <ref> --count 4 --label "draft→ship" --out "$RUN/v.png"
# (b) MODEL COMPARISON — loop the SAME prompt over the chosen models
#     (full OpenRouter ids from references/models.md):
for m in <model-id-1> <model-id-2>; do
  python3 .../illo.py generate --prompt-file p.txt --ref <ref> --model "$m" --label "$m" --out "$RUN/$(basename $m).png"; done
# (c) CONCEPT VARIATIONS — different prompts (different stagings) for one idea:
python3 .../illo.py generate --prompt-file staging-A.txt --ref <ref> --label "as a funnel" --out "$RUN/a.png"
python3 .../illo.py generate --prompt-file staging-B.txt --ref <ref> --label "as a crossing" --out "$RUN/b.png"

python3 "$SKILL_DIR/scripts/illo.py" gallery "$RUN" --title "<the piece or request>" --open
# always pass --title so a saved gallery stays identifiable later;
# add --embed for a single portable file (images inlined)

各 generate は $RUN/manifest.jsonl に自動で記録されます。gallery はそれらを1ページにまとめ、各画像のラベル、モデル、寸法、コスト、および折りたたみ可能なプロンプトを表示します。コンセプトのバリエーションを比較する際、変数となるプロンプトを切り替えられるため、比較がしやすくなります。ギャラリーは、単に結果を並べるのではなく、おすすめを添えて必ず提示してください。チャットセッションでは、ギャラリーではなく、ラベル付きの候補をチャット内に直接提示してください（ステップ7の配信先の振り分けを参照）。複数モデルでの生成失敗は画像ごとに発生します（モデルが利用できない場合、その画像の生成だけが失敗します）。残りはそのまま使ってください。

6. QAと反復

すべての画像を references/quality-bar.md に照らして確認します。マスコットが装飾的になっている、または固定仕様から外れている、ボディカラーがパレットに合っていない、ラベルのテキストが色付きの塗りつぶし部分に配置されている、アクセントがキャラクターのアクセントパーツと1～2個の要素を超えて広がっている、不要なタイトルバーが表示されている、構図がサンプルの模倣になっている、またはテキストに誤字がある場合は、再生成するか編集してください。被写体の大きさは実行ごとに変わります。被写体が小さすぎる場合は再生成してください（JSONの .width/.height を確認してください。16:9を指定したのに正方形で返ってきた場合は、再生成してください）。再生成によって既存の画像が置き換えられる場合は、レビュー用の成果物に却下した画像が表示されないよう、--exclude <superseded label>（複数回指定できます）を使って、配信用のギャラリーを作り直してください。

7. 納品 — セッションの媒体に合わせる

適切な場合は、完成品をユーザーの作業ファイルの隣にコピーします。依頼されていない限り、既存のアセットを上書きしてはいけません。ファイル名が役割を示します。ドキュメントへの添付後にも残る唯一のメタデータなので、用途を特定できる名前にします。ヒーロー画像には 00-hero-<slug>.png、続いて、作品内の順序に従ってセクションの目印となる画像には 01-<section-slug>.png、02-<section-slug>.png、…を付けます（assets/<slug>-illustrations/）。その後、画像の枚数、使用したパレット、特に優れた画像と任意の画像を報告します。また、複数画像の依頼では配置マップも添えます。画像ごとに1行で、ファイル名、役割（ヒーロー画像、またはどのセクションの後に置くか）、伝えるアイデアを示します。ユーザーが配置を考え直さずに、それぞれのファイルを適切な場所に置けるようにしてください。画像自体は、このセッションで実際に表示できる方法で納品します。

• ファイルシステムのセッション（IDE／ターミナルエージェント — Claude Code、Codex、Cursor）：各完成品の絶対パス（エンジンの JSON .path はすでに絶対パスです）を報告し、複数画像の場合はギャラリーを提示します。ディスク上のファイル自体がすでにオリジナルなので、ここでは [[as_document]] を絶対に出力しないでください。これは Hermes ゲートウェイ用のトークンであり、他のランタイムでは文字列ノイズになります。ランタイム独自のチャット内ファイル配信機能がある場合は、それを使用してください。

• チャットのセッション（ユーザーがメッセージングサービス上にいて、ローカルファイルを開けない場合 — Telegram／Discord／WhatsApp 上の Hermes、またはメディアを劣化させて配信するチャット画面）：パスだけでは納品として不十分です。画像はチャット内に届く必要があり、完成品はオリジナルファイルとして届かなければなりません。プラットフォームの写真配信では画像が再圧縮されます。これはリソグラフの粒子、ハーフトーンのテクスチャ、インク層のずれ、繊細な手書き文字を損なう原因になります。そのため、完成品はドキュメント添付ファイルとして納品します。Hermes では、各完成品に明示的な MEDIA: 添付タグを付けます。タグは MEDIA: の直後に絶対パスを続け、間にスペースを入れません。また、同じ返信内にリテラルの指示子 [[as_document]] を含めてください。完成品の納品に絶対パスだけを使ってはいけません。パスだけでは添付ファイルとして送信されず、文字列のままユーザーに表示されることがあります。

  MEDIA:/absolute/path/to/final.jpg
  [[as_document]]
  

候補やオプションを提示する段階では、手早く確認できる場合に限り、通常のインライン写真配信を使ってもかまいません。その場合は「プレビュー — オリジナルファイルは後ほど送付」と伝えます。ただし、完成品をその方法で納品してはいけません。チャットでは HTML ギャラリーを使わないでください。ユーザーが簡単に開いたり、ホストしたりする方法がないためです。ラベル付きの完成品をおすすめの説明文とともに直接送信し、ポータブルな成果物が明示的に求められた場合にのみ、gallery --embed（自己完結型ファイルを1つ）を作成し、[[as_document]] を付けて納品してください。

チャットセッションで最終返信を送る前に、次の点を確認します。

• 各完成品のパスは、指定した --out ではなく、エンジンの JSON .path から取得したものか（実際の拡張子が異なる場合があります）。
• 各完成品が、返信内に明示的な MEDIA:/absolute/path 添付タグとして含まれているか。
• プレビューのみの場合を除き、返信に [[as_document]] が含まれているか。
• 却下または再生成した候補が納品対象から除外されているか。
• 実装上の余計な情報ではなく、何を作成したか — キャラクター、パレット、最も優れた完成品、複数画像の場合は配置マップ（どのファイルがヒーロー画像か、どのセクションの後にどの画像を置くか） — が文章で説明されているか。

出力の方針

生成前の計画は、短く具体的にします。生成後は画像に語らせ、スタイル論ではなく、何をどこに作成したかを報告します。ラベルは少数にとどめ、短くします。画像に含める言葉が少ないほど、より安定して描画されます。