create-explanatory-image

name	create-explanatory-image
description	Generate explanatory diagrams and infographics that visually communicate concepts. Iterates autonomously until images are logically correct, text is clean, and the concept explanation is clear. Uses Nano Banana 2 (Gemini 3.1 Flash Image).
automation	gated
allowed-tools	Bash, Read, Write, Glob, AskUserQuestion
user-invocable	true
metadata	{"version":"1.1","created":"2026-03-03T00:00:00.000Z","author":"Ruby","changelog":["1.1: Imported explanation principles from /animated-explainer, adapted for static images - truth gate before design, one worked example (prefer a failure), explainer-not-advertisement, mechanism/numbers separation with disclosed scale, locked no-crossing layout, nothing floats, visibly-unfinished parts, labels-first storyboarding; self-critique now checks facts and structure separately from looks","1.0: Initial version"]}
category	visual-communication

Create Explanatory Image

Purpose

Generate explanatory diagrams and infographics that clearly communicate a concept, iterating autonomously until the images are logically correct, text is accurate, and the visual explanation lands.

Core Principles

Adapted from /animated-explainer - what makes an image explain rather than decorate. Apply them at decomposition time (Steps 2-3); the self-critique loop (Step 5) checks them.

1. The facts are the boss - interrogate before you design. Decide what's TRUE before deciding what's compelling. If the image explains a real system, read its source of truth (specs, architecture docs, the actual data) - not marketing copy or published summaries. A concept the facts don't support dies at this step; that is the step working, not failing. Never soften an unsupported claim into a diagram.

2. One concrete worked example beats any amount of abstraction. A diagram that traces one real item end to end (this request, this invoice, this forecast) explains more than an abstract schema. Prefer a failure case the mechanism catches - it shows the machine doing its job and cannot be read as cherry-picking.

3. Explainer, not advertisement. Assume the viewer knows nothing. Open on the problem the mechanism solves - the title states what's broken or the single insight, not the product name. If the image only makes sense to someone who already understands the system, it has failed.

4. Separate the mechanism from the numbers. Carry the mechanism with symbolic marks; put real figures in ONE place (a footer stat, a single callout) or nowhere. If a mark is not 1:1 with a thing, say so on the image (1 dot = ~30 runs). Never silently mix scales. This also serves the 10-label limit.

5. Lock the layout - nothing crosses anything. One spine (a left-to-right flow or a single loop), elements sitting ON it. Crossing arrows read as complexity, not as a system. Prompt for it explicitly and reject renders where connections cross or wander.

6. Nothing floats - every element visibly comes from somewhere. The static cousin of "nothing teleports": causality is carried by explicit arrows and numbered steps (input -> transform -> output). An element with no incoming or outgoing connection is decoration - cut it or wire it in.

7. Show the part that doesn't work. If part of the system is unproven, planned, or broken, draw it dashed/hollow/greyed and label it. A diagram where everything works is the least trustworthy thing you can draw - the unfinished part is the credibility.