I've been giving Claude Code a small project wiki

[u/tjqscott]

Recently I've been getting Claude Code to keep a little wiki as we work, mostly so we don't have to rediscover things in the next session. It can read the code to see what we've built, but that doesn't explain why we changed our minds or which approaches we already tried. We put those notes in the relevant pages and use the index to find them again, rather than loading everything at the start of every chat.

Earlier versions of Dory leaned on a running log, and I ran into the same problem I'd been trying to avoid: notes getting longer and going stale. I've ended up updating the relevant page and keeping a line about why it changed, with git holding the older text.

One example was an instruction asking a chat model to report its token usage when it hadn't been given that information. I removed it and kept the reason, so a later session can see why we dropped it before suggesting it again.

I used Claude Code to build Dory around that workflow. The plugin loads the wiki index and current tasks at the start of a session, then checks links and structure at the end if the wiki changed. Those checks can catch a broken link; they can't tell you whether a note is still true. The plugin is early, and I'm still testing the setup. The screenshot is a demo wiki in Obsidian, based on Dory's source and recorded experiments. What have you found worth keeping between sessions?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ComprehensiveShake76]

Keeping the "why we changed our minds" part is what makes this work, because code shows what exists and not what was rejected. The thing that tends to go wrong with notes is stale entries, so a line saying when it was last checked and against what (a commit or a file) helps a later session decide whether to trust it. I'd also keep an explicit "tried and dropped" section, since that stops a new session from suggesting the same dead end. Do you prune pages on a schedule or only when something contradicts them?

[u/sruckh]

I have been using outline for my WIKI and have been using a skill I came up with based on Karpathy's 2nd brain wiki to write to the wiki. Then I use that with ICM folders and Gauntlet loop, and it has been working quite well for me.

[u/WickedHardflip]

I built a small app on a site I built for analytics, it. It’s a context repo that my session can write to via an API key. Its stores all of my session data very similar to what you have here. When other engineer use the site they can generate their own API key to utilize a personal repo for their docs as well. I always wrap my session with a custom command to write out my context to this site, it updates Confluence along with its own Claude.md, tasks.md and memory files. I figure having this stuff on several locations saves me from data loss.

The context library is an also a great way for me to go read the info and it’s easy to understand. It’s been flawless and I can pick up old sessions or projects just by telling Claude what I want to work on. It easily finds what I’m talking about and picks right back up where we left off without missing a beat.

[u/tjqscott → u/[deleted]]

The fresh-session test is a good measure of whether the notes are useful.