illo

Illo

为书面内容创作原创、鲜明的编辑插画。一张图片解释一个想法：一个关键判断、一段流程、一个前后对比、一个陷阱、一个循环。每个场景中，都由一个反复出现的吉祥物来呈现这个想法——它是主体，绝非装饰。当一个想法逐步推进时，可以采用迷你漫画形式：在一张图片中包含 2–4 个分格。如果想法本身是一种可追踪的结构——管线、标注阶段、分支、时间线、循环——则可以采用说明图形式：由同一个吉祥物以相同风格，用手绘草图式示意图绘制结构，并配上箭头和标注（references/composition.md 中的“Two registers”和“Pick the diagram type”；编辑场景始终是默认形式）。命名管线或配方属于这种形式中的标注阶段——按顺序排列的命名阶段，构成一个连贯系统，根据该形象的设定包量身打造，绝不采用全新风格。或者采用角色抠图：吉祥物单独出现在透明 PNG 上，供下游叠加使用——只保留姿势和接触关系的连贯性，不包含想法、文字或环境（references/cutout.md）。

这是一种可配置的统一风格，不是通用图像生成器。方法论保持不变；角色设定包和调色板则是可调参数——角色设定包也自带风格：每个设定包只采用一种风格，从内置风格库中选择（risо——颗粒状半色调、油墨图层错位、纸张纹理、一圈粗犷而边角柔和的轮廓线——以及 blueprint、woodcut、pixel、clay、manila、chalk、phosphor、enamel、gouache、felt、diorama、sketchbook、bricks、fizz、bloom 和 snes），也可以使用自定义风格文件。默认吉祥物是 Blot，一滴面无表情的油墨，采用 riso 风格。调色板可选用预设、用户自己的调色板文件，或从一种颜色派生而来。无论参数如何设置，作品都刻意不追求照片效果——唯一有意的例外是 bricks 风格，即玩具积木摄影风格——也不是徽标、企业信息图、正式的方框与菱形流程图风格或 UI 模型图。即使要求绘制流程图，也仍然意味着以设定包的风格呈现标注阶段——禁止正式风格是对视觉风格的限制，并不意味着拒绝“流程图”这个说法。

使用场景——为请求选择合适形式

用户想要什么	路径
为文章／帖子／新闻简报／URL 配图	步骤 0–7：先为来源确定路由（论点 → 覆盖范围：主图／主图+组图／组图／迷你漫画 — references/composition.md，“来源路由”），然后列出镜头清单（主图行 + 锚点），每个锚点生成一张图，再按放置位置穿插排布。
为单个概念生成一张图	步骤 1 的概念分支（如果想法不够明确，最多快速提问约 3 个问题），然后生成一张图。
惊喜／随机 — “surprise me”、“random”、“surprise me with art quote using bray”、“surprise me --autopick”	完整阅读 references/surprise.md：先执行步骤 0，然后处理角色 + 来源（忽略 defaultCharacter；* quote 会强制使用有引用出处的引言；否则约有 1/3 的概率抽中），构建 三个 安全候选项，通过交互式选择器或自动挑选最佳项（调度器优先使用 --autopick），然后根据已锁定的文案进行登记，再将步骤 3–7 作为一张图执行。交付文案 + 图片。海报标题默认关闭；迷你漫画仍会为每格添加标签。
一个序列 — 故事节拍、前后对比、失败→修复	如果整个过程发生在同一处，则使用一部迷你漫画（在 references/composition.md 中确定形状路由——由创意决定形状，目标位置绝不决定）。指定的流程图／流程图示／带标签的工作流属于带标签的阶段，不属于此行。
可追踪的结构 — “展示流程”、“按带标签的阶段呈现”、“给步骤加标签”、“逐步讲解阶段”、“绘制流程图”、“像那张工厂图一样”、“映射步骤”、“作为解说图”，或明确要求流程图／带标签的工作流／流程图示	使用解说图登记流程（references/composition.md，“选择图表类型”和“解说图登记流程”）：在当前风格中手工构建带标签的阶段／流程／扇出／时间线／循环／堆栈／系统切片，并让吉祥物成为其中发挥作用的一部分。指定流程图／带标签的工作流／流程图示时，应在该套件的风格中锁定为带标签的阶段——禁止正式流程图是风格限制（不使用 Visio、标题／图例／网格），而不是拒绝“流程图”这一说法。带标签的阶段是解说图中的一种结构类型，并非新的登记流程或风格——提示词编写前，先根据当前角色为其确定套件方案。最适合论点本身就是具名管线、配方或分阶段流程的单元；绝不能将其作为所有解说图的默认选择。
适合发布到 X 帖子／文章正文的社交媒体配图	16:9（明确需要正方形时可用 1:1），采用醒目的 ink-punch 风格；如果已配置或用户要求，则添加带有 x 账号名的水印。
X Article 横幅／主图	用户要求 X Article 主图／横幅时，使用专属横幅格式：1536 × 640 px。通过常规 illo.py generate 图像流程编写提示词并生成图像，保持角色／物体比例正常、不失真，并留出适合裁切的留白。除非用户明确要求后期处理，否则不要手动合成或从其他图像重新拼接裁切内容来满足此需求。
博客／品牌／网站风格匹配的配图	使用具名或自定义调色板，或根据一种主色推导调色板（references/palettes.md）。
用户自己的吉祥物 — “make me a character”、“use our mascot”、“replace Blot”	使用角色构建器：完整阅读 references/character-builder.md 并从头到尾按其说明操作。
社区角色 — “what characters are available”、“install blip”、“install all characters”、“update mole”、“publish my character”	参阅 references/pack-sharing.md——引擎命令 packs list/show/install/update，包括 packs install --all；通过 GitHub PR 发布。
不同的风格 — “in blueprint”、“woodcut style”、“pixel version of blip”	风格随角色套件一起提供：通过 references/character-builder.md 中的“风格变体”构建风格变体套件。
可供挑选的选项，或“哪个模型最好”	步骤 5b：使用 --count 生成多个变体，或循环使用多个模型 → 通过 gallery 展示并给出推荐。
修复现有图像（多余标题、重新上色、吉祥物装饰性过强）	在 references/prompt-recipe.md 中编辑提示词，并通过 --ref 传入图像。
角色抠图／透明 PNG／叠加贴纸 — “just the mascot”、“no background”、“paste on something else”	使用抠图登记流程（完整阅读 references/cutout.md），根据 references/prompt-recipe.md 中的“抠图变体”编写提示词，使用 --cutout 和 --aspect 1:1 生成。OpenRouter 抠图默认使用 GPT Image 2（而不是 Grok）。不适用于解释创意——如果请求需要场景，请改用编辑类流程。
吉祥物动画待机图／机器人头像／循环 GIF	使用抠图登记流程以及 references/cutout.md 中的“待机循环／机器人头像”：使用 --cutout，并将角色设定表作为 --ref，生成一张透明的 1:1 抠图，然后在该 PNG 上以编程方式添加动作。

