text-to-comic v2

Purpose

Turn user-provided text, photo descriptions, dialog, diary entries, poems, or knowledge notes into a visual deliverable that fits the material best:

• multi-panel comic
• picture-book spread
• infographic
• hybrid comic + diagram page

Preserve the strong parts of v1:

• automatic content-type judgment
• visual-form selection
• style recommendation
• character consistency
• scene continuity
• clean-image assembly

Add v2 structure so results are easier to control and revise:

• style presets from presets/styles.json
• structured panel plan from schemas/panel-plan.schema.json
• per-panel render task and retry record from schemas/render-task.schema.json
• panel-by-panel rendering instead of one-shot full-page generation

When to use

Use this skill when the user wants to:

• draw a story as a comic or picture book
• convert dialog into a 4-panel or short comic
• turn a concept or workflow into a visual infographic
• convert travel notes, diary entries, or photo notes into illustrated output
• iterate on style, storyboard, or single-panel fixes instead of regenerating everything

Do not use this skill when the task is mainly:

• pure text writing with no visual output
• exact imitation of a living artist's distinctive signature style
• direct reproduction of copyrighted third-party material

How it differs

• Not a one-shot image generator. It produces a storyboard and panel plan you can revise before rendering, and supports per-panel retry instead of redrawing the whole page.
• Not a style-cloning tool. It recommends from curated presets and refuses to imitate a living artist's signature style.
• Not a research tool. It visualizes material you already have; it does not go find or verify the source content for you.

Decision flow

1. Classify the input as one of:
   • narrative
   • dialog
   • knowledge
   • poetic
   • hybrid
2. Choose a visual form:
   • comic
   • picture-book
   • infographic
   • hybrid
3. Pick a default format:
   • 4-panel for short dialog or punchline-based requests
   • 6-panel to 8-panel for short narrative arcs
   • single for infographic or single illustration
   • webtoon for vertical, dramatic, mobile-first storytelling
4. Pick a style preset from presets/styles.json.
5. Build a compact panel plan.
6. Render panel by panel.
7. Validate, retry if needed, then assemble the final output.

Compatibility with v1

Keep the old experience as the default:

• If the user simply says "画成漫画" or gives a short story, still auto-select a reasonable format and style.
• Keep broad support for comics, picture books, and infographics.
• Keep the v1 ideas of storyboard confirmation, character cards, scene labels, clean-image suffixes, and PIL-based assembly.

New in v2:

• Use style IDs instead of only prose style names.
• Store storyboard as structured JSON.
• Track retries and fallbacks per panel.
• Make single-panel regeneration a first-class path.

Core workflow

1. Analyze the request

Identify:

• content type
• likely visual form
• target audience
• tone
• whether the request contains a stable protagonist, multiple scenes, or mainly conceptual information

If the task is obvious, present a compact plan and continue. Ask the user to confirm before rendering when any of the following is true:

• the content could reasonably become more than one visual form
• the style choice materially changes tone
• the story needs more than 8 panels
• the request contains private or sensitive photo material
• the user supplied copyrighted third-party source text that may need summarization first

2. Create the story/panel plan

Represent the visual plan with the schema in schemas/panel-plan.schema.json.

Requirements:

• one key beat per panel
• panel count should match narrative complexity
• the last panel should carry payoff, twist, conclusion, or CTA
• keep dialog short enough to remain readable after layout
• if scenes change, make transitions legible

For infographic mode:

• use visual_form = infographic
• use format = single
• still produce a panels array, usually with one major page and multiple structured sections inside the scene/action/must_include fields

3. Load or create the character bible

Two paths:

a. Default protagonist asset（默认路径）

If the user does not name or describe a protagonist, load the shipped character card before storyboarding:

• read characters/protagonist.md (default: black short hair, round glasses, slim young woman)
• inject its visual anchors into every panel prompt (see step 4), so the protagonist stays consistent across panels and across sessions
• never modify the default card; it is a shipped asset
• characters/protagonist-ref.png is an optional reference sheet; use it only when the host image tool accepts reference images, otherwise rely on the text anchors alone

b. Custom protagonist（用户指定主角）

If the user names or describes a protagonist, build a compact character bible instead and reuse it in every panel. Optionally save it as characters/custom-<slug>.md for the session — do not overwrite characters/protagonist.md.

