Teach back
17 model-agnostic thinking & context-engineering skills for Claude — clarify, attack your own plan, manage the context window, verify before trusting. grill-me-style process skills.
npx -y skills add opelpleple/meta-skills --skill teach-backAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Forces real understanding of a concept by explaining it in the plainest possible language — as if to a 10-year-old — so that every place the explanation stumbles exposes a genuine gap in understanding (the Feynman technique). Use this skill when the user is learning something new and wants to check whether they actually get it: phrases like "explain like I'm 5", "ELI5", "do I actually understand this", "help me learn X", "I'm studying X", "quiz my understanding", "make sure this sticks", or when they ask you to explain a concept simply or to let them teach it back to you and probe the holes.
SKILL.md
4.5 KB, as published. Nobody here has run it
Teach-Back (Feynman)
Understanding is the ability to explain a thing simply; wherever plain language fails, that is exactly where understanding is missing. This skill drives a concept down to ten-year-old clarity and treats every stumble as a map to the gap.
When to use
- The user is learning a new concept and wants to confirm they truly grasp it.
- They ask for an "explain like I'm 5" / ELI5 / simplest-terms explanation.
- They want to be tested on whether their mental model holds up.
- They're studying for an exam, interview, or want something to actually stick.
- They've read or been told something and aren't sure it landed.
When NOT to use
- They want a fast factual lookup or a definition, not deep understanding ("what's the capital of France").
- They need a rigorous, jargon-correct technical spec (e.g. a precise API contract) — oversimplifying would mislead.
- They're an expert seeking nuance or edge cases, not foundational clarity.
- The task is to produce a polished artifact (essay, doc), not to learn.
The method (numbered, concrete — the heart)
- Name the one concept. Pin down a single, specific thing to understand. If the user gives something broad ("machine learning"), narrow to one teachable chunk ("how a model learns from one example").
- Pick the mode. Either (a) you teach it back to them in the simplest terms, or (b) they teach it to you and you probe. Ask which they want; default to (a) for "explain it," (b) for "test me / do I understand."
- Explain at a 10-year-old level. Short sentences. Zero jargon — and if a technical word is unavoidable, immediately define it in plain words. Use one concrete analogy from everyday life (kitchens, sports, money, traffic), not another abstraction.
- Hunt the seams. As you (or they) explain, watch for the moment the words get vague, hand-wavy, or fall back on the jargon you were trying to avoid ("it just optimizes the loss"). That stall is the gap. Flag it out loud: "Right here is where it gets fuzzy."
- Drill the gap with a child's question. Ask the dumb-on-purpose "but why?" or "what does that actually mean?" Keep asking until the explanation reaches bedrock or visibly breaks.
- Patch and re-simplify. Fill the exposed gap, then restate the whole thing once more, even simpler than before. The second pass should be shorter, not longer.
- Close with a one-sentence summary the user could repeat from memory, plus the single weakest spot they should review next.
What good looks like
- A child could follow the explanation and repeat the gist.
- Every analogy maps cleanly onto the real mechanism (no analogy that quietly lies).
- Gaps are named explicitly, not glossed over to sound smooth.
- The final version is shorter and clearer than the first.
- The user leaves knowing both what they understand and the one thing they don't.
Anti-patterns
- Hiding behind jargon to sound rigorous instead of proving understanding.
- A confident, fluent explanation that never tests itself — fluency is not understanding.
- Analogies that are cute but structurally wrong.
- Piling on more detail when the fix is more clarity.
- Letting the user nod along; if they never stumble, you didn't probe hard enough.
Example (short, vivid)
User: "Help me learn how interest compounds — do I actually get it?" Mode (b): "Teach it to me like I'm 10." User: "You earn interest on your interest." → "Okay — but why does that grow faster than plain interest? Walk me through year two with $100 at 10%." User: "Year one... $110. Year two... uh, another $10?" → "Stall. That's the gap. Plain interest gives $10/yr forever. Compounding charges year two's 10% on $110, not $100 — so $11, then $12.10... the base keeps growing. Now you teach me year three." User nails it. → One-liner to keep: "Compounding pays you on your past payouts, so the pile snowballs." Weak spot to review: how the rate-vs-time tradeoff changes the snowball.