# Eli5

Explain a technical spec or proposed change in plain language: what problem it solves...

- Repository: https://github.com/dzhng/skills (1394 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add dzhng/skills --skill eli5 -g -a claude-code -y`
Codex: `npx skills add dzhng/skills --skill eli5 -g -a codex -y`
Cursor: `npx skills add dzhng/skills --skill eli5 -g -a cursor -y`
Gemini CLI: `npx skills add dzhng/skills --skill eli5 -g -a gemini-cli -y`

## Description

Explain a technical spec or proposed change in plain language: what problem it solves, how the solution works, and every schema change.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

The rest: https://github.com/dzhng/skills/blob/HEAD/skills/engineering/eli5/SKILL.md