先决条件

引擎（scripts/illo.py，使用 Python 标准库，无需安装）通过 三种引擎后端和 两种 Agent 端传输方式之一进行渲染；唯一的硬性要求是 python3 和网络访问。Grok Bot（Cursor 的 Grok Bot / Grok 桌面助手）是一种 Agent 端传输方式：使用其内置的 Grok 图像工具，而不是 illo.py generate，除非用户配置明确选择了某个引擎后端。Muse（Meta 的个人助手 Blip）是另一种 Agent 端传输方式：当 你 是 Blip 时，根据此技能构建 illo 提示词，并调用你的原生图像生成工具，同时附上当前角色表作为参考。其他恰好提供某种图像 API 的 Agent 不得使用这两种原生方式——Agent 必须能够调用自己的内置图像工具，并且名称必须列在上文中。

运行引擎——在每个代码块中内联设置 $SKILL_DIR。 以下每条引擎命令的形式都是 python3 "$SKILL_DIR/scripts/illo.py" …。将 SKILL_DIR 设为加载此 SKILL.md 的目录的绝对路径（该目录包含 scripts/illo.py 和 assets/），并在使用它的同一个命令块中设置——shell 状态不会在不同命令运行之间保留，因此在前一个代码块中设置的值到下一个代码块时就会消失。如果运行环境没有提供该路径，请找到已安装的 scripts/illo.py 并使用其父目录；如果两种方式都无法确定，就停止，不要猜测工作目录。引擎会自行定位其捆绑资源，因此 $SKILL_DIR 只需设置为足以启动 illo.py 并让 --ref 指向捆绑角色表的路径即可。

编写代码块时要确保折叠安全——某些宿主（已观察到 Codex）会把围栏代码块折叠成一行，将换行符变为空格。请以 ; 结束赋值语句（SKILL_DIR="…";——如果没有分号，折叠后的 SKILL_DIR="…" python3 "$SKILL_DIR/…" 会成为环境变量前缀，$SKILL_DIR 会在赋值生效之前展开为空值，导致路径变成 /scripts/illo.py）。不要在赋值语句或命令行上添加注释（折叠后，# 会注释掉该行余下内容，命令会悄无声息地消失），并让每次调用都保持在一行（折叠后的 \ 续行符会引入多余参数）。值错误或未设置会导致 doctor（工作流步骤 0）明确失败（can't open file …/scripts/illo.py）——这说明应修正路径，而不是技能本身有问题。

• Codex 后端（Codex 订阅用户免费）。 如果宿主环境中有可用的 Codex CLI——已安装、已执行 codex login，且启用了 image_generation 功能——illo 就能通过用户的 Codex 订阅生成图像，无需按张付费（使用其 Codex 配额）。无需 API 密钥，也无需令牌：illo 只会调用用户自己的 CLI。会检测是否可用， 而不是默认假设；自动使用 gpt-image-2；Windows/WSL 不支持。
• Grok CLI 后端（Grok/xAI 订阅用户免费）。 如果宿主环境中有可用的 Grok CLI——已安装并已执行 grok login——illo 就能通过 grok -p（无头模式） 使用用户的 Grok 订阅生成图像，消耗其 Grok 配额。与 Codex 一样，采用无需环境变量、无需令牌的子进程设计。Grok 返回的 JPEG 不包含 Alpha 通道，因此无法制作透明抠图——这类请求会自动回退到支持抠图的后端。图像工具不提供模型选择器。
• Grok Bot 原生传输（Agent 侧，Grok Bot 用户免费）。 如果 你是 Grok Bot——具体来说，是 Cursor 的 Grok Bot，或内置 Grok 图像工具的 Grok 桌面 助手——请构建 illo 提示词，并调用该工具，将当前角色的设定图作为参考图。不要要求使用 Grok CLI、Codex CLI 或 OpenRouter 密钥；也不要因为缺少引擎后端就运行 init。这不是通用的“宿主图像 API”规则，也不是 illo.py --backend 的取值。
• OpenRouter 后端（付费，可直接使用或作为显式回退）。 需要在用户的配置文件中提供 OpenRouter API 密钥——这是唯一的凭据渠道——由用户运行 init 一次性写入（权限模式为 600）。引擎绝不会从环境变量读取密钥，也不接受将密钥作为命令行参数。没有订阅 CLI 的宿主环境可以直接选择此引擎路径。 Codex/Grok CLI 渲染失败后，不会自动产生费用：付费回退需要指定 --allow-paid-fallback。支持选择模型 （--model）。

