sketchnote

name	sketchnote
description	Use when the user wants a hand-drawn sketchnote-style infographic that summarizes a document, article, Notion page, or topic into one image. Triggers on "스케치노트", "인포그래픽으로 만들어줘", "sketchnote", "이거 한 장으로 요약해줘", "요약 이미지", "비주얼 요약", or "/sketchnote". Not for ordinary chart/data visualization (use the dataviz skill for that) or for editable design canvases (use the design skill for that).

Sketchnote Infographic Generator

Turn a source (article, Notion page, conversation, raw topic) into one hand-drawn sketchnote-style infographic image, generated with ima2 and refined through a self-review loop, optionally delegated to a background Herdr agent so the main session stays free.

Method is adapted from https://educraft.tech/accurate-study-notes-in-2-mins-with-chatgpt-claude/ : separate "what to say" (blueprint) from "how to draw it" (visual prompt), and never let the image model invent facts.

Step 0 — Get the source

If the user gave a URL, fetch it (WebFetch, or ntn pages get <id> for a Notion page — see the user's global CLAUDE.md for Notion CLI usage). If they pasted text or referenced the current conversation, use that directly. Do not paraphrase from memory — read the actual source.

Step 1 — Write the blueprint (text only, no drawing yet)

Write a blueprint file (e.g. to the session scratchpad) with this exact shape:

TITLE: <one short punchy line>
SUBTITLE: <one short line>

## Module A — <name>
<2-6 word line, key term wrapped in ==double equals==>
<2-6 word line>

## Module B — ...
(6-8 modules total, each 2-4 short lines, no full sentences)

## Central visual
<one clear metaphor/diagram the whole page pivots on — a scale, a funnel,
a branching arrow, etc. Describe what it shows, not how to draw it>

## Closing line
"<one short quotable takeaway sentence>"

Rules for the blueprint itself:

• 6-8 modules, never more — more than that garbles in generation.
• Every line is a label/phrase, not a sentence. Long sentences become illegible gibberish text in the generated image far more often than short labels.
• Mark only the words that must be visually emphasized with ==like this==, at most ~1/4 of the words in a module.
• Treat the blueprint as the single source of truth: nothing in the image prompt (step 2) may introduce facts, numbers, or claims not in this file.
• If the user's language is Korean, write the blueprint in Korean directly — don't plan to translate later, translation-after-the-fact costs a full round.

Step 2 — Write the visual prompt

Translate the blueprint into an English image-generation prompt (English prompts are far more reliable for layout/style instructions even when the rendered text is Korean). Always include these constraints — they were empirically necessary, not optional style flourishes:

• Hand-drawn / chalkboard sketchnote style, pure white background, no lines or grid (dark/neon backgrounds are the #1 regression when re-rendering — restate "white paper background" explicitly on every regeneration, especially when switching languages).
• Black ink + teal as the primary palette; orange used sparingly and only for the 1-2 truly critical emphasized phrases (not decorative underlines on every module title — that dilutes the emphasis).
• Title box only gets a 3D/drop-shadow effect; everything else stays flat line art.
• Irregular, hand-placed layout — explicitly say boxes have different sizes and rotations, and explicitly say "avoid grid/column/row alignment". Left to itself the model defaults to a tidy grid; this has to be forced every time.
• Connectors (arrows) must carry meaning (sequence, cause-effect) — no numbered steps, no purely decorative lines.
• Icons/labels do the explaining — no long caption sentences, no separate "summary" / "key terms" / "conclusion" section (the source article explicitly bans these because they duplicate what the visual should already show).
• Never put literal == characters in the prompt — describe the emphasis ("bold teal lettering") instead of pasting the blueprint's markup syntax, or the model draws the == symbols as literal ink.
• If any text will be Korean, add "accurate Hangul hand-lettering, no garbled or fake characters" and treat Korean-text accuracy as its own review criterion.
• Aspect ratio: pass --size explicitly (e.g. a tall 1024x1536 ≈ 2:3) — the model does not reliably honor ratio words alone in the prompt text.

Step 3 — Generate and self-review loop

1. ima2 status (or ima2 doctor); ima2 serve if not running.
2. ima2 gen "<prompt>" --size <WxH>.
3. Read the generated image yourself (the Read tool renders images). Check against the blueprint line by line: any missing/invented facts, garbled or fake characters, grid-like layout, color-rule violations, forbidden sections.
4. If anything fails, fix only that specific problem in the prompt (don't rewrite wholesale — preserve what already works) and regenerate.
5. Cap self-review at 3 rounds per pass. If the user then asks for a further change (e.g. "make it Korean", "fix the layout"), that's a fresh pass with its own 3-round budget, not a continuation of the same counter.
6. Save the final image to the working scratchpad and report the path plus a short per-round summary of what was wrong and what was changed.

Step 4 — Delegate to a background Herdr agent (optional but default when available)

When HERDR_ENV=1, prefer running steps 1-3 in a separate Herdr pane so the main session doesn't fill up with image-generation back-and-forth:

1. Confirm Herdr: test "${HERDR_ENV:-}" = 1. If not set, just run steps 1-3 directly in the current session instead.
2. Check the current pane's layout (herdr pane layout --pane "$HERDR_PANE_ID") and split right (wide pane) or down (narrow/tall pane), --no-focus, preserving --cwd "$PWD".
3. herdr agent start <name> --kind claude --pane <new-pane-id> (reuse the same named agent across rounds in one session instead of starting a new one each time).
4. herdr agent prompt <name> "<full step 1-3 instructions + blueprint file path>" --wait --timeout 600000. Long generations can make the wait call itself time out even though the agent is still working — that shows up as a timeout error from the CLI, not an agent failure. On that error, just re-issue herdr agent wait <name> --timeout 400000 rather than re-sending the prompt.
5. After it reports done, herdr agent read <name> --source recent-unwrapped --lines 100 to get the round-by-round summary, and Read the resulting image file yourself — do not just trust the sub-agent's self-assessment, you are the final judge before showing the user.
6. If your own review finds a real problem, send one more targeted herdr agent prompt describing exactly what to fix and what to preserve — don't restate the whole brief each time, the agent has context.

Step 5 — Deliver

Once you're satisfied, SendUserFile the final image with a one-line caption naming the source and round count. Don't batch multiple intermediate rounds to the user — only the version you've approved.

Known failure modes (fix directly, don't guess)

• Gibberish/fake text: labels too long or too many modules — shorten to 2-6 word phrases, cap at 6-8 modules.
• Literal == drawn in the image: prompt described emphasis via blueprint markup instead of describing the visual effect directly.
• Grid-like layout despite "organic" wording: the model needs explicit "different box sizes/rotations, avoid row/column alignment" language, not just "organic" or "non-grid" as a single adjective.
• Dark/neon background regression: happens most often right after emphasizing "pure white paper" too hard (overcorrection) or when switching the text language — restate the exact working background phrasing from the prior successful round instead of re-deriving new wording.
• Wrong aspect ratio: ratio words in prose are unreliable; pass --size.