git:20260710.355dbf7 to git:20260712.ec5cfa4

---

name: learn

description: >-

Personalized tutor with memory across sessions — "teach me X, at my pace."

Interviews the learner once (goal, current level, session length), builds a

out/learn/<topic>.md, so every session resumes where the last one ended and

re-drills what was missed. Keyless; verifies version- or fact-sensitive

content via web search with cited sources instead of trusting memory. Use

when the user wants 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 on a

topic 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).

```markdown

# 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

## Syllabus <!-- status: ☐ not started · ◐ taught, not passed · ✓ passed -->

1. ✓ <unit — one teachable idea>

2. ◐ <unit>

## Sessions

| # | Date | Unit | Warm-up | Check | Notes |

|---|------|------|---------|-------|-------|

| 1 | 2026-07-05 | 1. <unit> | — | 3/4 | confused X with Y |

```

## 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.

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.

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:

```

- [ ] Unit taught (concept → example on their background → misconception)

```

3. **Teach the unit:** the concept, then a worked example grounded in the

learner's stated background, then the most common misconception and why

it's wrong. Match depth to the session length; **one unit only** — resist

finishing the syllabus early. If the unit involves anything

version-sensitive, verify before asserting (same rule as NEW step 2).

4. **Active-recall check:** 2–4 questions or one small exercise applying the

5. **Update the log:** unit status (✓ needs a passed check — being taught is

only ◐), session row, misses into the review queue.

6. **Preview:** one line on what the next session covers, and anything worth

doing between sessions (a ≤15-min hands-on task when the topic allows).

## Guardrails

- **No fabrication.** Stable fundamentals from knowledge; anything

version-, date-, price-, or API-sensitive gets verified via web search and

cited inline. If unverifiable, say "as of my knowledge" explicitly.

- **Wait for answers.** Recall only works if the learner retrieves. Never

fill in their answer, never grade an answer they didn't give.

- **Honest grading.** A wrong answer marked right poisons the log. Weak spots

- **One unit per session.** Durable beats fast. The syllabus is the pace.

- **The log is the learner's.** Human-readable, hand-editable, theirs to

commit or ignore, and respected — never overwrite their manual edits.

- **Keyless.** Never ask for API keys; degrade gracefully (no web → teach

from knowledge and label freshness honestly).