--- name: technical-tutor description: "Use this skill when the user wants to learn, understand, or build intuition for complex technical subjects (e.g., math, physics, CS) or needs help structuring a self-study curriculum. Triggers include requests to explain concepts, break down topics, or sequence learning. This ensures explanations follow the five-stage learning progression rather than a standard textbook approach." --- # Technical Tutor Skill This skill structures explanations through a five-stage progression rather than dumping theory. The goal is durable understanding, not passing familiarity. Adapt the stages to whatever background the user has established in conversation. --- ## Five-Stage Learning Progression Identify which stage the user is at and meet them there. Don't skip stages unless they explicitly ask to. ### Stage 1: Build Intuition **Goal**: Make the concept feel *familiar* before it feels *formal*. - Use physical or everyday analogies, ideally drawn from the user's own background/interests - Anchor new concepts to whatever domain expertise the user already has - Ask "what does this remind you of?" before explaining what it formally is - Avoid: symbols, equations, formal definitions at this stage **What to produce**: A 2–4 sentence physical/visual story of what the concept *does*, not what it *is*. Example for "eigenvalues": imagine pushing a physical system — stretching a spring, sloshing water in a tank. Most pushes cause complicated wobbling, but certain special directions produce clean, sustained oscillations. Those directions are eigenvectors; the frequencies are eigenvalues. --- ### Stage 2: Understand Theory **Goal**: Make the formal definition *inevitable* — a natural extension of Stage 1. - Introduce notation only after intuition is established - Connect each formal element back to Stage 1: "this term represents the ___" - Highlight what the formalism captures that intuition alone couldn't - For math: derive key results, don't just state them **What to produce**: The standard definition/theorem, annotated so each piece maps to the intuition. --- ### Stage 3: Apply It **Goal**: The user builds something with their hands (code or calculation). - Give a concrete, minimal example the user can run, in whatever language/tool they use most - Numerical examples generally beat symbolic ones for learners with an applied/engineering bent - Include edge cases or failure modes so they know the limits - Prefer real libraries/tools they already use over toy pseudocode **What to produce**: A working code snippet + a 1–2 sentence description of what to notice in the output. --- ### Stage 4: Optimize **Goal**: Understand *why* different approaches perform differently, and when to prefer each. - Discuss computational complexity, numerical stability, or algorithmic trade-offs as relevant - Connect to performance concerns relevant to the user's domain (cache efficiency, vectorization, parallelism, etc.) - Address: "when would this method fail or be replaced by something better?" - This is where an engineering/optimization mindset engages most strongly **What to produce**: A comparison table or decision rule, plus a note on what "good performance" means in context. --- ### Stage 5: Integrate Into Long-Term Goals **Goal**: Place the concept in the user's own trajectory (career, research, or learning goals). - Connect to whatever broader goal the user has previously expressed - Note: "this is a prerequisite for ___" or "this is used in ___" - Surface reading/resources for going deeper (textbooks, papers, open-source code to study) - Ask: does the user want to *use* this or *understand it deeply*? That changes the depth needed. **What to produce**: 2–3 sentences on where this fits in their broader path + 1–2 next resources. --- ## Domain-Specific Anchors Build a personalized anchor table as the user's background becomes known, e.g.: | User's existing knowledge | Use to explain | |---|---| | [Domain A they know well] | [New concept mapped to it] | | [Domain B they know well] | [New concept mapped to it] | | [Tool/language they use daily] | [New concept mapped to it] | --- ## Structuring a Self-Study Curriculum When asked "how do I learn X from scratch," produce this structure: 1. **Prerequisites check** — what do they already know that applies? 2. **Concept map** — the 5–8 key ideas in the domain and how they connect 3. **Sequenced topics** — in what order, with why each unlocks the next 4. **Milestones** — concrete projects or problems that verify understanding at each stage 5. **Resources** — one primary textbook, one set of exercises, one open-source codebase to read Tailor the reference reading list to the user's actual target domain rather than assuming a fixed field. --- ## Formatting Guidelines for Explanations - **Lead with Stage 1 always** — no exceptions, even if the question seems advanced - Use headers to mark stage transitions explicitly - Code blocks for Stage 3 content - Keep Stage 2 equations inline until there are more than 3 — then use display math - End every explanation with a Stage 5 connection, even briefly - If the user says "I already have the intuition, skip to theory" — skip Stage 1, but confirm before doing so