Keep a readable per-topic memory for Claude Code across twenty work streams

Peeters juggles more than twenty topics across a client, an employer and side projects, each spread over repos, Jira, mail and folders. Each Claude Code session started from zero. Over about four days, mostly by talking to Claude, Peeters built a system: one Markdown doc per topic with location, dated status, decisions with reasons and open items, plus an index. Rules in the global CLAUDE.md tell Claude to read the index and topic doc first and update the doc after progress unprompted, and a Stop hook reminds it once if it forgot. Slash commands triage new ideas against existing topics, search across docs, propose cleanups, and plan a sprint by estimating open items and reading the calendar read-only for holidays. A cheaper-model subagent reads mails Peeters drags into a per-topic Outlook folder and returns only a digest of decisions and deadlines. A single local HTML file serves as the dashboard.

Starting a session now takes one sentence, "continue with topic X", instead of about five minutes of explaining. The mail subagent cut the text the main session handled for the first real thread from about 78 KB to 14 KB. Ideas, cleanups and sprints all stop for approval, and nothing writes to the calendar; Peeters imports an .ics file himself. When Peeters packaged it as a repo, a fresh Claude agent installed it from INSTALL.md into a fake home folder, and it found fifteen unclear spots in the instructions.

Token cost came from raw data in the main conversation, not the docs, so the rules say check sizes before loading and send bulk reading to a smaller model. It runs on a locked-down corporate laptop with no new connections to client systems: Outlook is read locally and Jira comes in as a CSV export. Keep client, employer and personal contexts strictly apart.