The Wiki That Never Goes Stale: Let Your Coding Agent Own the Docs

Every team we work with has the same three problems. Project knowledge is scattered across wikis, chat threads, old tickets and people's heads. Coding agents get too little context and guess, or the whole codebase and get slow and expensive. And the wiki drifts out of date, because maintaining it is nobody's job.

Our proposal: a small markdown wiki inside the repo, maintained by the agent itself. Here's how it works, plus a sample repo you can clone today.

Built on two open patterns

In April 2026, Andrej Karpathy published the LLM Wiki pattern: an agent builds and maintains small, interlinked markdown pages instead of re-deriving answers from raw sources every session. In June, Google Cloud formalised it as the Open Knowledge Format (OKF), a vendor-neutral spec for those pages.

Both are patterns, not products. Claude Code or a similar agent does the work. No new platform, no database, no lock-in.

Three parts, all in the repo

• Router. CLAUDE.md (or AGENTS.md) at the repo root, under 150 lines: what the product does, a code map, top conventions and an index of wiki pages. It's the only file the agent always loads.
• Wiki. A docs/ folder with one page per topic: architecture, data model, each business module, conventions and gotchas. Under 200 lines each.
• Rules. Standing instructions in CLAUDE.md that make the wiki the agent's job: read only the relevant pages before coding, update them after.

What it looks like

The sample repo is a small CRM:

core-crm/
├── CLAUDE.md          ← router: always loaded
├── docs/              ← the wiki: one page per topic
│   ├── architecture.md
│   ├── data-model.md
│   ├── contacts.md
│   ├── deals.md
│   ├── pipeline.md
│   ├── conventions.md
│   └── gotchas.md
├── src/
└── tests/

Running several repos? CLAUDE.md can also link to company-wide standards for coding, security and prompting, so every repo follows the same patterns.

Each page is plain markdown with an OKF header. OKF only requires type; the other fields tell the agent what the page covers and how fresh it is:

---
type: concept
module: deals
updated: 2026-09-14
status: current
---
# Deals
Amounts are integer cents. A deal can only be won from proposal.

Keeping it current

This is where every wiki dies, so docs become part of the definition of done. Whoever makes the change, agent or developer, updates the affected pages in the same pull request as the code.

A review gate makes it stick. A PR checklist is the minimum. The sample repo also has a CI check that fails any PR changing src/ without touching docs/, unless it's labelled docs-not-needed.

Two prompts do the work

A bootstrap prompt runs once. It reads the code module by module, folds in your existing Confluence or Notion pages, and generates the router and wiki. Where old docs contradict the code, the code wins.

Standing rules in CLAUDE.md cover every session after that:

• You own the wiki. Keeping it accurate is part of every task.
• Before coding, load only the pages relevant to the task.
• After any change, update the affected pages and their updated date in the same branch.
• If code and docs disagree, trust the code and fix the docs.

Rolling it out

• Day one: bootstrap. Run the prompt, then review the generated pages as a team. That review is the main human effort.
• A few hours: wire the workflow. Add the rules, the PR checklist and, optionally, the CI check.
• Two sprints: pilot. Use it on real tickets, fix drift as you find it, then roll out to other repos.

Try it in five minutes

Clone infonex/agent-maintained-wiki, run npm test, open your coding agent and ask: "Can a deal skip from lead to proposal?" It should answer from pipeline.md without reading the codebase. Then ask it to add a pipeline stage, and check that the docs change with the code.

Why it's worth it

Knowledge lives in the repo, versioned and reviewed with the code. Context stays small, so token costs drop. Onboarding becomes "ask the agent". And the docs stay current by design, because updating them is part of every PR. OKF is still a young spec, but this is just markdown in git, so you're never locked in.

Want this across your repos?

We help teams roll out agent workflows that hold up in production. Get in touch and let's scope it.