后端/传输模式概要（解析与优先级、CLI 要求、Grok Bot 原生路径、内置图像工具的自动选择、配额与费用、抠图限制、Windows/WSL、回退）：选择或说明后端前，请完整阅读 references/backends.md——具体机制只在该文件中说明。

设置由用户自行完成（绝不亲自输入密钥）

输入 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 后会通过它读取配置；未安装时，内置的精简解析器仍可读取扁平键——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 — riso，默认视觉风格：Risograph 技法、线条语言、纸张/油墨，以及明确的注意事项。
• references/styles/<name>.md — 其余视觉风格库（blueprint、woodcut、pixel、clay、manila、chalk、phosphor、enamel、gouache、felt、diorama、sketchbook、bricks、fizz、bloom、snes），由角色包使用。生成前，请完整阅读当前角色的风格文件。
• references/character.md — 角色规则（承重测试、反复杂度护栏、明度遵循调色板、交互模型——由每个角色包声明，或根据已锁定的设计和参考表保守推导）、默认角色 Blot，以及自定义包格式。开始任何角色相关工作前请阅读。
• references/character-builder.md — 设计并安装用户自有吉祥物的引导流程。创建或替换角色前请完整阅读。
• references/pack-sharing.md — 从社区仓库安装角色，以及通过 PR 发布角色包。收到安装/发布请求前请阅读。
• references/palettes.md — 命名预设、默认解析、自定义调色板，以及从一种颜色推导调色板的算法。选择或推导调色板前请完整阅读。
• references/composition.md — 两种构图形式（编辑式场景 / 解释型图表）、图表类型选择器、解释型图表的结构类型与预算（包括带标签的阶段、箭头注释及其角色包解法）、场景安排、将想法转化为动作、解剖结构-动作可行性检查（渲染前根据角色的交互模型验证接触关系图）、禁止重复使用构图的规则，以及镜头列表格式。
• references/cutout.md — 剪贴图形式：透明合成素材、接触连续性、姿势词汇表和生成标志。收到任何剪贴图请求前请完整阅读。
• references/surprise.md — 惊喜 / 随机模式：预检优先、范围解析、随机角色、来源多样性 + 三个候选说法（可选对来源模式进行并行验证）、交互式选择器或 --autopick / 自动挑选最佳项、刷新时完整重抽、锁定说法后再确定形式、说法栏 + 含义栏、多来源引文验证、提供前的安全检查、无头模式约定。收到任何惊喜/随机请求前请完整阅读。
• references/backends.md — 三后端图像引擎及 Grok Bot 原生传输：引擎后端的解析方式（优先级为 Codex > Grok > OpenRouter，以及自我识别规则）、Grok Bot 绕过 illo.py generate 的情况、Codex/Grok CLI 要求、优先以产物判定成功、内置图像工具会自动启用（无需选择模型）、配额与收费的区别、Grok 不支持剪贴图的限制、Windows/WSL，以及选择启用的付费回退方案。选择或说明后端前请阅读。
• references/models.md — 模型列表（仅限 OpenRouter 后端）：友好名称 → OpenRouter id 对照表、特性、宽高比注意事项、404/回退处理。传入任何 --model 前请阅读。
• references/prompt-recipe.md — 生成提示词模板和编辑/重新着色提示词。
• references/quality-bar.md — 生成后的检查清单和迭代规则。交付前请阅读。

assets/character-reference.webp 是默认角色的标准模型表——一致性基准（由下文的引擎使用）；自定义包需提供自己的模型表。不会随附风格校准示例——每个风格文件都通过 URL 链接到自己的示例（需要时再获取）：研究线条密度、负空间和强调色的克制使用。切勿照搬示例的构图——请为当前作品创造新颖的隐喻。

工作流

0. 预检

生成前，确认引擎已就绪：

SKILL_DIR="<path to this skill>";
python3 "$SKILL_DIR/scripts/illo.py" doctor

单独运行 illo.py 调用，绝不要与 && 链接，这样显示的退出代码本身就是就绪信号（0 = 就绪）：链式命令中相邻命令的失败会让健康检查显示为错误。

它会报告 Python、配置路径、解析后的模型／调色板默认值、是否存在自定义角色包或自定义调色板文件、Codex/Grok CLI 检测结果及解析后的后端／传输方式，以及是否找到 OpenRouter 密钥（不会泄露密钥）；退出代码为 0 = 解析后的后端已就绪。仅安装 OpenRouter（没有订阅 CLI）时仍会返回退出代码 0——就绪状态取决于解析后的后端，而不是硬编码的密钥检查（references/backends.md）。

Grok Bot 原生路径（Agent 侧）。 如果你是 Grok Bot（Cursor 的 Grok Bot／内置 Grok 图像工具的 Grok 桌面助手），且用户没有明确选择 backend: openrouter、backend: codex 或 backend: grok，请先初始化 Agent 侧传输方式，再依赖 doctor 的结果：

SKILL_DIR="<path to this skill>";
python3 "$SKILL_DIR/scripts/illo.py" init --backend grok-bot --no-key

然后照常运行 doctor：在此路径下，退出代码为 0 表示已就绪。使用 backend: grok-bot 时，缺少 Codex CLI、Grok CLI 或 OpenRouter 密钥并不算失败；资产损坏、自定义包无法读取、调色板格式错误或 SKILL_DIR 错误仍会导致失败，必须在渲染前修复。第 5 步中，调用 Grok Bot 内置的 Grok 图像工具，并提供当前模型表参考来生成图像。此路径仅适用于 Grok Bot 自带的 Grok 图像工具；使用其他无关图像工具的 Agent 必须使用下方的引擎后端。

