/learn

name: learn
description: >-
  Personalized tutor with memory across sessions — "teach me X, at my
  pace." Builds a syllabus with a pass rubric per unit, teaches one unit
  per session: a recall quiz on what's due (date-based spaced repetition),
  examples matched to your background, and an active-recall check graded
  against the rubric with confidence tags. Progress and weak spots persist
  in out/learn/<topic>.md, so sessions resume and re-drill what was missed;
  fact-sensitive content is verified by web search, not memory. Keyless.
  Use to learn or study a topic — e.g. "/learn rust ownership", "teach me
  kubernetes", "quiz me on X", "continue the SQL lessons"; "/learn" alone
  lists topics in progress. For community buzz use pulse; for choosing
  between technologies use verdict.

learn — personalized tutor with memory

`/learn <topic>` — start or continue learning a topic `/learn` — list topics in progress and what's due `/learn quiz <topic>` — quiz-only session (no new material)

Answer one question per session: **what should this learner do for the next N minutes to durably advance toward their goal?** One unit per session, active recall before and after, everything scored and remembered. The point is durable learning, not an impressive wall of text.

This skill is deliberately **keyless** (native `WebSearch`/`WebFetch` only, when verification is needed) and **human-paced**: the learner answers real questions in chat; you grade what they actually wrote.

Modes (auto-detect)

• **NEW** — no `out/learn/<slug>.md` exists for the topic → interview + syllabus.
• **CONTINUE** — a log exists → run the session loop from where it left off.
• **STATUS** — `/learn` with no topic → summarize all logs: per topic, progress

(`x/y` units), last session date, review items due, and a suggested next step.

• **QUIZ** — "quiz me" → recall-only session from the review queue + covered

units; grade, update the log, teach nothing new.

The learning log — memory across sessions

One file per topic: `out/learn/<slug>.md` (`<slug>` = topic lowercased, non-alphanumerics → hyphens). It is the skill's entire memory and it is the learner's file too — plain markdown they can read and edit. Respect manual edits (a unit hand-marked done stays done; ask nothing).

# learn log: <Topic>

## Learner
Goal: <what they want to be able to DO> · Level: <self-described start point>
Background: <relevant experience to hook examples onto> · Session length: ~<N> min
Freshness: <stable — teach from knowledge · fast-moving — verify each unit before teaching>

## Syllabus                <!-- status: ☐ not started · ◐ taught, not passed · ✓ passed -->
1. ✓ <unit — one teachable idea>
   pass: <the check question/exercise that proves it> · rubric: <2–3 criteria>
2. ◐ <unit>
   pass: <…> · rubric: <…>

## Review queue            <!-- weak spots; due dates, not session counts -->
- <item missed> — missed 2026-07-05 (conf: sure) · due 2026-07-06 · passes 0/3

## Sources                 <!-- verified references; check here before searching again -->
- <title> — <url> · verified 2026-07-05 · covers: <units/claims>

## Sessions
| # | Date | Unit | Warm-up | Check | Notes |
|---|------|------|---------|-------|-------|
| 1 | 2026-07-05 | 1. <unit> | — | 3/4 | confused X with Y |

**At the start of every run:** read the log if it exists. **Write as you grade, not at goodbye:** update the log immediately after each graded step — warm-up scores right after the warm-up, check results right after the check. A crashed or compacted session must not lose answers the learner already gave. Compute dates with `date +%F`, never guess. Older logs (session-number dues, no rubrics, no `Freshness:` line or `## Sources` section) upgrade in place on the next run: session dues become dates (due today), a unit's rubric is written when it's next touched, and a missing freshness verdict is judged and written before any teaching. **Supersede, don't delete:** a revised unit or rubric strikes the old line and adds the new one — how the plan and the learner's understanding evolved is itself signal for future sessions.

NEW — interview, then syllabus (human-in-the-loop)

1. **Interview once**, in one compact question set (`AskUserQuestion`): the **goal** as an ability ("what do you want to be able to *do*?"), current **level** and relevant **background** (their stack/domain — examples get hooked onto this), and preferred **session length** (~15/30/45 min). Skip anything already clear from the request. 2. **Freshness check (effort-scaled):** for stable subjects (math, algorithms, an established language) draft from knowledge. For fast-moving subjects (a tool, framework, API, anything with versions or pricing) do **one** light `WebSearch` pass first to confirm the current major version and any recent breaking changes — so the syllabus isn't stale on day one. Cite what you verified. Don't fan out sub-agents; this is a check, not research. **Record the verdict** as the log's `Freshness:` line — `stable` or `fast-moving` — so CONTINUE sessions inherit the decision instead of re-judging it, and seed `## Sources` with anything you verified. 3. **Draft the syllabus:** 5–12 units, each **one teachable idea** sized to a session, sequenced so every unit builds on passed ones, ending at the goal. **Write each unit's pass check now** — the question or micro-exercise that will prove it, plus a 2–3-criterion rubric — so later grading is against a contract written before the teaching, not the tutor's mood after it. Present it and let the learner reorder/cut/add before saving. Then save the log and either start unit 1 (if the session has time) or stop cleanly.

CONTINUE — the session loop

Copy this checklist into your working response and tick items as they complete — the session isn't done until every box is ✓ or consciously skipped with a stated reason:

- [ ] Log read; reviews