Minimum character anchors:

• age/gender presentation when relevant
• hair
• face shape
• eyewear if any
• outfit
• accent color
• body build or silhouette
• vibe/expression

Keep these anchors stable across all panels.

4. Select and compile style preset

Use presets/styles.json as the source of truth for supported styles.

Each render prompt should combine:

• style positive template
• character-bible summary
• panel scene
• panel action
• shot type
• emotion
• must-include list
• avoid list
• global clean-image suffix

If the user gives a reference style image or a very specific style direction:

• preserve the selected style_id
• add a short reference-derived modifier instead of replacing the whole preset
• do not promise exact style cloning

5. Render panel by panel

Do not render the full page in one shot unless the request is explicitly a single illustration or infographic.

For comics or picture books:

• generate each panel independently
• keep output paths and retry records separate
• prefer clean images without embedded panel numbering
• if in-image text is unavoidable, keep it short and in English for image generation reliability
• add Chinese captions, narration, or labels during assembly when possible

6. Validate each panel

Validate against these priorities:

• character consistency
• scene continuity
• clean image without watermark/signature/panel numbering
• readable composition
• dialog within text_budget
• no obviously broken face or limb rendering

If a panel fails validation, retry with a bounded mutation ladder.

7. Retry policy

Use schemas/render-task.schema.json for retry bookkeeping.

Retry ladder:

1. shorten dialog or move text out of the image
2. simplify background and reduce secondary props
3. switch to a more stable shot such as medium
4. reduce side characters
5. fall back to a more stable style preset when appropriate

Stop conditions:

• default maximum 2 retries per panel unless the user explicitly wants more
• if the panel still fails after fallback, return the best valid storyboard plus the strongest attempt rather than silently looping

8. Assemble final output

Assembly defaults:

• 4-panel: 2x2 grid
• 6-panel or 8-panel: balanced grid with consistent gutters
• webtoon: vertical stack
• single: single page or single image

Assembly rules preserved from v1:

• crop to target ratio before final resize
• avoid panel numbering inside generated images
• keep a clean margin and readable caption area
• use warm off-white backgrounds for comic boards unless the chosen style clearly calls for another background

Hard constraints

Character consistency

If the story has a main character, every panel should clearly look like the same person. Reuse the same core descriptors and avoid drifting outfit, hair, face shape, or accent color.

Language separation

Prefer:

• English for minimal in-image text if generation quality depends on it
• Chinese for captions, narration, or post-assembly overlay

If the user explicitly wants all-Chinese bubbles, try it, but still favor readability and brevity.

Chinese dialogue and layout (中文对白与排版约束)

When the target language is Chinese (zh-CN), enforce these extra readability rules on top of text_budget. These are document-level guidance for planning and assembly; the JSON schemas are unchanged.

对白与旁白的字数上限（基于中文排版可读性）：

• 单个对话气泡：建议 ≤ 16 字（含中文标点占位，超出则拆句，不放第二行硬塞）
• 整格内所有对白合计：建议 ≤ 40 字（含标点）
• caption / 旁白单格：建议 ≤ 25 字（含标点）
• 上述字数按"每个全角字符占 1 字"计数（含标点）；若必须放入英文、数字或拼音，按 1 个半角字符 ≈ 0.6 字折算占用，避免超限

中文标点规范：

• 对话内一律使用中文标点：逗号「，」、句号「。」、问号「？」、感叹号「！」；不用半角 , . ? !
• 省略号用中文「……」；引号内对话用「」或“”；破折号用「——」
• 不使用连排标点（如 。。 ！！）；标点占位会影响字数预算

气泡内的排版建议：

• 单气泡内不换行过多：短句优先（一句一个停顿）
• 整格对白超 40 字时，拆到多格 / 多气泡，或用旁白承接，绝不让一格塞满小字
• 心情、环境等"可画出来"的信息不要写进对白，留给画面

竖排文字场景：

• 默认对白用横排（现代中文阅读习惯 + 生图可读性）
• 仅在标题、古风 / 竖排叙事、或用户明确要求时使用竖排；竖排时每列 ≤ 12 字，气泡按列排布，拼版时再叠文字
• 生图阶段文字不可控，竖排文字一律在拼版层处理，不在格内依赖 AI 直出

拼版时中文标题区建议：