Grok Bot 快捷路径：当后端未设置／为自动时，运行一次 init --backend grok-bot --no-key；运行 doctor 检查资产／配置／角色包；照常使用 packs 命令（安装后运行 packs install --all，以便将社区角色保存到本地）；阅读相同的参考资料；构建相同的提示词；然后调用 Grok Bot 内置的 Grok 图像工具，并提供当前角色参考。除非用户明确希望使用 OpenRouter 或将其他引擎后端设为默认值，否则跳过 OpenRouter 的 illo.py init；除非用户明确选择了引擎后端，否则跳过 illo.py generate。

Muse 原生路径（Agent 侧）。 如果你是 Blip（Meta 的个人助手 Muse），且用户没有明确选择引擎后端（backend: openrouter、backend: codex 或 backend: grok），请先初始化 Agent 侧传输方式，再依赖 doctor 的结果：

SKILL_DIR="<path to this skill>";
python3 "$SKILL_DIR/scripts/illo.py" init --backend muse-native --no-key

然后照常运行 doctor：在此路径下，退出代码为 0 表示已就绪。使用 backend: muse-native 时，缺少 Codex CLI、Grok CLI 或 OpenRouter 密钥并不算失败；资产损坏、自定义包无法读取、调色板格式错误或 SKILL_DIR 错误仍会导致失败，必须在渲染前修复。第 5 步中，调用原生图像生成工具，并提供当前模型表参考来生成图像。与 Grok Bot 不同，此路径可以生成抠图：在角色包的色度屏幕上渲染，然后运行 illo.py keyout（参见 references/cutout.md）。此路径仅适用于 Blip 自带的原生图像工具；使用其他无关图像工具的 Agent 必须使用引擎后端。

Muse 快捷路径：当后端未设置／为自动时，运行一次 init --backend muse-native --no-key；运行 doctor 检查资产／配置／角色包；照常使用 packs 命令；阅读相同的参考资料；构建相同的提示词；然后调用原生图像工具，并提供当前角色参考。除非用户明确选择了引擎后端，否则跳过 illo.py generate——使用原生方式渲染时，通过 illo.py record 记录结果（抠图则使用 keyout），以便将其加入本次运行的 manifest.jsonl 和图库。 配置迁移 — 通过交互式方式选择后端。 当你准备使用 illo.py generate 时，如果 doctor 报告 backend: NEEDS CHOICE（或 generate 硬性停止并提示配置“已过时”），则说明该用户的配置早于后端选择功能——他们使用的是较旧版本，且从未看到过订阅 CLI 选项。不要擅自替他们选择。使用平台的阻塞式提问功能（Claude Code 中为 AskUserQuestion，其他平台使用等效功能；如果宿主平台没有此功能，例如纯聊天会话，则用简洁消息提出同一个选项并等待回复，绝不能擅自选择），询问用户并给出五个选项：“illo 现在支持图像后端/传输方式——你想选哪个？”——Codex（免费，使用你的 Codex 订阅）、Grok CLI（免费，使用你的 Grok 订阅；不支持透明抠图）、Grok Bot（Agent 侧原生工具；仅当你是 Grok Bot 时使用）、Muse（Agent 侧原生工具；仅当你是 Blip，即 Meta 的个人助手时使用），以及 OpenRouter（选择模型：Grok Imagine、Nano Banana、GPT Image 等）。保存用户的选择，但不要改动任何现有键： python3 "$SKILL_DIR/scripts/illo.py" init --backend <codex|grok|grok-bot|muse-native|openrouter> --no-key， 然后继续。全新安装（完全没有配置）属于常规引导，不属于此迁移——不会触发此流程。

如果你是订阅 CLI Agent，优先使用自己的 CLI。 引擎的自动默认值读取的是宿主平台能力（Codex > Grok > OpenRouter；它无法判断是哪个 Agent 调用了它）——但你知道自己是哪种 Agent。因此，如果你是订阅 CLI Agent，且自己的 CLI 在此宿主平台上可用，那么生成非抠图图像时，应在 generate 中添加自己的后端标志：Grok CLI Agent 添加 --backend grok，Codex Agent 添加 --backend codex。这样即使宿主平台也有 Codex，在 Grok CLI 中也能确保“使用 Grok 生成”，而无需在引擎中运行时探测。抠图不受此规则影响（Grok 无法生成抠图——会自动回退）。用户配置中的 backend: 优先级最高。解析与优先级机制详见：references/backends.md。

对于 Grok Bot，等效的身份识别规则要在 generate 之前执行：当后端未设置或为自动时，使用 init --backend grok-bot --no-key 保存 backend: grok-bot，并使用上文提到的 Grok 原生图像工具路径。如果用户明确配置或请求了引擎后端，则应遵从该选择，而不是擅自切换到 Grok Bot 原生工具。

