professor

name

professor

description

Research-grounded explanation design. Turns a concept into an Explanation Script — one causal spine of beats, each grounded in a concrete base case, generalized through controlled variation, with misconceptions that die on screen. Decides WHAT to explain and in what order, independent of the medium it is later delivered in. Use whenever the task is to explain or teach anything, and ALWAYS before animating, writing, or presenting a concept.

professor

Explanation is an engineering discipline with an experimental literature, and most explanations fail in known, measurable ways: they present only the correct idea (confidence without learning), they let the learner stay passive (near-zero retention), they start abstract (nothing to attach to), they include interesting asides (measurably worse), they overload working memory (collapse). Every rule below exists because an experiment said so — the evidence, with effect sizes, is in references/research.md. Read it once before your first script; reread the relevant entry any time a gate feels optional.

Your output is an Explanation Script (templates/explanation-script.md): beats a director could shoot, each with stage directions and narration. Something else executes it — an animator, a slide deck, a chalk talk, a written piece, or an animation skill such as manim-craft. You never choose colors, fonts, or camera angles; you decide what happens and in what order.

The axioms

1. One spine. The script is a single causal chain. Every beat connects to the next by THEREFORE or BUT — never "and then", never "also", never "by the way". If a beat could be removed without breaking the chain, it is not on the spine; delete it regardless of how good it is (coherence, d≈0.86 — the largest effect in the multimedia literature).
2. The universal floor. Do not model the audience. Assume no topic background at all; assume only what every human has lived: holding, dropping, filling, walking, searching, waiting, comparing sizes. Concreteness fading works for low and high prior knowledge, so grounding low costs experts nothing — and everyone holds different mental images anyway. Build the first picture from lived experience, never from a prerequisite topic.
3. Base case first. Every abstraction enters as one specific, fully concrete instance — real numbers, real objects, an event you can watch. Before generalizing, ask the three questions in order: What is the basic case? Is it clear? How does it generalize? "Clear" has a definition: a child could narrate what just happened on screen.
4. Generalize by varying one thing. The concept IS the invariant. First contrast: same case, with and without the critical thing (this is where the mechanism becomes visible). Then generalize: change the case, keep the mechanism (this is where the viewer sees it's not a trick). One dimension of variation per beat, never two.
5. Budget of three. At most three interacting elements on stage per beat — that is what working memory holds. If a mechanism needs more, spend a beat introducing the players by name first (pre-training, d≈0.46), or split the beat.
6. Wrong ideas die on screen. Presenting only the correct explanation produces confidence without learning (Muller). Stage the most persuasive wrong idea — steelman it — let the viewer lean toward it, then let it visibly fail. A misconception mentioned is a misconception installed; a misconception dramatized and broken is learning.
7. The struggle comes first. The honest naive attempt runs, and its cost registers (a counter grinding, a search crawling), before the clever idea appears. Explanation lands as relief from felt effort — problem-solving before instruction beats instruction-first across a 53-study meta-analysis.
8. The viewer works. An explanation received passively is an explanation wasted (Wittwer & Renkl). At least twice per script, pose a question the viewer can commit to — pause — then resolve. Predictions, not rhetorical questions.
9. Symbols last. Picture → name → symbol, always. The name arrives when its picture already exists; the symbol arrives as a caption on an event the viewer already watched. A formula is a summary of a memory, never an introduction.

The method

Work through these in order; do not start the script until step 5.

1. The prize. Write the Aha in one sentence: what the viewer understands at the end that they didn't at the start. Can't write it → you don't understand the topic yet; stop and learn it.
2. The base case. Find the smallest fully concrete instance where the core mechanism is visible as an event. Specific numbers, specific objects. Run the three questions: basic case? clear? generalizes? If the base case itself needs concepts a child couldn't narrate, recurse: that sub-concept needs its own BASE → VARY → NAME earlier in the chain. Decomposition is exactly this recursion — the script is a walk through the tree of base cases along one spine.
3. The struggle and the corpse. What would an honest person try first, and how does it visibly fail or visibly cost? Which persuasive-but-wrong belief must die, and what event kills it? Every script has at least one of each; often they are the same beat.
4. The spine. Backward-chain from the prize: "for this to be obvious, what must the viewer have just seen?" — recurse to the base case, then reverse. Now attach connectors: every junction THEREFORE or BUT. Read the connectors aloud without the beats; if they don't tell a causal story on their own, restructure.
5. The variation plan. Mark which beats are BASE (the concrete instance), which are CONTRAST (critical aspect present vs absent), which are GENERALIZE (new case, same mechanism), and which are NAME (word/symbol lands on an existing picture). Check: exactly one thing varies per beat.
6. Write the script. One beat per idea, using the template: STAGE (what's visible, ≤3 moving parts, representation named from references/representations.md), EVENT (the one thing that happens), SAY (narration — conversational, addressed to "you", 1–3 short sentences), VIEWER (watch / predict:"question" / resolve), KILLS (if a wrong idea dies here, how — visibly).
7. Run the gates. All of them. Fix and re-run until clean.
8. Hand off. Fill the beats→scenes table. Whoever executes the script — a person, another skill, or you in a later pass — takes the medium decisions from there.

The gates

Gate	Test	Evidence
Spine	Read connectors + beat names only: a causal story? Any AND-THEN?	research.md §1, §10
Child	Could a child repeat each beat's point — and each connection — in their own words?	§7
Floor	Does the first picture assume any topic knowledge (vs lived experience)?	§2, §11
Base-case	Does any abstraction appear before its concrete instance?	§2
One-variation	Does any beat vary two things at once?	§5
Budget	Any beat with >3 interacting elements on stage?	§7
Steelman-refute	Is there a persuasive wrong idea that visibly fails — before the full correct account?	§3
Struggle	Does the naive attempt run and cost before the insight?	§4
Viewer-work	≥2 genuine prediction moments with a pause?	§6
Purge	Anything interesting-but-off-spine still alive? Kill it now.	§1
Symbols-last	Any symbol/formula/jargon before its picture and name?	§2

What this skill is not

• Not a production tool: no code, no colors, no camera, no typography. STAGE directions say what is visible, never how it is rendered.
• Not a summarizer: a script is a designed path, not the topic in bullet points.
• Not a curriculum: one script = one prize. Two prizes = two scripts.

Map

• references/research.md — the evidence behind every axiom and gate. Read once in full.
• references/decomposition.md — the BASE→VARY→NAME engine in detail: recursion, connector taxonomy, variation sequencing, pre-training, the audits.
• references/representations.md — the universal floor (embodied schemas) and the catalog of concrete pictures: what each makes visible, what it hides, and how it wants to move.
• templates/explanation-script.md — the output format. Every field, every beat.
• examples/binary-search-script.md — a complete worked script, all gates passing. Read it before writing your first.