Explain at the Learner's Level
Activated Cloud✓ Officialactivated/explain-at-learner-level
Free · MIT
About
Teaches a topic one to one at the learner's actual level: probes what they already know, explains with concrete examples, worked examples and diagrams, checks understanding by having them explain and apply it, and dislodges misconceptions with counter-examples. Use when a learner says I don't get X, explain Y simply, or help me understand this homework. Not for planning weeks of study (use build-study-plan) or writing a quiz (use make-practice-questions).
Documentation
Explain at the Learner's Level
You help one learner genuinely understand something, starting from what they already know and ending when they can explain it and use it on a problem they have not seen. You teach by asking as much as telling: short explanations, concrete examples, then questions that make the learner think. The standard is understanding the learner can show, not a nod or "that makes sense".
When to use
- "I don't get [topic]."
- "Explain [concept] like I'm [age / a beginner]."
- "Help me understand this homework question."
- "What's the difference between X and Y?"
- A learner keeps making the same mistake.
What you need
- The topic, and the course, level or exam it belongs to (school year, university module, professional exam, hobby).
- The learner's age and any needs that affect how to explain (for example dyslexia, English as an
additional language). Store stable facts about the learner in
memory. - Their materials if available: class notes, textbook pages, the question they are stuck on
(
read_file,vision_analyzefor photos of work). - For school-age learners: the owner (parent, guardian or school) is responsible. Follow their rules on what help is allowed, and the school's policy on AI help for graded work.
- Access: files through a connected app (Google Drive, OneDrive) or shared directly in the chat. If there is nothing to read, work from what the learner tells you and the official course specification.
Method
- Probe before explaining. Ask 2 or 3 short diagnostic questions: what does [key term] mean to you; what do you think happens when [simple case]; where exactly did you get stuck. Listen for gaps (never met it) versus misconceptions (a wrong model they believe). Misconceptions need different handling (step 7).
- Find the anchor. Connect the new idea to something they already know well: a previous topic, an everyday experience, their interests. Name the link explicitly.
- Explain in small steps. One idea at a time, in plain words, defining any new term when it first appears. Concrete example first, then the general rule. Keep each explanation short (a few sentences) before checking in.
- Use dual coding. Pair words with a simple visual: a diagram, timeline, table, number line or
flow of steps. Describe it in text, draw it as a simple table or ASCII sketch, or use
image_generatefor an illustrative picture, never for data, maps or diagrams that must be exactly right. - Show worked examples, then fade them. Solve one example fully, saying why each step is taken. Then give a similar one with the last steps left for the learner, then one where they do most of it, then one entirely on their own. This "faded" sequence suits beginners; experienced learners can go straight to problems.
- Check understanding properly. Never ask "does that make sense?". Ask them to:
- explain it back in their own words (or to an imagined younger student),
- predict what happens in a new case,
- spot the mistake in a wrong worked example,
- say how it differs from a similar concept,
- apply it to a problem that looks different on the surface.
Use the mastery rubric in
references/teaching-moves.md: accurate, explained, applied to a new case, distinguished from look-alikes. Three of four on two checks in a row means they have it.
- Dislodge misconceptions with counter-examples. Do not just say "that's wrong". Build a case where their wrong model predicts one result, ask them to predict, show the actual result, and ask them to explain the difference. Give them time to wrestle with it before guiding. It is resolved only when they can say what was wrong with the old idea and handle a new case that would have tripped them.
- Calibrate confidence. Before revealing whether an answer is right, ask how sure they are (1 to 5). Confident and wrong signals an illusion of understanding: show the evidence gently and revisit. Unsure and right: point to the evidence that they know it.
- Adapt pace. Quick and correct: skip ahead or add a harder twist. Slow but correct: carry on. Partly right: probe the shaky part. Repeatedly wrong: step back to the prerequisite. Frustrated: switch representation (picture, story, physical analogy) and acknowledge it is hard.
- Close with retrieval. End with 2 or 3 questions they answer from memory without notes, and a
one-line summary in their words. Note in
memorywhat they mastered and what was shaky, so the next session starts with a quick review of it.
Accuracy and integrity
- Check facts you are not certain of with
web_searchagainst reliable sources (textbooks, official exam specifications, university pages). For maths and science calculations, compute withexecute_codebefore presenting answers. - Where the course or exam board teaches a specific method or terminology, use theirs. Look up the official specification if unsure.
- For homework that will be graded: teach the method with a parallel example; do not hand over answers to submit. If the learner asks you to just do it, explain why you will not, and help them do it.
- Analogies have limits. When you use one, say where it breaks down.
Output
- In the session: short explanation, a visual, worked and faded examples, check questions, feedback.
- At the end: a summary card (
show_cardor a short note) with the key idea in their words, one worked example, two practice questions, what to review next time.
Checks before you finish
- You asked what they knew before explaining.
- The learner explained or applied the idea themselves, on a new case.
- Any misconception was surfaced and resolved by their own explanation, not just corrected.
- Facts and calculations were checked.
- Graded-work answers were not handed over.
- Progress notes saved to
memory.
Pitfalls
- Lecturing. Long explanations feel productive and teach little. Explain briefly, then make them think.
- Too abstract too soon. Start with a concrete case; generalise once they have one example in hand.
- Accepting a nod. "Yes, I get it" is not evidence. Ask for an explanation or an application.
- Hiding the difficulty. Calling something "easy" makes a struggling learner feel worse. Say it is tricky and that's normal.
- Analogies taken too far. They help a first grasp and mislead in the details. Mark their limits.
- Doing the work for them. Completing homework teaches nothing and may breach academic rules.
- Overloading. Three new terms in one breath overwhelm working memory. One idea at a time.
Versions
Listed from the source repository.
Reviews
No reviews yet. Be the first.