对于 Blip（Muse），适用相同规则：当后端未设置或为自动时，使用 init --backend muse-native --no-key 保存 backend: muse-native，并使用原生图像工具路径。如果用户明确配置或请求了引擎后端，则应遵从该选择，而不是擅自切换到 Muse 原生工具。 下结论说密钥缺失前，先查看打印出的配置路径：在 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，绝不会接触密钥），然后向用户提供两种等效的一次性选项，让他们在 运行 Agent 的机器上执行（那台主机属于他们——他们在那里安装了 Agent）：运行 python3 <resolved absolute $SKILL_DIR>/scripts/illo.py init（隐藏 提示），或打开 ~/.config/illo/config.yaml 并填写 apiKey: 行。密钥绝不能经由聊天传递：绝不要在消息中向用户索要密钥；如果用户还是粘贴了密钥，请勿使用——告知他们前往 openrouter.ai 撤销该密钥，并在主机上设置一个新的（粘贴的密钥此时已留存在聊天记录和平台服务器中）。绝不要自行将环境变量或其他存储中的密钥复制到配置中——只有用户可以写入该行——有一个范围明确的例外：临时云工作区（Claude Code web、Codex cloud、CI），用户通过平台的机密信息机制配置了 OPENROUTER_API_KEY。这一配置本身就是用户有意授予的、限定于工作区的许可，而且没有可供 init 使用的交互式提示或持久主目录——因此，在这种情况下，从工作区机密信息初始化配置一次（使用 README.md 中“云端与 CI”的单行命令）。在个人机器上，环境中存在变量并不能证明用户有此意图（它可能属于其他工具）——规则不变： 绝不复制。

可选的插件新旧状态提示（预检，先征得同意）。 如果本次运行将使用已安装的社区插件进行渲染（doctor 会列出插件；安装时会附带 .version 标记），可以选择检查其新旧状态： python3 "$SKILL_DIR/scripts/illo.py" packs list 会标记过期的安装 （[installed 1.0.0 — 1.0.2 available]）。检查可以在此处进行，但提示要等到确定当前使用的插件后再发出——也就是 Step 2 确定角色后（或惊喜模式抽取角色后），并且紧接着使用该插件进行的首次渲染之前。如果确定的插件已过期，请通过平台的阻塞式提问功能（与上文配置迁移相同）提示用户是否在渲染前更新；只有用户明确回答是，才运行 packs update <name>（更新会覆盖本地副本；手动编辑警告及 --as 替代方案见 references/pack-sharing.md）。绝不要静默更新，也绝不要因此阻塞流程：用户回答“否”、主机离线、注册表出错或无头／调度程序运行（例如惊喜模式下的 --autopick）时，都继续使用固定版本的副本——没有声明 ## Interaction model 的插件仍可通过保守推导安全地进行规划（references/character.md）。如果未涉及已安装的社区插件，则完全跳过检查。

1. 阅读输入——并简要澄清一个模糊概念

三种输入，处理方式各不相同：

• 惊喜 / 随机（“给我点惊喜”“随机”“用 bray 来创作一幅惊喜艺术作品”“给我点惊喜 --autopick”及类似说法）——这是要求你构思并绘制，而不是提供一个既定论点。停下来并完整阅读 references/surprise.md，先执行 Step 0，然后根据其中的说明确定角色和出处（忽略 defaultCharacter；如果用户没有指定角色，就随机选择），构思三个格言候选项，并通过选择器或 auto-pick-best 确定其中一个，根据选定的格言选择语域，然后继续执行 Steps 3–7，绘制为一张图——在这次绘制流程中跳过 Steps 0 和 2，因为预检和素材包已完成。不要进入下方的模糊概念问答流程。已经明确提出具体想法的提示词（“将‘你就是瓶颈’画出来”）不属于惊喜模式，即使其中也说了“给我点惊喜”。

• URL / 文章 / 粘贴内容 / 长帖都自带上下文——但绝不要根据最生动的细节直接创作。先进行路由判断（references/composition.md 中的“Source routing”）：对来源的形式和体裁进行分类，推断所需作品的任务（这张图需要为受众完成什么），将这个任务与来源中最适合绘制的机制区分开来，用一句话锁定核心论点（主视觉要锁定来源 / 作品的任务，而不是最醒目的证据——体裁规范会说明每种体裁应突出什么），然后先选择覆盖方式——主视觉、主视觉 + 分节组图（完整呈现文章的任务）、组图、迷你漫画或镜头列表。组图需要明确放置位置：简短来源（一条推文、一个概念）绝不生成组图——其多节拍形式应为迷你漫画。提取承重关键时刻——即能引发判断、循环、输入→输出、前后对比或陷阱的少数几个位置——绝不是每段配一张图。文本已经说明了主题，所以不要盘问用户，只有一种情况例外：具有多个实质性节拍的来源（长篇文章、事后复盘、多论点发布）需要先问一个覆盖方式问题，再投入多图制作——除非用户已经指定了覆盖方式。从多节拍来源中挑出单张图，就是一张主视觉，交付时要明确说明这一点——不能说它覆盖了整篇内容。

• 单一概念或一句话（例如“将‘你就是瓶颈’画出来”）通常没有充分描述画面。最多问**约 3 个简短问题——只问那些会改变输出的问题——然后开始创作。**可询问：

  • 核心观点（读者应该得出什么结论？），
  • 用途（博客 / 幻灯片 / X 帖子 / X 文章正文 / X 文章横幅 → 决定配色、纵横比、像素规格标准化和水印），
  • 形式：一张图（默认）、迷你漫画（在一张图中绘制 2–4 个分格——仅当想法本身会随着阶段推进时使用），或几张独立图片；以及必须包含的元素或限制条件。形式应由想法决定，而不是由用途决定（references/composition.md）。

  只进行一轮简短提问，然后继续。**如果用户已经提供了足够信息、说了“直接做” / “单张图”，或根据上下文答案显而易见，就完全跳过提问。**不要因为提问而阻碍明确的请求。

2. 确定角色

**惊喜／随机模式：**跳过此步骤——角色已在 references/surprise.md 中确定（指定角色包，或从已安装的角色包和 Blot 中随机选择； 绝不使用 defaultCharacter）。继续执行第 3 步及后续步骤。

已安装的角色包位于 ${XDG_CONFIG_HOME:-~/.config}/illo/characters/ 下（格式和位置详情见 references/character.md）；doctor 会列出 已安装的角色包。用户可以保留多个角色包，并在每次运行时选择。按以下顺序匹配， 最先匹配的优先：

