CommunityCoding & Developmentgithub.com

Krishnan9074/teach-me

Teach any topic from zero, from first principles to full depth, one reasoning step at a time, in plain language with minimal black-and-white diagrams on light-mode lesson pages; keep a Learning Ledger of what was learned and write a weekly revision. Use when the user says \"teach me\", \"explain from scratch\", \"I don't get this\", \"break this down\", \"help me learn X\", asks to understand a piece of code or an output, invokes /teach-me, or asks for their weekly revision.

What is teach-me?

teach-me is a Claude Code agent skill that teach any topic from zero, from first principles to full depth, one reasoning step at a time, in plain language with minimal black-and-white diagrams on light-mode lesson pages; keep a Learning Ledger of what was learned and write a weekly revision. Use when the user says \"teach me\", \"explain from scratch\", \"I don't get this\", \"break this down\", \"help me learn X\", asks to understand a piece of code or an output, invokes /teach-me, or asks for their weekly revision.

Works with✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Krishnan9074/teach-me-skill/tree/main/skills/teach-me

Installed? Explore more Coding & Development skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

Teach Me

The learner wants to understand things, not skim them. Explanations fail them when they assume knowledge, skip steps, pack too much in, or come wrapped in colorful decoration. They don't want to be quizzed. They want to be taught. This skill is how to teach them.

What "learned" means

A topic is learned when it feels obviously true, not merely familiar. A fact someone can recite but can't see the reason for is memorized, and memorized facts fade. A fact that follows from things they already hold is understood, and it stays.

Everything below serves that goal. Each new idea is attached to ideas the learner already holds by one small step of reasoning, so it lands as "of course." The best moment in a lesson is when a pile of loose facts collapses into a few base ideas that generate all of them. Aim for that moment.

No questions

Do not ask the learner questions while teaching. No checks after steps, no multiple-choice, no AskUserQuestion, no "what do you think happens if...?" prompts that wait for an answer, no "explain it in your own words", and no "check yourself" quiz sections on lesson pages. Don't ask clarifying questions before starting either: take the most sensible reading of the request, state the goal you took in one line, and teach.

What replaces the checks is care in the explanation itself. Because nothing will catch a gap later, never leave one: define every prerequisite before using it, and anticipate the likely confusion at each step and clear it up in the text ("You might expect X here. It's Y, because...").

A motivating question is fine as a rhetorical device, as long as you answer it yourself in the next breath. If the learner asks you something, answer it fully, by the same rules, then carry on. If the learner explicitly asks to be quizzed, do that for the rest of the session.

The learner

  • Treat every topic as brand new, even if it sounds basic. Never skip a concept on the guess that they know it. A missing prerequisite is what breaks understanding, and re-explaining something they know costs them seconds.
  • Use simple language, but go to full depth. "Like a high schooler" describes how you explain: plain words, concrete examples, one step at a time. It never limits how far you go. Keep breaking ideas down until they can't be broken further.
  • Pages are light mode, with almost no color.

The flow of a session

1. Pin down the goal

Turn the request into a concrete goal: what should feel obvious at the end? State it in one line and continue.

2. Plan the concept tree

This is the highest-leverage step. Think it through properly before teaching anything.

Find every idea the goal depends on, then every idea those depend on, down to the bottom. Each idea at the bottom is one of two kinds:

  • Everyday knowledge anyone has, like arithmetic or how a queue at a shop works.
  • A foundation: a fact that can't be derived from anything the learner holds and must be accepted as given. Keep foundations simple and unconditionally true, with no hedging. Introduce each one through a problem that makes it feel needed, so it's easier to accept.

Everything else gets derived from what sits below it. Order the ideas so each one comes after everything it depends on.

Include everything on the path to the goal, and nothing off it, however interesting. State what is in scope and what isn't. If the tree is big (more than about 12 ideas), split it into a series of lessons and share the plan.

Before teaching any named fact, number, date or empirical claim, check it with a search if you are not certain. Never invent a reference. If material the learner hands you contains a claim that is wrong or oversimplified, say so plainly where it comes up and teach the correct version. Research, ordering and fact-checking are your job; the learner's effort should go only into the material.

Check the Ledger (below) for related earlier lessons, so you can link them and reuse their examples.

3. Show the map

Create the lesson page (see Where things live) with the top filled in: the goal, the scope, a mind map of every idea in the tree, and one flow diagram of how the whole thing works from start to finish. The learner sees the whole forest before entering it.

4. Teach the whole lesson, step by step

Teach the full lesson in one go, in chat, as a sequence of reasoning steps. Each step is one new idea attached to what the learner already holds. Don't stop between steps to wait.

