Train Topic

Runs the fixed 5-stage learning flow the user wants for every topic, and keeps TRAINING.md and topics/<slug>/ in sync so progress persists across sessions.

Before starting

1. Read TRAINING.md. If the topic already has notes (in progress or later), read topics/<slug>/README.md and resume from where it left off instead of restarting the overview.
2. If the user supplied a file or link as source material, save it under resources/<slug>/ first (copy local files; for links, note the URL and fetch/summarize as needed), then use it as a primary source alongside your own knowledge.
3. Pick a slug for the topic (kebab-case, matches the topics/ folder name) if one doesn't already exist in TRAINING.md.

The 5 stages

Work through these in order in a single session where practical. For large topics (e.g. "RAG", "Kubernetes on EKS"), it's fine to split across sessions — just checkpoint status in TRAINING.md after each stage.

1. Overview — what it is, why it exists, where it fits relative to adjacent topics the user is also studying (e.g. relate RAG to embeddings + vector DBs already on their list). Keep this to the level of a strong intro, not exhaustive.
2. Deep dive — mechanics, key concepts, trade-offs, common pitfalls, how it compares to alternatives. This is the section worth the most detail.
3. Hands-on practice — a runnable exercise: code snippet, CLI walkthrough, or config example the user can execute. Prefer minimal, real, working examples over pseudocode. If you have a runtime available, run it yourself first and fix anything broken before handing it to the user.
4. Real-world application — 1-3 concrete scenarios where this shows up in production or in an FDE/solutions-engineering context, tying back to TRAINING.md's "Company / role prep" section when relevant.
5. Validation — a short quiz (5-10 questions, mixed format: multiple choice, short answer, "explain this to me") or a teach-it-back exercise. Don't mark the topic mastered in TRAINING.md until the user has actually attempted validation and done reasonably well — reviewed is the right status if they stop before validating.

Flag explicitly anything that's fast-moving or you're not fully certain is current (model names, pricing, API surface, service names) rather than stating it as settled fact — this domain changes monthly.

Persisting output

• Write/append the session's material to topics/<slug>/README.md. Structure it with the 5 stage headers above so future sessions (and future-you) can see what's covered.
• Always hand off to quiz-flashcards to export atomic fact/definition/term-style questions from the session as CSV cards (not the open-ended "explain this to me" ones — those aren't a good Anki card format) — this is the Anki deck's only input, so don't skip it just because the session's quiz wasn't the primary focus.
• Update the topic's row in TRAINING.md: status, last-touched date (use the actual current date), and a one-line note (what was covered / what's left).
• If validation passed for the first time (or the topic just moved to reviewed/mastered), add a row for it to REVIEW.md at Box 1 if it isn't already tracked there — this hands it off to spaced-review for scheduled open-ended re-testing (teach-it-back, system-design-style recall). Don't add a row before validation. This is separate from the Anki export above — see "Anki vs spaced-review" in the spaced-review skill for the division of labor.