1. 明确请求 —“使用 ”“以 的身份”：使用该角色包（如果按名称 指定的是随附默认角色，则使用 blot）。如果词语与任何角色包名称都不匹配，则通过 近似匹配来确定：将其与每个已安装角色包的 Aliases: 行和主体进行比对 （character.md 的首行和 Locked design Body）——doctor 会打印名称 和别名，因此通常无需读取文件——并与目录中的 description（packs list） 进行比对。因此，“使用 ox”会找到副标题中提到牛的角色包（例如 yoke）。 如果有一个明确匹配项，则使用它并说出其名称；如果有多个，则询问用户选择哪一个； 如果没有，则说明这一点后再继续匹配。
2. 配置默认值 — 如果用户配置中设置了 defaultCharacter，则使用它。
3. 随附默认角色 — Blot（规格见 references/character.md，角色设定图见 assets/character-reference.webp）。

确定角色后，读取该角色包的 character.md，并在所有原本会使用默认角色相关内容的地方， 使用其中的提示词规格、价值规则、可选的 Cutout chroma: 兼容性偏好，以及 reference.png。

将一组文章改用新角色时——尤其是在尝试效果不佳后，或处理技术／平台类文章时—— 请在规划或渲染前完整阅读 references/article-set-character-reroute.md。开始渲染前，先按其中的要求进行可读性预检。

如果用户想要创建新角色，则使用角色构建器 （references/character-builder.md）；如果用户想要使用别人的角色，则从社区仓库 安装角色包（references/pack-sharing.md）。无论哪种情况，都先安装，再继续此处步骤。

3. 规划（镜头列表）——用户要求规划或需要多张图片时

如果用户想要规划（“应该在哪里配图”“镜头列表”），则在生成前先输出镜头列表。每张 图片需包含：放置位置、一个核心理念、图稿的用途、风格基调（除非该行符合说明性图解 的门槛，否则使用编辑风格）、场景布置（或结构类型——根据 references/composition.md 中的“Pick the diagram type”进行选择）、吉祥物在做什么、配色，以及文字层级—— 如果图稿需要，则说明主要阅读内容／标题，再加上符合 references/composition.md 中各风格基调字数限制的简短辅助标签／标注。根据锚点数量 决定图片数量（分段规则和禁止凑数的规则见 references/composition.md）。如果文章某一 段内容在同一处逐步推进多个阶段，则规划一张迷你漫画，而不是多张图片——迷你漫画 与单独图片的选择规则见 references/composition.md。

对于改用新角色的一组文章，在任何渲染前添加 references/article-set-character-reroute.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，并依照其中的规则确定——该文件包含解析顺序（明确请求，然后通过用户的调色板文件确定目标提示，再到配置默认值，最后使用 house ink-punch）、命名预设、自定义调色板，以及从单一颜色推导调色板的算法。最终必须给出具体的十六进制值；当套件风格不是 riso 时，还要按照该风格的调色板映射处理这些值。

5. 生成——严格遵循参考图，每张图片只用一个比喻

剪纸分支。 当请求路由到剪纸类别时，先完整阅读 references/cutout.md——其中涵盖了针对后端的透明度处理（默认使用 Codex 原生 alpha；OpenRouter 或显式指定 --chroma 时使用色度兼容模式）、锁定对齐的剪影（墨层不得偏移）、--cutout / --aspect 1:1、OpenRouter --image-config，以及清单中的 cutout_alpha 说明。根据 references/prompt-recipe.md 中的 “Cutout variant” 构建提示词——不要使用编辑插画模板，并省略手动的 BACKGROUND: / 输出格式说明；引擎会附加实际运行后端所需的约定。只有在强制进行兼容模式重试时才传入 --chroma。仅将角色模型设定图用作 --ref（不添加编辑插画风格锚点，也不加水印）。根据 references/quality-bar.md 中的剪纸章节进行 QA。跳过编辑插画的镜头列表 / 主旨步骤。

编辑插画和说明图。 当锁定类型标记为分阶段时，在编写提示词之前，按照 references/composition.md 中的 “Labeled stages — skeleton, then pack-solve” 执行套件求解准备步骤——阶段列表 → 操作阶段 → 接触图 → 绑定；不要臆造外观。根据 references/prompt-recipe.md 为每张图片编写完整提示词（场景 + 结构 + 信息传达层级 + 风格 + 当前角色规格 + 已解析的调色板十六进制值 + 对应类别的文本预算），将提示词写入文件，然后进行渲染。每次都要将当前角色的模型设定图作为 --ref 传入——这种参考图条件控制能让吉祥物保持符合设定；风格和调色板来自提示词，因此两者都可以替换。套件的设定图是在其自身风格下制作的，因此设定图和风格始终匹配——不要混用不同风格的参考图。（在 Hermes Agent 下，首次使用 --ref 之前必须已完成上述资源修复预检——损坏的设定图会导致每次渲染都基于错误内容进行条件控制。）

