LLM wikis, or how I stopped re-explaining my infrastructure to Claude

The problem

Every conversation with an LLM agent starts from zero. Close the session, lose the thread — the model that just spent an hour learning my deploy pipeline’s quirks has no idea any of that happened five minutes later. The context window is a tape measure, not a notebook. I ran into this directly today, migrating this very site’s CI off a VM-based docker-compose setup onto Kubernetes and Helm, debugging a Forgejo runner, and chasing down a DNS misconfiguration across three separate domains I run. Long session, lots of decisions. None of which the next Claude session would know about unless I wrote it down somewhere it could actually read.

So I did what I’d do if a new freelancer joined a project: I gave it a wiki.

What it actually is

Not a product, not a framework I installed. Just a wiki/ folder in this repo, full of markdown with frontmatter, linked the way I already link my personal Obsidian notes — [[wikilinks]], tags, a Home.md pointing at everything else. Claude reads it at the start of a task and writes to it as things change. I read it too, which is the whole point — unlike a vector database full of embeddings, there’s nothing in it I can’t open in a text editor and understand at a glance.

It split into three kinds of content pretty naturally, because they decay at completely different rates:

• Rules — things that basically never change. Commit message format, “never add a Co-Authored-By line,” that kind of thing. I keep these short and point to them from the root AGENTS.md so any agent framework finds them without being told twice.
• Tasks — state that changes within hours. What’s blocked, what’s done, what’s next. This is the part that actually makes an agent’s work legible across sessions. A fresh Claude session with zero memory of yesterday can open Tasks.md and know exactly where things stand, instead of reconstructing it from git log and guessing.
• Knowledge — durable facts that aren’t in the code. Which IP a domain is supposed to resolve to. Which of my three Forgejo instances is already EOL. Why a redirect got dropped during a migration. Things git blame can’t tell you, because they’re decisions, not diffs.

Why this beat the alternatives I’d already tried

The obvious competitor is RAG over a vector store — I’ve used that elsewhere. It’s good at “find the paragraph that’s semantically close to this question,” bad at “remember that we decided X instead of Y and here’s why,” because that kind of fact doesn’t cluster near anything in embedding space until you already know what to search for. A wiki entry, by contrast, gets written at the moment the decision is made, by whoever made it, in whatever shape is most useful to the next reader. It’s push, not pull.

The other competitor is “just put everything in one big CLAUDE.md.” That works until the file is a few thousand lines and loads into every single session whether it’s relevant or not. A wiki lets an agent fetch only what matters to the task in front of it.

Where it actually caught me, today

The rule-enforcement part isn’t hypothetical — it caught a mistake of mine in this exact session. I defaulted to adding a Co-Authored-By: Claude line to a commit, which is the generic instruction I usually follow. Except this repo has a standing rule against it, written down in wiki/agents/Commit Rules.md and linked from AGENTS.md. I’d pushed two commits with the line in before anyone caught it — had to rewrite history and force-push to fix it. Not a disaster, but a clean demonstration of the actual failure mode: an agent that reads a memory file treats it as true the same way it treats code it hasn’t verified, which cuts both ways. It’ll follow a documented house rule correctly once it’s found it — but it won’t go looking unless something points it there, and it’ll just as confidently act on a stale fact if nobody’s kept the file honest.

That’s the part worth being deliberate about. If every passing observation gets saved, the wiki turns into noise and you’ve lost the entire advantage — an agent skimming forty near-duplicate notes is barely better off than one with no memory at all. The useful habit is saving corrections and non-obvious decisions, not routine activity. “We migrated the deploy pipeline from kaniko+SSH to buildx+Helm, here’s why” earns its line. “Ran npm install” doesn’t.

Keeping it honest

A wiki two humans and a handful of agent sessions have all edited needs the same discipline a codebase does, which is exactly why it lives inside the git repo instead of as some bespoke “agent memory” database bolted on the side. Git gives me blame, diffs, and revert for free. Today’s session updated Tasks.md probably a dozen times over the course of debugging CI, DNS, and a cert-manager issue — each one a small, reviewable commit, same as any other change to this repo. By the end, anyone (human or agent) opening that file cold could tell exactly where the zeidler.dev deploy stood, without reading the conversation that produced it.

That’s the trade I’m making: a little bit of discipline about what’s worth writing down, in exchange for not having to re-explain my own infrastructure to a blank slate every single time.