eli5 - Explain Like I’m 5.
Lekin, 2-3 ta misollarni o’rganib chiqib, o’zimga moslashtirvoldim - yaxshi diagramma bilan HTML artefakt qiladi. Qiyinroq mavzularni o’rganishga qulay usul. Sizga ham osh bo’lsin!
---
name: eli5
description: Use when the user types /eli5 <topic>, or asks for a picture explainer, a visual walkthrough, a diagram of how something works, or a dead-simple explanation of a system, module, tradeoff, incident, or unfamiliar concept.
---
# eli5
Turn one topic into a single HTML artifact a smart stranger can understand in sixty seconds.
Topic: $ARGUMENTS
## The reader
Intelligent, with no context on *this* particular domain. Not a child, not a beginner at everything. Write for a sharp colleague from a different team.
## Before you draw anything
Get the mechanism right first. If the topic lives in this repo, read the actual code, config, or logs — never explain from a guess about how it probably works. If it is a general concept and you are unsure of a detail, say so on the page instead of inventing a confident answer. A plausible explainer that describes the wrong mechanism is worse than no explainer.
## The artifact
Load `artifact-design` first, and `artifact-diagramming` for the diagram. Then write the HTML and publish it with the Artifact tool.
The page has five parts, in this order:
1. **The answer** — one sentence, the largest text on the page.
2. **The picture** — one diagram of the real mechanism, as inline SVG. Label the parts with the names the reader will meet in the code or the docs.
3. **The moving parts** — three to five of them, one line each, 25 words maximum. Each line says what the part does and why it exists.
4. **Where it bites** — two or three specific misunderstandings people actually have about this topic.
5. **Going deeper** — the precise technical version for the reader who now wants it. Real names, real numbers, real edge cases.
Few words is the constraint that does the work. If a part needs a paragraph, the diagram is wrong.
## Metaphors
Use one at most, drawn from technology the reader already knows: a mail queue, a phone book, a lock on a door. Then name where it breaks — “…except unlike a phone book, this one is rebuilt on every write.”
Do not reach for cars, restaurants, or houses. If the topic is a database query, an analogy about driving to a friend’s house gives the reader nothing they can use.
## Accuracy
Simplify the language, never the facts. When the simple version would be wrong, add the nuance rather than dropping it. Mark anything you could not verify as unverified, on the page, where the reader will see it.
## Tone
The reader is smart and busy. Never “simply,” “just,” “obviously,” “clearly,” “as everyone knows,” or “it’s easy to” — each one tells a stuck reader that the problem is them.