/epic-infographics

name: epic-infographics
description: Create polished, professional infographic images from data, facts, or a topic. Builds a self-contained HTML/CSS+SVG page in one of several fully-specified design languages, renders it to PNG with a bundled script, then reviews and fixes its own output. Can also choreograph the same file with CSS animation and render it to MP4/GIF. Use when the user asks for an infographic, a visual summary, a stats poster, a social graphic, a one-pager image, an animated infographic or short data video, or "turn this data into an image."
license: MIT

Epic Infographics

You are going to produce an infographic **image** (PNG) by writing a single self-contained HTML file and rendering it with the bundled script. The three things that separate a great result from a mediocre one:

1. **Varied data representations** — not everything is a bar chart. 2. **Executing one design language exactly** — its tokens are law. 3. **The check–render–review loop** — the mechanical preflight must pass, and you MUST look at your own PNG and fix it before delivering. Never deliver a render you haven't looked at.

Workflow

1. Understand the brief

An infographic made for "everyone" lands with no one. Before touching any data, pin down three things:

• **Audience** — who is this for, and how much do they already know?

(executives skimming, practitioners fluent in the jargon, general public)

• **Goal** — what should the graphic *do*: inform, persuade, impress, or

drive one action? The goal decides what kind of fact can be the hero.

• **Context** — where will it live (feed, slide deck, print, link preview)?

This feeds the canvas choice in step 5 and sets how loud the design can be.

• **Still or animated** — offer an animated MP4/GIF version alongside the

still (step 12). Motion earns its keep where the graphic will autoplay (social feeds, stories, slides, landing pages); for print or a link preview the still alone is the right answer, so say so in the offer.

If the request already answers these, restate them in one line and move on. If not, ask the user before proceeding — one round of questions, as multiple-choice where you have a tool for it (e.g. AskUserQuestion) so answering takes one click. Only when you are running unattended and cannot ask, pick sensible answers and state those assumptions at delivery.

2. Gather the data

Collect the facts that serve the brief. Use what the user gave; research or derive the rest — never invent statistics; if values are illustrative, label them so. Gather slightly more than one graphic needs: the pitch in step 3 is only honest when there was more than one possible angle in the material.

3. Pitch the story

An infographic is an argument, not a data dump. From the data, draft **2–3 candidate story angles**. Each pitch is a working headline, the hero number/fact that anchors it, and one sentence: *what should the reader remember?* The angles must genuinely differ — e.g. "how big it is" vs. "how fast it's changing" vs. "what it costs you" — not rewordings of one claim.

Present the pitches to the user as a multiple-choice question (AskUserQuestion where available, plain text otherwise), with your recommended angle first and marked as recommended. If you cannot ask, take your recommendation and say so at delivery. The chosen angle decides the hero element; every other fact is support or gets cut.

4. Find the visual metaphor

Read `references/illustration-and-texture.md`. List 2–3 physical objects the subject evokes and pick one that can **carry data** (a cup whose fill level is the value, a ladder whose rungs are the steps). This becomes the canvas's subject — the reason the graphic could only be about THIS topic. Type-led styles (swiss) may go abstract instead, but then scale and composition must do the identity work. The litmus test comes back at review: cover the text — is the topic still recognizable?

5. Pick the canvas

| Preset | Size (px) | Use for | |---|---|---| | `square` | 1080×1080 | social feed post | | `story` | 1080×1920 | stories/reels, phone-first | | `wide` | 1920×1080 | presentations, YouTube, wallpaper | | `og` | 1200×630 | link previews, banners | | `a4` | 1240×1754 | print poster/handout | | `tall` | 1080×auto | long-form scrolling infographic |

Aspect drives layout before style does: `story`/`tall` = vertical single-column flow; `wide` = 2–3 column zones; `square` = hero + 2×2 support grid is a safe default.

6. Pick the design language

Read exactly ONE file from `references/design-languages/` and follow it completely — palette hexes, fonts, geometry, signature devices, do/don'ts.

• User asked for a vibe → match it (technical → `blueprint`, dramatic/tech →

`dark-glass`, literary → `editorial`, warm/craft → `retro-print`, friendly → `hand-drawn`, nature/science/anatomy → `naturalist-plate`, systems/places/playful-spatial → `isometric-world`, places/journeys/ vistas → `park-poster`, how-it-works/inside-a-machine → `cutaway`).

• No preference → pick by subject matter, favoring the scene-native styles

above.

• **High slop-risk styles** — `swiss`, `corporate-clean`, `neo-brutalist` —

are flat by construction (type + shapes on a plain ground) and have repeatedly failed audience tests. Use them ONLY when the user explicitly asks for that look, and even then import scene-craft: environment, detail density, a story path (composition.md rule zero).

• Every color and font size in your HTML must come from the style file. No

freelancing.

7. Choose data representations

Read `references/data-vocabulary.md` and pick deliberately **varied** forms: one hero element (big number, hero chart, or hero pictogram) plus 2–4 support elements of *different* types. Three bar charts in a row is a failure even if each one is correct. Prefer forms that fuse with the metaphor (liquid fill, object-as-bar, icon army) over generic charts beside it.

8. Compose and build

Read `references