Eli5 Skill for Cursor

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

• 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.

• Explain the problem through its user or operational consequence, including

why the current design produces it.

• Explain the solution as one simple before/after data flow. Introduce each

component by responsibility, not by filename or internal symbol.

• 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:

• Problem
• Solution
• 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.