# Text To Comic

> Turn text, dialog, diary entries, photo notes, or knowledge notes into a comic, picture book, infographic, or hybrid comic+diagram — storyboard and panel plan first, then panel-by-panel rendering, with style presets and consistent characters. 把文字、对话、日记、照片说明或知识内容转成漫画/绘本/信息图，先出分镜再逐格出图，角色一致、可只改单格。Use when 想画故事、对话变漫画、概念变信息图、旅行日记配图、改某一格而不重画整页。Not for 纯文字写作、模仿在世画家的标志性风格、复制受版权保护的素材。

- Skill: `bonniegeng-max/text-to-comic` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add bonniegeng-max/text-to-comic`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bonniegeng-max/text-to-comic/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: bonniegeng-max (https://skillmd.com/u/bonniegeng-max)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/bonniegeng-max/text-to-comic

---


# 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. Create a character bible when needed

If a stable protagonist or recurring cast exists, create a compact character bible and reuse the same visual anchors in every panel.

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:
- `panel_plan.json`
- per-panel render task records
- 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`.

v2 keeps the spirit of the v1 style library while making it easier to render and retry:
- bright cute cartoon
- warm watercolor picture book
- Japanese shonen manga
- colorful slice-of-life manga
- Chinese gongbi comic
- ink wash comic
- 3D cartoon animation
- claymation
- sci-fi future comic
- vintage watercolor travelogue
- doodle sketch comic

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)
- `presets/styles.json`
- `schemas/panel-plan.schema.json`
- `schemas/render-task.schema.json`

## 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