Grok Bot 原生渲染。 如果你是 Grok Bot，且适用步骤 0 中的原生路径，不要运行 illo.py generate。使用相同的完整提示词配方、相同的宽高比、相同的角色锁定规则，以及针对系列图像的相同风格锚点规则，并调用 Grok Bot 内置的 Grok 图像工具。将当前角色的模型设定图作为参考图附加（Blot 使用 assets/character-reference.webp，或使用套件的 reference.png）；对于系列中的后续图片，也要附加已接受的风格锚点图。要求工具保存 / 返回生成的文件，并将保存的路径视为引擎 JSON 中 .path 的等价项，用于 QA 和交付。Grok Bot 的图像工具与 Grok CLI 传输使用的是同一类 Grok 图像模型：没有模型选择器，不通过 OpenRouter 计费，也不支持 alpha 通道。透明剪纸不得使用此路径；应改用支持剪纸的引擎后端，或暂停并要求配置该后端。 Muse 原生渲染。 如果你是 Blip（Meta 的个人助手 Muse），且适用 Step 0 中的原生路径，请勿运行 illo.py generate。使用相同的完整提示词配方、相同的纵横比、相同的角色锁定规则，以及为系列设定的相同风格锚点规则，并调用你的原生图像生成工具。将当前角色的模型图纸作为参考图附加（Blot 使用 assets/character-reference.webp，或使用素材包的 reference.png）；对于系列中的后续图像，还要附加已接受的风格锚点图像。一次响应中最多可批量调用 4 次原生图像生成；超出此数量时，请在后续响应中继续。将每个返回的文件保存到运行目录，然后使用 illo.py record 记录（参见其用法）；该命令会追加一条带有标签和提示词的 muse-native 清单记录，使其与引擎渲染一样出现在图库中。将记录的路径视为与引擎 JSON .path 等效，用于 QA 和交付。

与 Grok Bot 不同，此路径支持抠图：要求原生工具生成素材包指定的纯色抠像背景（素材包会指定 green 或 magenta），然后运行 illo.py keyout <screen.png> --chroma <green|magenta> --out <final.png>，生成透明 PNG；有关色键选择、QA 和不透明回退规则，请参阅 references/cutout.md。此路径没有模型选择器，也不会通过 OpenRouter 计费；--model 不适用。

内联设置 SKILL_DIR（参见先决条件），并将捆绑的图纸用作 REF；如果是自定义角色，则使用当前素材包的 reference.png。添加 --model <id>，可覆盖此图像的配置／默认模型（仅限 OpenRouter 后端）：

SKILL_DIR="<path to this skill>";
REF="$SKILL_DIR/assets/character-reference.webp";
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"

对于引擎渲染，illo.py generate 会为每张图像打印一行 JSON（{path, backend, model, id, cost, width, height, label, prompt}；backend 为 codex、grok 或 openrouter，model／id／cost 仅适用于 OpenRouter——由 CLI 提供服务的记录（Codex 或 Grok）中这些字段为 null。除非传入 --cost，否则 cost 为 null——gallery 会补填该值），并将同一条记录追加到 <out-dir>/manifest.jsonl。 读取 .path——它可能与 --out 不同：引擎会根据实际编码格式命名文件（某些模型返回 JPEG 字节，因此请求的 .png 会保存为 .jpg）。使用 .width/.height 检查是否在请求 16:9 时生成了正方形图像（需重新生成）。默认情况下，即使已配置 OpenRouter 密钥，Codex/Grok CLI 渲染失败也会停止。仅当用户明确批准按张付费重试时，才添加 --allow-paid-fallback。直接使用 --backend openrouter 渲染，以及有意将 Grok 抠图请求重定向的情况，仍是直接路径，无需此标志。 每张图像都要单独生成——绝不要把多个想法合并到一张画布中。默认纵横比为 16:9；方形社交媒体图像使用 1:1，竖版图像使用 9:16／4:5，X Article 横幅／主视觉使用 1536:640。X Article 横幅的目标尺寸为 1536 × 640 px。通过常规图像流程生成；不要手动合成，也不要用裁剪拼接重建场景来代替 illo 渲染。检查 .width/.height，仅在最终后期处理属于不改变形状的缩放／裁剪、能够保持正常比例和所有关键信息时进行。绝不要拉伸或压扁图像来强行达到精确尺寸。传入 --label，设置会显示在图库中的说明。

系列图像要像同一位艺术家创作。 对于任何多图系列，第一张通过完整质量标准的图像（如果是重定向文章系列中的主视觉，还必须通过 references/article-set-character-reroute.md 中的主题清晰度检查；绝不要以未经审核的渲染作为锚点——失败的锚点，例如背景颜色偏离调色板或隐喻难以理解，会导致整个系列都出现同样的问题）将成为该系列的风格锚点：在系列后续每张图像以及系列成员的每次重新生成中，都将其作为角色图纸之后的第二个 --ref 传入，确保整个系列的线条粗细、半色调密度以及扁平与立体的处理方式保持一致。单张图像也可用同样的方法锁定风格：将任意已完成的示例作为第二个 --ref 添加。 模型选择（仅适用于 OpenRouter 后端）。 --model 和配置项 model: 是仅适用于 OpenRouter的选项——在 Codex、Grok CLI、Grok Bot 原生后端和 Muse 原生后端中，图像模型会自动选择，--model 不适用（参见 references/backends.md）。使用 OpenRouter 时，传入任何 --model 之前（或用户用日常语言指定模型，或要求“最高质量”／“最便宜”时），请先完整阅读 references/models.md：其中包含友好名称 → OpenRouter ID 的映射、各模型特性、宽高比注意事项，以及 404／回退处理方式。选择顺序为 --model > 配置项 model > 内置默认值。

水印／署名（可选，默认关闭）。 此技能不提供默认水印——文本仅来自用户的 watermark 配置映射（从配置文件读取）或明确请求，因此安装者不会继承他人的账号名。优先级顺序、要追加的提示词行以及双次渲染注意事项，详见 references/prompt-recipe.md。

5b. 批量生成与比较（仅在有帮助时）

