Turns work into retained understanding.
Most of a second brain is built to take work off you. This does the opposite: it makes the work leave something behind.
Concepts that were load-bearing in real work — a constant you had to derive, a failure mode you hit in production, a decision and the reasoning behind it — become atomic notes, and those notes become spaced-repetition cards surfaced in your daily briefing. Two minutes a morning, answers withheld.
The premise is that a task completed silently is a partial success: the load went down but your ceiling did not go up.
Learning fails on a one-hour-a-week budget when it competes with work for calendar space. So it doesn't. It routes through surfaces that already exist:
Zero marginal cost — work links to its own reasoning. PRs and issues stay exactly as concise as they already are, and carry a one-line pointer to a note where the reasoning lives. Reading the issue leads naturally into the note. This is the highest-volume channel, and the only one that scales with a busy week rather than against it.
Do not inline derivations into PR bodies. They are write-once, unsearchable, and buried the moment they merge — the worst available store for anything meant to be reused, and bloating them degrades their actual job.
Two minutes daily — retrieval practice.
Cards drawn exclusively from live systems, so review doubles as system
understanding and never decays into trivia. Delivered in /today with the
answers withheld, because a card only works if retrieval is attempted first.
One hour weekly — the block. Sequential curriculum blocks, each ending in an artifact that changes a running system. A block that produces no such change hasn't landed; carry it rather than passing it.
Breadth comes from the work, depth comes from the queue: the first two channels span every domain at once, the third runs one track at a time.
Copy or clone into your Datacore modules directory:
git clone https://github.com/datacore-one/datacore-tutor \
~/Data/.datacore/modules/tutorCreate a deck directory and your first deck:
mkdir -p ~/Data/0-personal/3-knowledge/decks
cp ~/Data/.datacore/modules/tutor/decks/example.yaml \
~/Data/0-personal/3-knowledge/decks/Run /today — the Concept Review section appears when cards are due.
Deliberately. Decks hold whatever you have been working on, which for most people
means production incidents, trading positions, client details, or internal
architecture. They live at deck_dir (default
0-personal/3-knowledge/decks), outside this module, so a public
module repo can never carry private cards.
decks/example.yaml ships with this repo and contains only generic material.
lib/spaced_repetition.py due # what's due (all decks)
lib/spaced_repetition.py show <card-id> # reveal the answer
lib/spaced_repetition.py review <card-id> good # grade and reschedule
lib/spaced_repetition.py add --deck cs --front ... --back ...
lib/spaced_repetition.py stats # per-deck summaryGrades are again / hard / good / easy, on an SM-2 variant. Grade from how
recall actually went, not from politeness — a card marked good without a real
attempt corrupts the schedule and you stop seeing material you never knew.
Plain YAML, hand-editable, diffable in git. One file per domain; a new domain is a new file, with no wiring change.
deck: cs
description: |
What this deck covers and where the cards come from.
cards:
- id: some-stable-slug
front: |
The question. Anchored to a real artifact, not a textbook example.
back: |
The answer, with the derivation.
source: path/to/the/note/or/system.md
tags: [distributed-systems, resilience]Scheduling state (sched:) is written back by the script. You never write it by
hand, but it stays readable when you inspect the file.
Cards anchored to something real are worth several anchored to a chapter. The
source field is what makes review double as system understanding.
Configured in module.yaml:
| Setting | Default | What it does |
|---|---|---|
enabled |
true |
Enable the module |
deck_dir |
0-personal/3-knowledge/decks |
Where decks live. Relative paths resolve from ~/Data. Override at runtime with TUTOR_DECK_DIR |
cards_per_day |
3 |
Cards surfaced per briefing |
withhold_answers |
true |
Never print answers in the briefing |
This module has a predecessor: a knowledge-surfacing system designed in early 2026 with roughly 2,000 lines of specification, 281 lines of working code, and a passing test suite. It surfaced nothing in six months, because the five lines that would have called it from the daily briefing were never written.
Three of its design decisions are inherited here, and one is deliberately not:
Inherited — repeated failure is a signal about the item. That system retired
knowledge after three unsuccessful surfacings. Here, cards past LEECH_LAPSES
are flagged: a card you keep failing is usually a badly-written card, not a hard
concept.
Inherited — a system must report its own non-use. Its stats block was cut
during implementation, so six months of zero activity looked identical to
health. stats here leads with last activity and reviews-in-last-7-days, and
says plainly when a deck has gone dormant.
Inherited — verify integration by running it. Its completion reports
declared production-readiness for wiring that did not exist. This module's
/today hook was checked by executing the discovery path, not by assuming it.
Not inherited — context-aware selection. It is the best idea in that design:
match today's calendar and tasks against knowledge, fall back to rotation. It is
also the idea that got three zettels, a scoring function, and a five-layer
roadmap, and shipped as return None. Porting an unvalidated feature into a
system with no review history would repeat the mistake exactly. If it is added
later it belongs as a tie-breaker within the cards already due — never as an
override of the schedule.
v0.2.0 — deliberately thin. A /today hook, a scheduler, and a deck format.
Commands and a card-generating agent are intentionally not included yet. They are worth building once there is grading history showing which cards actually work, and worth nothing before that. The failure mode this module is most exposed to is building the learning system instead of doing the learning — which is not a hypothetical here, it is what happened last time.
MIT