• 若作品有中文标题，拼版时预留独立标题区（顶部标题条或封面区），不在第一格内直接画字
• 中文标题建议 ≤ 12 字；副标题 ≤ 20 字
• 标题区需匹配正文字体族（同一套 CJK 字体），避免系统字体缺字（如宋体 / 黑体未覆盖的生僻字）

Scene continuity

Use clear indoor/outdoor/street/home/office/etc. tags in planning when scene continuity matters. Add a transition panel if a major scene jump would feel abrupt.

Clean image rule

Use a clean-image suffix equivalent to:

• no border
• no panel frame
• no watermark
• no AI signature
• no accidental page numbering
• edge-to-edge composition

Copyright boundary

Allowed:

• user-owned stories
• user summaries of ideas or experiences
• original educational reframing

Disallowed:

• direct transformation of substantial copyrighted text or art into near-derivative output
• exact imitation of a protected living artist's signature style

Output contract

Default user-facing output should include:

• a compact explanation of chosen visual form and style
• a short storyboard summary
• final image(s) or assembled page
• concise notes if any panel required retries or fallback

Internally keep these artifacts whenever useful, using the naming convention from Quick commands:

• panel_plan.json
• prompts/NN.md per panel
• pages/NN-<slug>.png per panel
• per-panel render task records and retry notes

Do not force raw JSON on the user unless they ask for it or the task benefits from editable intermediate output.

Style system

Supported style presets live in presets/styles.json (12 presets).

presets/styles.json is the source of truth; the list below is a human-readable summary:

• cute-cartoon — bright cute cartoon / 明亮可爱卡通
• watercolor-picture-book — warm watercolor picture book / 温暖水彩绘本
• shonen-manga — Japanese shonen manga / 日式少年漫画
• slice-of-life-color — colorful slice-of-life manga / 彩色日常漫画
• gongbi-comic — Chinese gongbi comic / 国风工笔漫画
• ink-wash-comic — ink wash comic / 写意水墨漫画
• toon-3d-animation — 3D cartoon animation / 3D 卡通动画
• claymation — claymation / 黏土定格
• sci-fi-future — sci-fi future comic / 科幻未来漫画
• vintage-watercolor-travelogue — vintage watercolor travelogue / 复古手绘水彩
• doodle-sketch — doodle sketch comic / 潦草涂鸦风
• naive-crayon-sketch — naive red-blue crayon doodle / 红蓝蜡笔稚拙涂鸦

naive-crayon-sketch note: use it for photo-to-doodle redraws (often a top-photo / bottom-doodle contrast layout), travel memory keeping, and childlike records. Its fallback_style_id is doodle-sketch and its stability_rank is 2, so it is a reasonable first choice for casual travel material but should fall back quickly if faces turn unreadable.

When a request is ambiguous, recommend 2 to 3 styles instead of forcing a single one.

Example resources

If you need a concrete starting point, read:

• examples/four-panel-demo.json
• examples/chinese-webtoon-demo.json (zh-CN diary/slice-of-life webtoon example)
• characters/protagonist.md (default character card)
• presets/styles.json
• schemas/panel-plan.schema.json
• schemas/render-task.schema.json

Quick commands（快速指令）

These are shortcuts over the core workflow; they reuse the same schemas, retry policy, and character bible.

• 只出分镜 / storyboard only — stop after the panel plan; render nothing. Cheapest way to iterate on narrative before spending image calls.
• 重出第 N 格 / 重出 2,5,8 / regenerate N — regenerate only the listed panels. Reuse panel_plan.json and the compiled prompts, re-render just those panels, keep all other panels untouched, and record the update in the render-task notes.
• 换画风保留分镜 — keep the panel plan, recompile prompts with a different style preset, re-render all panels.

Artifact naming convention (when saving to disk):

• panel_plan.json — the storyboard / panel plan
• prompts/NN.md — compiled prompt for panel NN
• pages/NN-<slug>.png — rendered image for panel NN

NN is the 1-based panel index matching the order of the panels array. The mapping between prompts/, pages/, and the panels array is what makes single-panel regeneration reliable.

Revision behavior

When the user asks for changes:

• prefer single-panel repair when the issue is local
• change style preset only if the issue is stylistic, not compositional
• change the storyboard only if the problem is narrative
• carry forward the validated character bible and successful panels whenever possible