Within a session, Claude Code remembers everything. That's what the context window is for. The problem is what happens between sessions: you close the terminal and everything it learned (the bug that took a day to find, the deploy quirk, the architectural decision) stays locked in that chat, unrecoverable from the next one. The model isn't forgetful; the knowledge just doesn't survive the session.
I'm a high-school CS teacher in Italy who ships software in the gaps of the day: 15+ live products, from tournament platforms and booking systems to a card game with ELO rankings and mobile apps on the App Store and Play Store. The long tail is the fun part: the ESP32+RFID system that opens the doors and meters the showers at beacharena.it (with a Telegram bot for ops), an industrial remote-control dashboard born from reverse-engineering a proprietary protocol, an AI assistant that reads school circulars over Telegram, and the portals parents use to sign school paperwork with an email OTP. All built and maintained with Claude Code, solo. At that scale, session amnesia is a tax on every working hour.
So I built a memory system: an implementation of Karpathy's LLM Wiki pattern with a promotion gate on top. I've been running it since April 2026. This week I open-sourced the result:
claude-kb-workflow.
The architecture: three tiers
Messy sessions → LLM Wiki (living synthesis) → Stable KB (authoritative truth)
↑ ↑
/kb-ingest /kb-promote (only when mature)
The promotion gate is what keeps the system honest. Everything goes into the wiki cheaply: session summaries, decisions, lessons. But knowledge only gets promoted to the stable KB when it has earned it: verified in production, seen in 2+ projects. The wiki is allowed to be wrong. The KB is not. Without that gate, your knowledge base fills with junk and you stop trusting what it quotes back. (Ask me how I know.)
After four months, the wiki holds 80+ interlinked pages of projects, concepts, lessons, and decisions. Opened as an Obsidian graph: one cluster per project, half a dozen concepts acting as hubs, and a long tail of pages with two links each.
Three stories from running this
1. My multi-agent system was silently dead for months. I had 10 specialist subagents (backend, frontend, devops...). Claude Code registers agents from YAML frontmatter. An editor had escaped the delimiters (\--- instead of ---), so it registered none of them. No errors. Nothing. Multi-agent work still happened, because Claude Code's built-in generic agents kept running in parallel, which is exactly why nothing looked wrong. What was dead was the part I'd designed: the routing by domain and by model tier. The orchestra played; the sheet music I thought it was following didn't exist. Ten agents, no errors, months. The docs now open with a 30-second check: ask Claude which subagents it can see.
2. I recovered 3 months of lost knowledge from transcripts. I stopped ingesting sessions for a busy quarter. Instead of accepting the loss, I pointed 10 read-only agents at Claude Code's local transcript files (~/.claude/projects/**/*.jsonl), one per project, in parallel, each one cross-checking what it read against the repo's git history, because commit messages are the other half of the story. An hour later I had 15 project pages back, including two products I'd never documented. The transcripts are still on disk. So is the git log.
3. The reviewer caught its own boss. The system has a mandatory rule: before any work is declared done, a reviewer subagent (running on a stronger model) audits it. On its first run it produced 26 findings on a release I'd prepared, including a factual error in docs/orchestration.md`, which the orchestrator had drafted (I claimed subagents can't delegate; the reviewer proved otherwise by having the delegation tool in its own hands). I corrected the doc and kept the rule.
What's in the repo
- The wiki → KB pipeline: 5 slash commands (
/kb-ingest,/kb-query,/kb-promote,/kb-lint,/kb-output) + templates - 12 orchestrated subagents (2 orchestrators + 10 specialists, correct frontmatter included, see story #1)
- 30 patterns paid for in production: multi-tenant single-DB, payment webhooks that lie, sync-selector deadlocks, cold-cache page speed...
- 6 methodological skills Claude picks up from their description, when the description matches (root-cause-before-fix, evidence-before-done, design-approval-first...)
- Knowledge disaster recovery: how to make your entire dev setup 100% restorable (repos for knowledge, vault for secrets, nothing else matters)
- Install:
git clone+./scripts/install.sh+ restart Claude Code. First command to try after a session:/kb-ingest your-project
It's complementary to skills frameworks like Superpowers/GSD/gstack: they tell the agent how to run a session, while this decides what survives it. Install both.
Docs are bilingual: an English front door with native Italian alongside (I'm a teacher and built this partly for my students, and Italy has few native resources on this).
Agent/skill content is still Italian: the architecture is language-neutral, and English translations are the most welcome contribution.
Repo: https://github.com/thomascasali/claude-kb-workflow
I'm Thomas, a teacher by day and an indie dev in the gaps between, from the Italian Riviera. Why give this away? Because the method gets copied anyway; the experience doesn't. If you try the toolkit and something breaks or an approach seems wrong, open an issue: being proven wrong is how half of these patterns were born.
Top comments (0)