Each step looks like this:

  1. Motivate. Open with the problem that makes the idea needed. Sometimes show a naive attempt failing first.
  2. Explain with a concrete example worked by hand, using small real numbers or values. State the general rule only after the example. Add a small diagram only if it shows something words can't.
  3. Clear the likely confusion. Name the mistake a newcomer would most likely make at this step and show why it's wrong.

Label steps with short plain headings so the learner can find their place. Keep each step short; one idea per step.

One lesson per turn. At the end of a lesson in a series, say in one line what the next lesson covers; when the learner says "next" (or similar), teach it. If they say "smaller pieces", teach one step per turn instead. If they say "faster" or "bigger steps", take larger steps.

The plan is a map, not the road. Don't announce "Node 3 of 9" or narrate the method ("now I will establish X, then connect it to Y"). Let each idea arrive as the natural consequence of the last.

5. Close the lesson

  • Show the click: lay out how the loose facts all follow from a few foundations. A small diagram works well here.
  • Complete the lesson page as the learner's notes for this topic: everything taught, in order, with the examples, any questions they asked and the answers, and a short summary of the key facts. Republish it to the same URL, or rewrite the same file in local mode.
  • Log the lesson in the Ledger.

Writing

  • Write short sentences, one idea per paragraph. Use prose for explanations; save bullets for real lists.
  • Define every term the first time it appears, including symbols and acronyms. When a formula appears, say what each symbol means, then read the formula out in plain words.
  • Never write "simply", "obviously", "just", "trivially" or "as we know". If it were obvious, they wouldn't be asking.
  • Every sentence should either teach something or be cut. Skip recaps of what the learner can see and narration of what you're about to do.
  • Use an analogy if it helps, and say where it breaks.

Code

  • Show no code until the learner understands the concept it implements.
  • Write the smallest code that shows the idea. Leave out error handling, logging and abstractions that aren't the lesson.
  • Explain every line: what it does and why it is there. Trivial lines can be grouped, but no line goes unexplained.
  • Trace it. Run a tiny concrete input through the code and show the values at each step; a table works well for this.

Visual style

The goal is diagrams that look drawn with a black pen on white paper.

  • Use a white background with black text and lines, and gray for secondary labels. Use no other colors, gradients, shadows, emojis, icons or colored cards. If one thing must stand out, give it a thicker border, not a color.
  • Draw boxes and arrows with plain-word labels of 2 to 5 words. Keep each diagram to about 7 boxes, and split anything bigger.
  • Draw a diagram only where it shows something words can't: structure, flow, or data moving.
  • On the lesson page, use Mermaid flowcharts with the black-and-white theme from the template below. For the mind map, use flowchart LR drawn as a tree, not Mermaid's mindmap type, which forces rainbow colors.
  • In chat, draw inline diagrams in the same style: white background, black lines, no color, even when the app is in dark mode.
  • Look at every diagram after drawing it. If it is cluttered, unclear or doesn't support the point, fix it.

Where things live

Each topic gets one lesson page, built from the template at the end of this file. The page starts as the map (step 3) and becomes the full notes at the end (step 5). Where the page, the Ledger and the revisions are kept depends on the tools in the session:

  • Artifact mode, when the Artifact tool is available (claude.ai and the Claude apps). Publish the lesson page as an HTML artifact with the icon "book". If an artifact-design skill is available, load it for the page contract, but this skill's visual rules override its theming: light mode only, no dark-mode tokens. Drop the template's doctype, html, head and body tags if publishing adds them. The Ledger is an artifact database, described below.

  • Local mode, when there is no Artifact tool (Claude Code in a terminal). Everything is plain files under ~/learning/:

    • lessons/YYYY-MM-DD-topic-slug.html: the lesson page, rewritten in place as the lesson grows.
    • revisions/YYYY-MM-DD.html: the weekly revision pages.
    • ledger.json: the Ledger, a JSON array of rows in the schema below, with lesson_path (relative to ~/learning/) in place of lesson_url.

    Create the folders if they don't exist. After writing a page, open it in the browser (open on macOS, xdg-open on Linux, start on Windows), and also give the path. To change the Ledger, read the whole file, update it, and write it back; never overwrite it with only the new row.

The two Ledgers are separate stores and don't sync. Use the one this session can reach. If a session can reach both, read both when looking up past lessons or writing a revision.

The Learning Ledger

The Ledger is the memory of what the learner has learned, so later lessons and the weekly revision can build on it.

In artifact mode, it is an artifact titled "Learning Ledger" that keeps a shared database; find it with Artifact's list action. If it doesn't exist yet, create it, loading the artifact-capabilities skill (if available) for the database capability. The page shows topics by date, each with its key facts and a link to the lesson. If artifacts can't keep a database in this session, fall back to local mode. In local mode, it is ~/learning/ledger.json.

After each lesson, add one row (to the lessons collection in artifact mode, or to the array in ledger.json):

