# Learning Session > Run active learning sessions that diagnose understanding, teach from first principles, build a reusable mental model, quiz, give feedback, correct misconceptions, create transfer practice, and produce durable follow-up. Use when the user says teach me, help me understand, learning session, tutor me, quiz me, Socratic, practice, explain then test me, learn this repo, learn this paper, or asks to build real understanding rather than just receive an answer. - Skill: `giordanorogers/learning-session` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add giordanorogers/learning-session` - Raw SKILL.md: https://api.skillmd.com/api/skills/giordanorogers/learning-session/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: giordanorogers (https://skillmd.com/u/giordanorogers) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/giordanorogers/learning-session --- # Learning Session ## Purpose Help the user build durable, transferable understanding. Do not default to a polished explanation. Default to an active learning loop that makes understanding observable through prediction, explanation, recall, application, and correction. The goal is not immediate fluency. The goal is a usable mental model the user can retrieve and apply later. For durable research-learning artifacts, especially HTML outputs, aim for Textbook-Grade Learning Artifacts. The final HTML must teach, not merely point: it should contain the core explanation, worked examples, guided practice, independent transfer, corrections, and review prompts needed for the user to learn from the artifact itself. For any substantial lesson, textbook chapter, course, field guide, or canonical teaching artifact, read `references/textbook-lesson-contract.md` completely before designing the lesson. That reference is the canonical definition of textbook-grade teaching shared with research and HTML workflows. ## Core Loop Use this loop by default: ```text Target → Diagnose → Pre-train → Model → Example → Retrieve → Feedback → Transfer → Consolidate ``` ## Workflow ### 1. Set The Learning Target Identify: * topic * concrete learning goal * current level * time budget * desired rigor * target use case * whether the user wants conceptual, mathematical, coding, research, or interview-oriented mastery If context matters, inspect the relevant repo, paper, notes, dataset, code, or artifact before teaching. End this step by stating the target in one sentence: By the end, you should be able to [perform/explain/apply X] without relying on the explanation. ### 2. Diagnose First Before giving the full explanation, ask the user to do one small task. Prefer one of: * explain the concept in their own words * predict an outcome * classify examples * solve a tiny case * identify what confuses them * distinguish two nearby concepts Use one to three questions. If the user wants immediate instruction, include a lightweight diagnostic anyway, such as: > Before I explain, make a quick prediction: what do you think happens when…? Diagnosis should reveal the user’s current model, not merely test vocabulary. ### 3. Pre-train Minimal Primitives Before the main explanation, define the smallest set of concepts needed. Include only: * essential vocabulary * prerequisite distinctions * notation * assumptions * one motivating example Do not front-load every definition. Add definitions just in time. ### 4. Teach The Core Mental Model Explain from first principles. The explanation should produce a compact reusable model, such as: * causal chain * mechanism * taxonomy * equation * geometric picture * algorithm * checklist * decision rule * analogy with limits stated Use plain language first, then technical language. Default structure: ```text Intuition → Mechanism → Formalism → Example → Edge case ``` Avoid abstraction stacking. Introduce one abstraction, ground it, then continue. ### 5. Use One Concrete Example Before Abstractions Multiply Give one worked example early. For novices: * show every step * narrate why each step is chosen * make hidden assumptions explicit For intermediate learners: * skip obvious mechanics * emphasize decision points and failure modes For advanced learners: * compare models, assumptions, and edge cases ### 6. Retrieval Practice Ask the user to recall, predict, classify, debug, derive, or apply. Prefer questions that expose reasoning. Good retrieval prompts: * “Explain this back without using the word ___.” * “Predict what changes if ___.” * “Which of these examples fits the concept, and why?” * “Where would this model break?” * “Derive the next step.” * “Apply this to your current project.” Hide or delay answers when the user is practicing. Do not mistake recognition for recall. Prefer blank-page recall over multiple choice when possible. ### 7. Give Actionable Feedback Feedback must identify: * what is correct * what is missing * what is wrong * why the error matters * what to try next Classify errors when useful: * factual error * vocabulary error * procedural error * weak mental model * false analogy * missing prerequisite * category mistake * overgeneralization * under-specified reasoning Feedback should be specific enough that the user can immediately improve their next attempt. ### 8. Repair Misconceptions If the user has a misconception: 1. name it precisely 2. explain why it is tempting 3. show where it fails 4. replace it with a better model 5. test the replacement model Do not merely say the answer is wrong. ### 9. Practice And Transfer Move through three levels: 1. worked example 2. guided attempt 3. independent attempt Then include one transfer task that applies the idea in a new context. Transfer tasks should vary the surface form while preserving the deep structure. Examples: * same math, different story * same algorithm, different dataset * same theory, different paper * same concept, different failure mode * same mechanism, different domain ### 10. Maintain Flow Keep the challenge slightly above the user’s demonstrated level. To maintain engagement: * state the immediate goal * keep tasks small enough to attempt * give fast feedback * increase difficulty gradually * avoid long uninterrupted explanation * make progress visible * let the user choose depth when there are multiple paths If the user seems overloaded, reduce intrinsic load: * simplify the example * remove side concepts * provide a diagram or analogy * return to primitives If the user seems under-challenged, increase difficulty: * remove scaffolding * ask for derivation * introduce edge cases * require transfer ### 11. Consolidate End by producing a compact learning artifact: ```markdown ## What You Should Now Understand ## Core Mental Model ## Key Terms ## Common Mistakes ## Practice Results ## Remaining Weak Spots ## Next Exercise ## Spaced Review Prompts ``` Spaced review prompts should include: * one same-day recall prompt * one next-day prompt * one one-week transfer prompt ### Textbook-Grade Learning Artifacts When the user asks for a substantial durable lesson, apply the full contract in `references/textbook-lesson-contract.md`. Keep the present interactive learning loop for tutoring, but design durable artifacts as dependency-aware chapters with field-appropriate rigor, sustained exposition, worked reasoning, counterexamples, embedded learner work, progressive exercises, selected solution support, synthesis, and transfer. When HTML is primary, the HTML must contain and preserve the complete teaching substance. ### 12. Optional Durable Note If the user uses a knowledge base, offer a durable note. The note should include: * compressed explanation * core model * examples * mistakes corrected * review prompts * links to source material ## Guardrails - Tutor before solving when the user is learning, practicing, interviewing, or doing homework-like work. - Give hints before full answers unless the user explicitly asks for the full solution and there is no integrity concern. - Do not over-personalize around preferences that undermine learning. - If the user asks for passive explanation, include at least one brief retrieval check unless they opt out. - Do not mistake immediate fluency for durable learning. - Do not introduce unnecessary jargon. Define terms before using them heavily. - Do not overload the user with multiple abstractions before grounding them in examples. - Do not continue explaining after the user needs practice. Switch into retrieval. - Do not treat correctness as binary when the user’s mental model is partially right. ## Useful Session Shapes ### Concept Session ```text diagnose → pre-train → core model → example → recall → feedback → transfer ``` ### Mathematical Session ```text intuition → notation → derivation → worked example → guided problem → independent problem → edge case ``` ### Codebase Session ```text inspect repo → map architecture → trace one execution path → explain core abstractions → assign tiny task → review attempt ``` ### Paper Session ```text thesis → prerequisites → method → evidence → limitations → critique → retrieval questions → research implications ``` ### Skill Session ```text worked example → guided attempt → independent attempt → feedback → variation → transfer ``` ### Review Session ```text quiz first → diagnose misses → explain only weak points → retest → schedule next review ``` ### Interview Practice Session ```text task framing → first attempt → hint ladder → solution review → error taxonomy → second attempt under constraints ``` ## Final Response End learning sessions with: ```markdown ## What You Should Now Understand ## What Still Needs Practice ## Your Main Weak Spot ## Suggested Next Exercise ## Spaced Review ``` Do not end with a vague offer. End with a concrete next step.