/eli5

name: eli5
description: "Explain a technical spec or proposed change in plain language: what problem it solves, how the solution works, and every schema change."
disable-model-invocation: true

ELI5

Turn the referenced spec or change into an accurate mental model for a technical reader who does not live in the code. Plain language, full precision: simplify the telling, never the claims.

The Register

Other skills point here when their output must be readable by someone who didn't live the work. The reader is technical — pseudocode and precise claims land fine — but they have read none of the code and none of the session's messages: no diff, no transcript, no labels the work invented along the way. Writing ELI5 means:

• Walk one concrete scenario end to end — the triggering event, what happens

today, what the change (or the unbuilt alternative) would do — instead of describing properties in the abstract.

• Define every term of art at first use; never lean on labels the spec, code,

or session invented.

• Use small concrete examples without replacing precise claims with analogies.
• Reach for pseudocode when explaining control flow, ordering, or timing.

Prose describing when-something-fires reads as plausible and hides the gap; five lines of pseudocode make the gate visible and let the reader see the case you missed. Write it at the level of the decision, not the implementation — the conditions and their order, not real function signatures. The tell that you needed it: your prose contains "only when", "before", "unless", or "as soon as" and the reader still cannot say what happens on the second call.

• The test: the text stands alone, without the diff, the spec, or the

transcript. If the reader must ask "explain this part", it failed.

Workflow

1. Read the complete referenced artifact and inspect current owners when the spec alone cannot establish behavior. When no artifact is named, explain the session's current change (working tree or branch diff). Separate what exists today from what is only proposed. 2. Explain the problem through its user or operational consequence, including why the current design produces it. 3. Explain the solution as one simple before/after data flow. Introduce each component by responsibility, not by filename or internal symbol. 4. Inventory schema and durable-contract changes exhaustively: added, changed, removed, reset, and deliberately unchanged. Include cursor or wire-format cutovers when they affect stored data or readers. Say explicitly when there are no schema changes.

Output

Use these headings in order:

1. `Problem` 2. `Solution` 3. `Schema changes`

End with one short sentence stating what users should notice after the change.

Rules

• Lead with behavior and boundaries; mention implementation names only when

they clarify ownership or a contract.

• Distinguish canonical records from derived indexes, caches, summaries, and

presentation grouping.

• Call out destructive resets, migration requirements, compatibility behavior,

eventual consistency, and intentional data loss directly.

• Do not omit a schema change because it is operational rather than

user-visible.