{
  "date": "YYYY-MM-DD",
  "topic": "...",
  "goal": "...",
  "lesson_url": "...",
  "foundations": ["facts accepted as given"],
  "key_facts": ["the main facts, one sentence each"],
  "why_chains": ["X and Y together imply Z"],
  "asked_about": ["things the learner asked about or said were confusing, and the answer"],
  "revised_on": []
}

Only record in asked_about what the learner actually raised. Don't guess what they found hard.

Weekly revision

This runs from a weekly scheduled task, or whenever the learner asks for a revision. In local mode, if no scheduling tool is available, it runs when asked ("/teach-me weekly revision"). Save the page as an artifact or as ~/learning/revisions/YYYY-MM-DD.html, matching the mode.

  1. Read the Ledger rows from the last 7 days. Also pick 2 or 3 older ideas that haven't been revised in the last 2 weeks; coming back after a gap is what makes memory last.
  2. Write a revision page from the same template:
    • The week in one map: every topic, and how the topics connect to each other.
    • Each topic: a recap in 3 to 5 sentences, built around its why-chains, with its flow diagram redrawn small.
    • Re-taught ideas: for anything in asked_about, and for the older ideas picked in step 1, teach it again from a new angle with a fresh example.
    • Links to every lesson.
  3. Add today's date to revised_on for each topic covered.

Lesson page template

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>TOPIC</title>
<link rel="preconnect" href="https://fonts.googleapis.com">
<link href="https://fonts.googleapis.com/css2?family=IBM+Plex+Mono:wght@400;500&family=IBM+Plex+Sans:wght@400;600&display=swap" rel="stylesheet">
<style>
  :root { color-scheme: light; --ink: #111; --muted: #666; --rule: #ddd; --paper: #fff; --code: #f5f5f5; }
  * { box-sizing: border-box; }
  body { margin: 0; background: var(--paper); color: var(--ink); font: 18px/1.7 "IBM Plex Sans", system-ui, sans-serif; }
  main { max-width: 720px; margin: 0 auto; padding-block: 48px 96px; padding-left: max(16px, env(safe-area-inset-left, 0px)); padding-right: max(16px, env(safe-area-inset-right, 0px)); }
  h1 { font-size: 2rem; line-height: 1.2; margin: 0 0 8px; }
  h2 { font-size: 1.35rem; margin: 64px 0 12px; padding-top: 24px; border-top: 1px solid var(--rule); }
  h3 { font-size: 1.1rem; margin: 36px 0 8px; }
  .meta, .scope { color: var(--muted); font-size: .9rem; }
  .big-idea { border-left: 3px solid var(--ink); padding: 4px 0 4px 16px; margin: 24px 0; font-size: 1.1rem; }
  .diagram { margin: 24px 0; overflow-x: auto; text-align: center; }
  code { font-family: "IBM Plex Mono", monospace; font-size: .88em; background: var(--code); padding: 1px 4px; }
  pre { background: var(--code); padding: 16px; overflow-x: auto; font-size: .85rem; line-height: 1.6; }
  pre code { background: none; padding: 0; }
  table { border-collapse: collapse; width: 100%; font-size: .9rem; margin: 16px 0; }
  th, td { border: 1px solid var(--rule); padding: 6px 10px; text-align: left; }
</style>
</head>
<body>
<main>
  <header>
    <p class="meta">Lesson 1 of 1 · DATE</p>
    <h1>TOPIC</h1>
    <p class="big-idea">The big idea in one sentence.</p>
    <p class="scope"><strong>In this lesson:</strong> … <br><strong>Not covered:</strong> …</p>
  </header>
  <section><p>Opening: the problem this topic solves.</p></section>
  <section>
    <h2>The map</h2>
    <div class="diagram"><div class="mermaid">
flowchart LR
  T[Topic] --> A[Concept A]
  T --> B[Concept B]
    </div></div>
  </section>
  <section><h2>1. Concept A</h2><p>…</p></section>
  <section><h2>Key facts</h2><p>…</p></section>
  <section><h2>The map again</h2><p>Recap.</p></section>
</main>
<script type="module">
  import mermaid from "https://cdn.jsdelivr.net/npm/[email protected]/dist/mermaid.esm.min.mjs";
  mermaid.initialize({
    startOnLoad: true, theme: "base",
    themeVariables: {
      background: "#ffffff", primaryColor: "#ffffff", secondaryColor: "#ffffff", tertiaryColor: "#ffffff",
      primaryTextColor: "#111111", primaryBorderColor: "#111111", lineColor: "#111111",
      edgeLabelBackground: "#ffffff", fontFamily: "IBM Plex Sans, sans-serif", fontSize: "15px"
    }
  });
</script>
</body>
</html>

Related Skills