Open-source project
OrRon/EpicInfographics avatar
OrRon/EpicInfographics

EpicInfographics: an agent skill that replaces the stock infographic template

A simple skill that will make your Agent create beautiful Infographics

409 stars39 forksJavaScriptMIT

At a glance

What is it?
OrRon/EpicInfographics is an MIT-licensed JavaScript skill that gives AI agents a written design process for infographics: scene-first composition, computed charts, and a self-review pass before output. It is a skill file, not a web app, and the README does not document installation steps.
Who is it for?
Adopt EpicInfographics if you already drive an AI agent that can read a skill directory and render HTML, and you want infographics that do not look like rounded card grids. Do not adopt it if you need a hosted tool with a point-and-click editor, or if you expect a documented install command: the README shows no setup steps, only a gallery, design language specs and a bundled render script.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 22 days ago.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem EpicInfographics targets: agents default to the same template

Ask most AI agents for an infographic and the README says you get a predictable result: rounded cards in a symmetric grid, Tailwind blue, an emoji standing in for an icon, a bar chart floating on a flat background. The project's own framing is blunt about it. The output works, and it is instantly recognizable as machine-made.

EpicInfographics is aimed at people who already generate graphics through an agent and are tired of that look. It is a skill, meaning a set of instructions and reference files the agent reads before it designs anything. The repository is JavaScript, licensed MIT, and organized around skills/, docs/, examples/ and scripts/. There is no server, no dashboard, no API to call. The audience is narrow on purpose: someone who can point an agent at a skill directory and let it write HTML.

How the skill works: scene-first composition and arithmetic instead of eyeballing

