Book Study

For books that teach by having the reader build a persistent codebase chapter by chapter — not a standalone topic deep-dive. Use train-topic instead for self-contained topics; use this when there's a real chapter sequence and a growing project the user's code needs to live in across sessions.

Before starting a new book

1. Get the book's actual table of contents (chapter list + what each chapter builds) — fetch it from the book page or companion repo rather than guessing. If a companion repo exists, note its URL but don't clone/vendor it wholesale into this project.
2. Pick a slug (kebab-case) and create books/<slug>/:
   • progress.md — chapter checklist: chapter title, status (not started / in progress / done), date, one-line note. Seed all chapters up front from the real TOC.
   • code/ — the user's own implementation, one subfolder per chapter (e.g. code/ch02/), built incrementally; later chapters import earlier chapters' code same as the book does.
   • notes.md — short per-chapter notes in the user's own words (concepts, gotchas), not a transcription of the book's text.
3. Add a row for the book to TRAINING.md's "Books & structured courses" section.
4. Save the book/repo URLs under resources/<slug>/ per the usual convention.

Per-chapter session flow

This replaces train-topic's 5 stages — the book already provides the curriculum, so don't re-derive an overview/deep-dive from scratch:

1. Check understanding first. Have the user summarize the chapter's core idea back to you (or walk through it together if they haven't read it yet). Fill real gaps; don't just re-explain the whole chapter unprompted.
2. Code along, in order. Implement the chapter's deliverable in books/<slug>/code/chNN/ from the user's own understanding first — don't hand them the reference repo's solution upfront. Run it, debug live, fix errors together the way real hands-on work goes.
3. Compare to the reference repo only after a working attempt. Once their version runs, diff against the companion repo's implementation and discuss real differences (style, efficiency, correctness) — the comparison is the point, not a shortcut to skip step 2.
4. Validate with the book's own material. Use its actual end-of-chapter exercises and quiz questions (most technical books/repos ship these, e.g. per-chapter exercise notebooks or quiz PDFs) rather than inventing new ones — that's what the author calibrated as "did you get it." If the book doesn't have such material for a chapter, then and only then generate a short quiz via quiz-flashcards.
5. Cross-link, don't duplicate. If a chapter substantially overlaps a topic already tracked in TRAINING.md (e.g. an attention-mechanism chapter vs. an "LLMs" or "Embeddings" topic row), note the link in both places instead of writing the same material twice.

Copyright care

Work from the open-source companion repo's code and the user's own paraphrased summaries. Never reproduce substantial verbatim passages of a paid book's prose — the user owns their copy and can quote small bits themselves in conversation, but don't fetch/regenerate long excerpts of purchased text into this repo's files.

Persisting output

• Update books/<slug>/progress.md after every session: chapter status, date, note.
• Update the book's row in TRAINING.md's "Books & structured courses" section (current chapter, overall status, last-touched date).
• Always hand off atomic fact/definition-style questions (book-provided or generated) to quiz-flashcards for the CSV export — tag the source as <book-slug> ch<NN> so cards are traceable back to the book. This is the Anki deck's only input, so don't skip it.
• If the chapter's exercises/quiz were passed for the first time, add a row for <book-slug> ch<NN> to REVIEW.md at Box 1 if not already tracked, handing it off to the spaced-review skill.