Pinker Teach For Understanding

---
name: pinker-teach-for-understanding
description: Design, deliver, or audit explanations and lessons with a Pinker-informed focus on phenomena, the curse of knowledge, concrete models, active reasoning, feedback, and revision. Use when the user explicitly requests Pinker's approach to teaching, invokes this skill, wants a difficult idea explained to a specified audience, or asks for a lesson, tutoring sequence, course segment, or teaching audit grounded in his work. Describe this as Pinker-informed teaching, not as a validated pedagogy created by Steven Pinker.
---

# Pinker: Teach for Understanding

Produce a change in what the learner can reconstruct and use, not merely a smooth presentation. Treat learners as intellectually capable people who do not yet share the expert's chunks, vocabulary, or background.

## Choose the mode

- **Explain the method:** State Pinker's direct advice, his observable teaching practices, this workflow's derivations, independent instructional evidence, and important limits separately.
- **Design:** Create a lesson, explanation, worked example, exercise sequence, or course segment.
- **Teach:** Run a responsive tutoring exchange. Ask one useful diagnostic at a time and adapt to the learner's response.
- **Audit:** Locate where an existing lesson assumes knowledge, obscures its model, substitutes fluency for learning, or fails to test transfer.

Read [references/teaching-evidence.md](references/teaching-evidence.md) when attribution, research support, or a broad claim about Pinker matters. Read [references/teaching-patterns.md](references/teaching-patterns.md) for ready-to-use designs and audits.

## Build the lesson

### 1. Define an observable destination

Name the phenomenon or consequential question and the performance expected afterward. Prefer outcomes such as explain, distinguish, predict, diagnose, apply, or critique. Do not use “understand” alone.

### 2. Diagnose the learner model

Establish the audience, purpose, prior knowledge, likely misconceptions, language needs, accessibility needs, time, and setting. When interaction is possible, use a short prequestion, prediction, miniature case, or paraphrase. Do not assume that imagining a novice defeats the curse of knowledge.

If the user has not supplied a live learner, state reasonable assumptions and mark them as assumptions. Provide diagnostic questions the user can run later.

### 3. Decompress expert chunks

Write down:

- the central claim in one sentence;
- the causal or logical chain, one link at a time;
- indispensable terms, acronyms, premises, and referents;
- prerequisites classified as known, teach now, or defer;
- a concrete instance for every important abstraction.

Define necessary technical vocabulary at first useful contact. Do not purge terminology that the learner must eventually command.

### 4. Construct a phenomenon-first explanation

Use this default arc when it fits:

1. Present a real observation, question, demonstration, case, or paradox.
2. Connect it to something the learner already knows.
3. Show a concrete case.
4. Name the general principle.
5. Walk through the mechanism or reasoning without hidden steps.
6. State the conclusion, scope, and live uncertainty.

Pair generalizations with examples and state what each example demonstrates. For an analogy, map the corresponding parts and identify where the analogy stops working. Do not use an entertaining analogy as a substitute for the mechanism.

### 5. Make epistemic structure visible

Distinguish claim, evidence, inference, assumptions, alternative explanations, uncertainty, and what could change the conclusion. Separate correlation from causation and an illustration from evidence. Preserve genuine controversy while staging detail so that a novice first gains a defensible orientation.

### 6. Require learner reasoning

Include at least one immediate check. For a lesson of roughly ten minutes or more, or any multi-part explanation, use checks at more than one level:

- **Reconstruction:** explain the mechanism in the learner's own words;
- **Discrimination:** distinguish it from a tempting near-miss;
- **Prediction:** infer an outcome before it is revealed;
- **Application:** use it in a new case;
- **Critique:** identify an assumption, counterexample, or rival account.

Do not use “Does that make sense?” as the only check. Recognition, assent, and verbal familiarity are weak evidence of learning.

### 7. Use feedback diagnostically

Keep feedback to the learner separate from evidence for the teacher.

Give the learner specific information about the target, the current gap, and a useful next move. For the teacher, collect errors, paraphrases, pauses, questions, transfer attempts, or assessment results that reveal where the model failed.

If no representative learner has tried the explanation, say that it is untested. Put this in a planning or handoff note rather than inside a standalone learner-facing artifact. Never invent learner feedback or claim the lesson has been validated.

### 8. Revise in two passes

First repair content: truth, model, evidence, missing prerequisites, alternatives, and qualification. Then repair presentation: sequence, examples, transitions, sentence load, terminology, modality, and pacing. A polished misconception is still a failed lesson.

For instruction extending over time, add spaced retrieval and varied transfer tasks. Make learners choose which reasoning tool applies rather than naming it in every prompt.

## Produce useful outputs

For a lesson plan, return the learner assumptions, destination, explanation arc, learner actions, checks with expected evidence, likely misconceptions, and revision signals. Keep teacher language separate from planning notes when that helps delivery.

For a live explanation, begin with the phenomenon and adapt. Do not front-load the provenance ledger unless the user asks about the method.

For an audit, lead with the highest-impact failure, show the learner symptom it can cause, and give a concrete repair. Distinguish correctness problems from presentation preferences.

For a method explanation, use plain provenance labels when useful: **direct Pinker advice**, **observed Pinker practice**, **workflow inference**, **independent evidence**, and **boundary**.

## Maintain the attribution boundary

- Call the result a Pinker-informed workflow. Pinker has not published or validated one comprehensive teaching theory.
- Treat his *Rationality* course as evidence of design choices, not proof that its sequence is optimal.
- Do not infer that literacy, mathematics, or disciplinary knowledge will emerge naturally from claims about spoken-language acquisition.
- Do not derive learning styles, left/right-brain teaching, fixed ability, genetic destiny, or a blanket preference for discovery learning from Pinker's work.
- Treat enthusiasm as motivational guidance, not proof of learning.
- Do not present lists of fallacies or biases as sufficient for general critical-thinking transfer.
- Do not turn Pinker's contested claims about language, evolutionary psychology, violence, progress, or politics into instructional premises.
- Preserve accessibility, alternative modalities, true uncertainty, formal validity, and safety requirements over stylistic neatness.