The core instruction is that the canvas is a place, not a page. Every piece builds a scene (a drafting sheet, a dark theatre, a naturalist's folio, a miniature world) and the data lives inside that scene. The README states flat graphic minimalism counts as a failure here, even when it is tidy. That is a strong editorial position, and it is the main reason the gallery pieces do not look interchangeable.

The second mechanism is that the drawn object carries the data. The README gives concrete examples: a cup filled to two thirds because 2 in 3 adults drink coffee, a rocket whose hatched section is exactly the 90% propellant fraction, a funnel of stage light drawn at 1px per 140 users. Charts are computed rather than eyeballed, with bar ratios, donut arcs and areas coming from arithmetic written into the file. Every palette is described as passing a six-check color-blind-safety validation, including the dark ones.

The third mechanism is self-review. According to the README, every graphic gets screenshotted, read back, and checked against an anti-slop list before the user sees it: a no-text squint test, a template test, and a flat-ground test. This is the part worth scrutinizing. A checklist run by the same agent that produced the image is not an independent review, and the README does not describe a separate model or a human gate. Treat it as a discipline the agent imposes on itself, not a guarantee.

Design languages are stored as complete specs the agent executes as written: exact hex values, font pairings, geometry, signature devices, do's and don'ts. The README lists blueprint, dark-glass, naturalist-plate, isometric-world, retro-print, editorial and hand-drawn, with the first six described as the scene-native defaults. Animation is optional and asked up front; the same HTML file drives both the still and the motion version.

Installing EpicInfographics: what the README does and does not give you

There are no install commands in the README. No npm package, no pip install, no Docker image, no version number, and no release retrieved for this project. The README points at the repository itself: the skill lives under skills/, the render tooling under scripts/, and the CI workflow is at .github/workflows/ci.yml. If you are looking for a download or a package manager entry, the README is silent, and you should read the repository tree before assuming one exists.

The practical path is to clone the repository and let your agent read the skill directory. The command below is the standard clone for this project; the branch is main.

bash
git clone https://github.com/OrRon/EpicInfographics.git
cd EpicInfographics
ls skills docs scripts examples

The listing should show the skill files, the documentation directory, the render scripts and the thirteen example briefs. From there, the README's suggested entry point for a first real use is a brief. It links examples/briefs.md as the place to find test briefs, and each gallery piece links to its own brief, HTML source, and MP4 and GIF versions.

bash
cat examples/briefs.md
ls examples/rocket-launch

The first command shows the briefs the project used to produce the gallery. The second shows one example folder, which the README documents as containing the brief, the HTML source, and the rendered MP4 and GIF. Reading the HTML next to its brief is the fastest way to see how a scene, a computed chart and a palette spec turn into a finished file.

Animation is a separate step. The README states a bundled script scrubs the page's CSS animations frame by frame in headless Chromium and assembles the MP4 and GIF with ffmpeg. That means headless Chromium and ffmpeg have to be available on the machine running the render; the README does not list versions or a container recipe. If you only want stills, you can skip that path entirely.

Where EpicInfographics breaks down

The biggest limitation is that this is instructions, not a renderer. The skill constrains what the agent designs; it does not guarantee the agent follows. A model that drifts from the style spec will still produce a file, and the only check described is the agent's own screenshot review. There is no test suite mentioned for output quality, and CI is referenced only through a badge, so what CI actually validates is not stated in the README.

The second constraint is the environment. The animation pipeline depends on headless Chromium and ffmpeg, both named in the README but neither versioned there. On a locked-down machine or a CI runner without a browser binary, the stills may work while the animated versions do not.

The third is fit. If your actual need is a quick chart embedded in a report, a scene-first spec is overhead. The README is explicit that tidy flat minimalism counts as a failure, which means a clean, conventional bar chart is off-brand for this skill. Anyone who wants a neutral corporate chart should use a charting library instead.

Finally, the gallery is the evidence base. Thirteen briefs across twelve design languages and six canvas formats, all produced by the skill per the README. That is a demonstration, not a benchmark, and it says nothing about how the skill behaves on a brief outside those styles.

EpicInfographics compared with a charting library

The natural alternative is a charting library such as D3 or a chart component from a UI framework. The difference is where the design decision lives. A charting library gives you a rendering primitive and a set of defaults; you decide the palette, the layout and the surrounding page. EpicInfographics inverts that. It hands the agent a full art direction spec, including exact hex values and font pairings, and expects the agent to compose a scene around the data rather than drop a chart onto a background.

That inversion is the whole value proposition and the whole cost. With D3 you get reproducible geometry and a large body of documented behavior; you also get the stock look the README complains about unless you do the design work yourself. With EpicInfographics you get a design process written down, and you accept that the output quality depends on the agent executing it faithfully. If your team already has a designer and a component library, the skill adds little. If your team has an agent and no designer, it is the missing half.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-27, which is recent. There are no retrieved releases, so there is no version number to pin and no changelog to read. Upgrading means pulling main and re-reading the skill files, because the design languages are stored as specs and a spec change alters output for every brief that uses it. Nothing in the README describes a migration path or a stability promise for those specs, so treat a pull as a potential visual change across all your generated graphics.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive arrangement, but it is not legal advice: if the output incorporates fonts or assets referenced by the style specs, check those separately, since the README names font pairings without listing their licences.

Editorial conclusion

Adopt EpicInfographics if you already drive an AI agent that can read a skill directory and render HTML, and you want infographics that do not look like rounded card grids. Do not adopt it if you need a hosted tool with a point-and-click editor, or if you expect a documented install command: the README shows no setup steps, only a gallery, design language specs and a bundled render script. Before committing, open skills/ and scripts/, confirm the animation path works without ffmpeg or headless Chromium on your machine, and read one style file end to end to judge whether its spec is something your agent can actually execute.

Frequently asked questions

What is the main purpose of EpicInfographics?

It teaches an AI agent to design infographics the way a studio would, replacing the rounded-card grid, Tailwind blue and emoji-icon look the README says agents default to. It does this by writing down a process: build a scene, let the drawn object carry the data, compute the charts, and review the render against an anti-slop list.

What is an example of an infographic made with EpicInfographics?

The gallery lists thirteen briefs, including an orbital launch in the blueprint style, the streaming wars in dark-glass, the coffee tree as a naturalist plate, and anatomy of a margherita in the hand-drawn style. Each example links to its brief, its HTML source, and MP4 and GIF versions.

Are infographics still relevant in 2026?

The README does not address that question. It argues only that machine-made infographics are recognizable and that a written design process produces better ones, and it backs that argument with a gallery rather than with data about demand.

What are the three main types of infographics?

The repository does not classify infographics into types. It defines design languages instead: blueprint, dark-glass, naturalist-plate, isometric-world, retro-print, editorial and hand-drawn, with the first six described as the scene-native defaults.

Official sources

  1. Issues
  2. License: MIT
  3. OrRon/EpicInfographics on GitHub
  4. README
Community notes

Community notes