默认生成一张图。 仅当用户要求提供选项／进行比较，或作品足够重要、值得多生成几张时，才并行生成——并且先说明每张图的费用：Codex 后端会占用用户的 Codex 配额（不按图收费）；Grok CLI 或 Grok Bot 原生后端会占用用户的 Grok 配额；Muse 原生后端使用 Agent 内置的图像工具（不产生 OpenRouter 费用）；OpenRouter 后端则会从用户的 OpenRouter 账户扣费（通常每张图不到十美分，具体因模型而异）。少量生成（2–4 张）。使用引擎的基本操作协调循环：

newrun 会将新的运行目录（/tmp/illo/<runid>）输出到 RUN。将用户的原始请求（URL、粘贴的文本、概念）记录到 request.txt——图库会将其显示为来源信息，以便任何人都能了解此次运行的用途。将下方每条 generate 命令调整为实际路径，然后分别运行：

SKILL_DIR="<path to this skill>";
RUN=$(python3 "$SKILL_DIR/scripts/illo.py" newrun);
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 会将它们整合到一个页面，并显示每张图的标签、模型、尺寸、费用和可折叠提示词——提示词切换功能可让人清楚地比较概念变化（提示词就是变化项）。始终附上推荐意见来展示图库，不要只倾倒原始结果；在聊天会话中，应直接在聊天里展示带标签的候选图，而不是图库（交付路由见步骤 7）。多模型生成失败按单张处理（某个模型不可用，只会导致那一次渲染出错）；保留其余结果。

6. 质量检查与迭代

根据 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/）。然后说明：图片数量、使用的配色、哪些最出色、哪些可选——对于任何多图任务，还要提供放置示意图：每张图片占一行，写明文件名、用途（主视觉，或位于哪个章节之后）以及它传达的一个核心想法，让用户无需重新规划就能将每个文件放到合适的位置。按照本次会话实际支持的方式交付图片本身：

• 文件系统会话（IDE/终端 Agent——Claude Code、Codex、Cursor）：报告每个最终文件的绝对路径（引擎 JSON 的 .path 已是绝对路径），多图任务还要提供图库。磁盘上的文件本身就是原件——此处绝不要输出 [[as_document]]：它是 Hermes 网关标记，在其他运行环境中只是无意义的字面文本。如果运行环境支持在聊天中直接发送文件，请使用该功能。

• **Grok Bot 原生会话：**在聊天中以内嵌图片或附件的方式发送 Grok Bot 内置图片工具返回的文件，并在与引擎渲染使用 .path 相同的位置注明其保存路径。该工具返回的文件就是此传输方式下的原件；不要仅为取回文件就让用户配置 OpenRouter。

• **Muse 原生会话：**在聊天中通过 sandbox://workspace/... 链接发送原生图片工具返回的文件，并在与引擎渲染使用 .path 相同的位置注明其保存路径。使用 illo.py record（或对抠图使用 keyout）记录每张已发送的图片，确保本次运行的 manifest.jsonl 和图库内容完整。该工具返回的文件就是此传输方式下的原件；不要仅为取回文件就让用户配置 OpenRouter。

• 聊天会话（用户使用的是消息平台——通过 Telegram/Discord/WhatsApp 使用 Hermes，或任何会压缩媒体且无法打开本地文件的聊天平台）：仅提供路径并不算完整交付；图片必须发送到聊天中，而最终文件必须以原始文件的形式发送。平台以照片形式发送时会重新压缩图片——这正会破坏 risograph 颗粒、半调纹理、油墨层偏移和精细的手写字——因此最终文件应作为文档附件发送。在 Hermes 上，使用明确的 MEDIA: 附件标记标注每个最终文件——标记为 MEDIA: 后紧跟绝对路径，中间不加空格——并在同一条回复中加入字面指令 [[as_document]]。不要只提供最终文件的绝对路径：裸路径可能会以普通文本的形式显示给用户，而不会作为附件发送。

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

候选稿／选项轮次若能通过快速预览帮助用户判断，可以使用常规的内嵌照片发送方式——请注明“预览——原始文件稍后发送”；但最终文件绝不能以这种方式发送。聊天中不要发送 HTML 图库——用户无法轻松打开或托管它；请直接发送带有标签的最终文件，并附上文字说明和推荐意见；只有在用户明确要求便携式文件时，才使用 gallery --embed（生成单个独立文件），并通过 [[as_document]] 发送。

在聊天会话中发送最终回复前，请检查：

• 每个最终文件的路径都来自引擎 JSON 的 .path，而不是请求的 --out（实际扩展名可能不同）；
• 回复中每个最终文件都包含明确的 MEDIA:/absolute/path 附件标记；
• 除非明确仅发送预览，否则回复中包含 [[as_document]]；
• 交付内容中不包含被拒绝或重新生成的候选稿；
• 文字说明了创作内容——角色、配色、最出色的最终稿；对于系列作品，还要提供放置示意图（指出哪个文件是主视觉，哪个文件应放在相应章节之后）——且不包含实现细节。

输出规范

生成前的规划应简短具体。生成后，让图片自己说明一切——报告制作了什么、放在哪里，不要讲风格理论。标签要少而简短；图片中嵌入的文字越少，渲染就越可靠。

像亲自参与创作的人一样交流，不要复述这份文件。聊天时绝不要叙述工作流步骤或使用术语：doctor、preflight、provenance、register、saying bar、thesis、backend，或“doctor's green”。如需报告状态，就用日常说法，不要念步骤清单。在惊喜模式选中一个未命名角色时，用通俗英语介绍一次这个角色——角色包名称加上角色身份（“Inch, the chalk inchworm”）——然后展示台词并询问用户喜欢哪一个。绝不要只用名字报状态（“Inch.”），不要说“Still Inch”，也不要问“which one should draw?”。用户想听到的是结果——角色、台词／图片、制作了什么——而不是过程。