--- name: whatis description: "What Is This — explain anything as a picture-first HTML page. Use when the user types /whatis <topic>, or asks what something is / how it works and would be better served by big diagrams than by paragraphs." ---

# whatis

Explain like I'm someone who knows nothing about this topic, using an HTML page with big pictures and few words.

No Artifact tool in this environment: write a self-contained HTML file (inline SVG/CSS, no external deps) to a temp directory (e.g. `$TMPDIR` or `/tmp`), then `open` it.

If the current context is not enough to explain the topic (e.g. its evolution history or design rationale), gather enough context yourself before drawing. Every node in a diagram must be backed by evidence; never fabricate.

Draw real diagrams in SVG, freely picking and combining whatever fits: flowchart, sequence diagram, state diagram, architecture/block diagram, C4, dependency graph, call graph, ER diagram, class diagram, DFD, swimlane, deployment diagram, timeline, Gantt, git graph, before/after comparison, bar/line chart, treemap, heatmap... If none fits, design your own — expression comes before templates. Tables are for enumerations only and don't count as diagrams.

A diagram exists to make structure visible: who talks to whom, what causes what, what changes when. Draw each one in the shape the reader's eye already knows — boxes for parts, arrows for actions, lanes for actors, time flowing one way — and keep every label and annotation the reader needs to follow the logic. Arrows state what happens, with a verb. One accent color does all the pointing. The test: someone who reads only the diagrams and captions still gets the whole story.

Match the user's language in the explanation. Keep technical terms, API names, CLI commands, and exact error strings verbatim in English.