From LLM Wiki to Agentic Knowledge Maintenance

Why the git diff, not the chat, is the real interface between you and a coding agent maintaining your wiki

Infographic generated by NotebookLM

In the first article in this series, Building a Minimal LLM Wiki (Article 1), we built a minimal LLM Wiki: a small Markdown knowledge base where source notes, concept pages, people pages, aliases, and comparison notes could be created and updated with the help of an external LLM.

In the second article, Visualising an LLM Wiki in Obsidian (Article 2), we made that wiki inspectable by using Obsidian for backlinks and local graph views, then Python for persistent reports such as audit.md and graph-health.md.

This third article starts after those two steps. The wiki now exists, and its structure can be audited, but maintenance is still a real problem. Some links point to unresolved paths. Some aliases overlap with existing concepts. Some proposed pages sound useful but are too broad or speculative. Some pages look isolated because they are unfinished, while others are intentionally isolated as demonstration pages.

A normal chat-based LLM can help if we prepare a context bundle, but the human still has to gather files, explain the current state, apply edits manually, and check the result. A folder-aware coding agent changes the workflow because it can inspect the repository, run scripts, edit Markdown files, and leave changes in the working tree.

That changes the risk profile. When a coding agent maintains an LLM Wiki, the chat is not the real interface. The diff is. The chat is where the agent explains what it thinks it did; the diff is where the human sees what actually changed.

1. The maintenance loop

The maintenance loop I want is deliberately modest:

audit → agent proposal → file edits → diff 
  → human review → maintenance log → commit

This is not autonomous knowledge management. I do not want an agent deciding what my knowledge base means. I want an agent to help with repetitive maintenance while the human remains the editor.

A useful maintenance cycle should read the wiki rules before editing, run the audit scripts that already exist, propose a small patch, distinguish mechanical repairs from editorial decisions, and expose the actual file changes through a diff. It should also record accepted, rejected, and deferred decisions so that the same proposals do not reappear without context in the next maintenance cycle.

That final record matters. Article 1 produced audit.md. Article 2 produced graph-health.md. This article (Article 3) adds one more artefact:

maintenance-log.md

The log is where the human records why a change was accepted, rejected, deferred, or deliberately left alone. Without that record, each agent run starts from a shallow understanding of the project. With it, the wiki gains a memory of its own maintenance decisions.

2. What changes from the context-bundle workflow?

In Article 2, I used a context-bundle workflow. A normal chat-based LLM cannot automatically read a local folder of Markdown files, so I had to provide selected files as context: schema.md, index.md, audit.md, graph-health.md, and several relevant wiki pages.

That method is safe and reproducible because the model can only see what I provide. It is also manual. The human prepares the bundle, asks for a plan, reviews the answer, applies the changes, and then checks the files.

A coding-agent workflow changes the access model. The agent works inside a folder or repository. It can read files, run commands, make edits, and leave those edits in the working tree. OpenAI’s Codex CLI, for example, is documented as a local coding agent that can read, change, and run code in the selected directory, while the Codex IDE extension works with VS Code and compatible editors such as Cursor and Windsurf.

I use Codex as the worked example in this article, but the pattern is broader than Codex. The same method can be adapted to Claude Code, Cursor agent workflows, Aider, or any other tool that can work against a local folder, modify files, and let the human inspect the resulting diff.

The important distinction is not the brand of agent. It is the workflow boundary. A chat LLM responds to the context you provide. A folder-aware agent works against the project state. That makes it more useful for maintenance, but it also makes Git checkpoints, schema rules, and diff review essential.

3. Make schema.md the editorial constitution

Before giving an agent access to the wiki, the wiki needs rules. In the earlier articles, schema.md described the structure of the project. In this article, it becomes more important. It is no longer just documentation; it becomes the editorial constitution that the agent must follow.

The schema should contain rules sharp enough to enforce. Vague principles such as “keep the wiki useful” are not enough, because they leave too much room for the agent to justify almost anything. A useful schema tells us what is allowed, what requires review, and what should be rejected.

Add a section like this to schema.md:

## Agent maintenance rules

These rules apply when a coding agent proposes or applies wiki maintenance changes.

### Source notes

Source notes are the basis for claims in the wiki.
An agent may add a `Related Pages` section to a source note, but it must not rewrite the original source summary, interpretation, or claims without explicit human approval.

### Concepts and people

Concept pages and person pages must not be merged.
A person page may link to related concepts, and a concept page may mention relevant people, but the page types remain distinct.

### New concept pages

New concept pages require a clear source basis.
Do not create a new concept page only because a phrase sounds important. If the concept is broad, speculative, or not yet supported by source notes, record it as deferred in `maintenance-log.md`.

### Wikilinks

Wikilink display text may be normalised mechanically.
Wikilink targets must not be changed without human review, because changing a target can change the meaning of the link.

### Existing pages

Existing pages should be updated before duplicate pages are created.
If a proposed page overlaps with an existing page, explain whether the new page is genuinely justified.

These rules give the human a basis for review. A path correction may be a mechanical repair. A new concept page may require editorial judgement. A rewrite of a source note may be a rejection. The schema turns those decisions from personal preference into project governance.

4. Setting up a folder-aware coding agent

For this article, I will describe the setup using Codex in VS Code, but the steps are intentionally transferable. What we need is a coding agent that can work inside the wiki folder, read Markdown files, run Python scripts, and leave changes in the Git working tree for review.

A minimal project might look like this:

llm-wiki-demo/
  AGENTS.md
  maintenance-log.md
  agent-maintenance-brief.md

  scripts/
    wiki_maintenance_cycle.py

  wiki/
    index.md
    schema.md
    audit.md
    graph-health.md
    concepts/
      llm-wiki.md
      retrieval-augmented-generation.md
      backlinks.md
      graph-view.md
      personal-knowledge-management.md
      memex.md
    sources/
      as-we-may-think.md
    people/
      andrej-karpathy.md
      vannevar-bush.md
    aliases/
      rag.md
    comparisons/

The important files are not all equal. wiki/schema.md defines the rules. AGENTS.md gives the coding agent persistent project instructions. scripts/wiki_maintenance_cycle.py generates a small maintenance brief. maintenance-log.md records the human’s decisions after reviewing the agent’s proposed changes.

A practical safety rule is to keep this wiki in its own dedicated folder or repository. Do not run the coding agent against your whole Obsidian vault, home directory, iCloud Drive, Dropbox folder, or personal notes archive on the first attempt. The agent should only see the files it needs for the maintenance cycle. Git gives you rollback, but folder boundaries reduce the chance that unrelated private notes or configuration files are touched in the first place. This also aligns with the general coding-agent principle of keeping sandboxing and permissions tight by default, then loosening them only for trusted repositories or specific workflows.

For Codex, the IDE extension can be installed for VS Code and compatible editors. The documentation says Codex starts in Agent mode by default, where it can read files, run commands, and write changes in the project directory; the IDE extension features page also describes the extension as available in VS Code, Cursor, Windsurf, and other VS Code-compatible editors.

That detail matters. In this workflow, assume the agent may write changes directly to your working tree. The review surface is not the agent’s summary of what it did; it is git diff against the last known-good state. This is why the checkpoint comes before the agent starts.

Create a clean checkpoint first:

# git init
git status
git add .
git commit -m "Checkpoint before agentic wiki maintenance"

If you prefer the terminal, Codex CLI can be installed with npm and launched from the project directory:

npm i -g @openai/codex
cd llm-wiki-demo
codex

The Codex quickstart documents the npm installation command and recommends Git checkpoints before and after tasks because Codex can modify the codebase.

Whichever tool you use, keep the first run small. Do not ask an agent to “clean up the whole wiki”. Ask it to read the rules, run the maintenance script, propose a few changes, and apply only one low-risk repair after review.

5. Add persistent instructions with AGENTS.md

A coding agent should not have to rediscover the project rules on every run. In Codex, this role is played by AGENTS.md as a mechanism for giving the agent additional project instructions, and the documentation describes both global guidance and repository-level project instructions.

Create this file at the project root:

# AGENTS.md

## Project

This repository is a Markdown-based LLM Wiki.
The goal is to maintain a small, readable, human-reviewed knowledge base.
The wiki is not an autonomous knowledge graph and should not be densely linked for its own sake.

## Important files

- `wiki/schema.md` defines the wiki structure and maintenance rules.
- `wiki/audit.md` records generated audit output.
- `wiki/graph-health.md` records graph-level health checks.
- `agent-maintenance-brief.md` summarises the current maintenance state.
- `maintenance-log.md` records human review decisions.
- `scripts/wiki_maintenance_cycle.py` generates a maintenance brief.

## Maintenance rules

- Read `wiki/schema.md` before proposing changes.
- Prefer small, reviewable patches.
- Do not rewrite the whole wiki.
- Do not alter source-note claims unless explicitly instructed.
- Do not merge concept pages with person pages.
- Do not create speculative concept pages.
- Do not add links only because words sound related.
- Preserve uncertainty.
- Record accepted, rejected, and deferred changes in `maintenance-log.md`.

## Done means

A maintenance task is complete only when:
- the maintenance script has been run;
- proposed changes are explained;
- the actual file diff has been reviewed;
- accepted, rejected, and deferred changes are recorded in `maintenance-log.md`;
- the working tree is ready for human commit.

Keep this file short. It should encode the rules that the agent must follow repeatedly, not reproduce the whole article. OpenAI’s best-practices guidance similarly recommends giving Codex clear repository context, constraints, and verification expectations.

6. Create a small maintenance script

The agent could inspect the wiki manually, but I still prefer to generate a maintenance brief. A script makes the workflow repeatable. It also prevents the process from becoming a vague conversation about “improving the wiki”.

Create:

scripts/wiki_maintenance_cycle.py

Use this compact version. It assumes Python 3.10 or later because it uses the str | None type-hint syntax.

from __future__ import annotations
import argparse
import re
from collections import Counter
from datetime import datetime
from pathlib import Path
WIKILINK_RE = re.compile(r"\[\[([^\]]+)\]\]")
SYSTEM_FILES = {
    "index.md",
    "schema.md",
    "audit.md",
    "graph-health.md",
    "maintenance-log.md",
    "agent-maintenance-brief.md",
    "AGENTS.md",
}

def markdown_files(root: Path) -> list[Path]:
    return sorted(
        p for p in root.rglob("*.md")
        if ".git" not in p.parts
    )

def split_wikilink(raw: str) -> tuple[str, str | None]:
    if "|" in raw:
        target, display = raw.split("|", 1)
        return target.strip(), display.strip()
    return raw.strip(), None

def normalise_target(target: str) -> str:
    target = target.split("#", 1)[0].strip()
    if not target.endswith(".md"):
        target = f"{target}.md"
    return target

def extract_links(text: str) -> list[tuple[str, str, str | None]]:
    links = []
    for match in WIKILINK_RE.finditer(text):
        raw = match.group(1).strip()
        target, display = split_wikilink(raw)
        links.append((raw, normalise_target(target), display))
    return links

def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("--root", default=".")
    parser.add_argument("--output", default="agent-maintenance-brief.md")
    args = parser.parse_args()
    root = Path(args.root).resolve()
    files = markdown_files(root)
    existing = {str(p.relative_to(root)) for p in files}
    incoming = Counter()
    outgoing = Counter()
    missing = []
    for path in files:
        rel = str(path.relative_to(root))
        text = path.read_text(encoding="utf-8")
        links = extract_links(text)
        outgoing[rel] = len(links)
        for raw, target, display in links:
            incoming[target] += 1
            if target not in existing:
                missing.append((rel, raw, target))
    no_incoming = sorted(
        page for page in existing
        if incoming[page] == 0 and page not in SYSTEM_FILES
    )
    no_outgoing = sorted(
        page for page in existing
        if outgoing[page] == 0 and page not in SYSTEM_FILES
    )
    lines = [
        "# Agent Maintenance Brief",
        "",
        f"Generated: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}",
        "",
        "Use this file as input for a small, reviewable coding-agent maintenance cycle.",
        "Do not treat every listed item as something that must be fixed.",
        "",
        "## Summary",
        "",
        f"- Markdown files scanned: {len(files)}",
        f"- Missing wikilink targets: {len(missing)}",
        f"- Pages with no incoming links: {len(no_incoming)}",
        f"- Pages with no outgoing links: {len(no_outgoing)}",
        "",
        "## Missing wikilink targets",
        "",
    ]
    if missing:
        for source, raw, target in missing:
            lines.append(f"- `{source}` links to `[[{raw}]]`; expected target `{target}`")
    else:
        lines.append("- None found.")
    lines += ["", "## Pages with no incoming links", ""]
    if no_incoming:
        for page in no_incoming:
            lines.append(f"- `{page}`")
    else:
        lines.append("- None found.")
    lines += ["", "## Pages with no outgoing links", ""]
    if no_outgoing:
        for page in no_outgoing:
            lines.append(f"- `{page}`")
    else:
        lines.append("- None found.")
    lines += [
        "",
        "## Instructions for the agent",
        "",
        "- Read `wiki/schema.md` before proposing repairs.",
        "- Prefer mechanical repairs for obvious path mismatches.",
        "- Do not create new concept pages unless there is a clear source basis.",
        "- Do not rewrite source-note claims.",
        "- Record accepted, rejected, and deferred decisions in `maintenance-log.md`.",
        "- Keep the patch small.",
        "",
    ]
    output_path = root / args.output
    output_path.write_text("\n".join(lines), encoding="utf-8")
    print(f"Wrote {output_path}")

if __name__ == "__main__":
    main()

Run it from the project root:

python scripts/wiki_maintenance_cycle.py --root wiki --output ../agent-maintenance-brief.md

The output is:

agent-maintenance-brief.md

The script does not decide what should be fixed. It only collects maintenance signals: missing wikilinks, pages with no incoming links, and pages with no outgoing links. The human and the agent still have to interpret those signals under the rules in schema.md.

7. Create maintenance-log.md

The maintenance log should be explicit enough that a later human or agent can understand why a decision was made. The rejection reason deserves its own field because this is where institutional memory lives.

Create:

maintenance-log.md

Use this template:

# Maintenance Log

This file records human review decisions from agentic wiki maintenance cycles.

## Template

### Date

YYYY-MM-DD

### Agent task

- Describe the maintenance task.

### Files reviewed

- `wiki/schema.md`
- `AGENTS.md`
- `agent-maintenance-brief.md`
- `wiki/audit.md`
- `wiki/graph-health.md`

### Accepted changes

- None yet.

### Rejected changes

- None yet.

### Reason for rejection

- None yet.

### Deferred changes

- None yet.

### Human reviewer notes

- None yet.

The point is not to document every keystroke. The log should capture decisions that matter: accepted mechanical fixes, rejected rewrites, deferred concept pages, and intentional exceptions.

8. Ask the agent for a small patch

Now open the coding agent and give it a constrained task. Avoid vague prompts such as “tidy up this wiki” or “fix all graph issues”. Those prompts invite broad edits, and broad edits are harder to review.

Use a prompt like this:

You are maintaining this Markdown-based LLM Wiki.

First, read:

- `AGENTS.md`
- `wiki/schema.md`
- `agent-maintenance-brief.md`
- `wiki/audit.md`, if present
- `wiki/graph-health.md`, if present

Your task is to propose a small maintenance patch.

Rules:

- Do not rewrite the whole wiki.
- Do not modify source-note claims.
- Do not merge concept pages with person pages.
- Do not create speculative concept pages.
- Prefer obvious mechanical repairs over broad editorial changes.
- Apply only small changes that can be reviewed in git diff.
- Update maintenance-log.md with accepted, rejected, and deferred decisions.

Start by summarising the maintenance issues you found.

Then propose no more than three changes.

Apply only the safest mechanical repair first.

The last line is important. In a tool where the agent can edit the working tree directly, “show me before applying” may not be the reliable control point. A safer habit is to start from a Git checkpoint, constrain the task, let the agent make a small edit, and then review the real file diff.

9. A mechanical repair can still need review

A good first maintenance task is not always a new concept page. Often, it is a small routing repair.

The cleanest version of this kind of repair is a direct link correction. For example, if a page contains:

[[Source: Vannevar Bush - As We May Think]]

and the maintained source note already exists at:

wiki/sources/as-we-may-think.md

then one possible mechanical repair is to point the link directly to the canonical source note:

[[sources/as-we-may-think|Source: Vannevar Bush - As We May Think]]

That kind of edit is easy to review. It does not rewrite the source note, invent a new concept page, or change any claim text. It only makes the target explicit.

In my actual Codex run, the agent chose a slightly different repair. It added a bridge page:

wiki/Source: Vannevar Bush - As We May Think.md

with the following content:

# Source: Vannevar Bush - As We May Think

This page exists as a canonical bridge to the maintained source note:
[[sources/as-we-may-think|Source: Vannevar Bush - As We May Think]].

## Related pages

- [[sources/as-we-may-think|Source note]]
- [[As We May Think]]
- [[concepts/memex|Memex]]

This was still a low-risk repair because it resolved the missing exact target without changing source-note content. It also avoided editing several existing pages at once.

However, it was not completely judgement-free. The filename contains a colon, which is acceptable on macOS but not portable to every operating system. For a cross-platform vault, especially one that may be used on Windows, the direct link correction may be safer than creating a colon-based bridge page.

This is a useful lesson. Even a mechanical agent repair can contain a small design choice. The question is not only whether the agent reduced the number of unresolved links. The question is whether the repair is portable, consistent with the schema, and small enough to review.

10. The dangerous case: a helpful edit that changes a claim

The previous example came from the real Codex run. The next example is separate: it is a constructed failure case showing the kind of edit that the same review process is designed to catch.

Suppose the agent says:

I added a Related Pages section to sources/as-we-may-think.md 
to improve navigation.

That sounds harmless. The schema allows the agent to add a Related Pages section to a source note. The chat summary may look reasonable, and the change may appear to be a simple navigation improvement.

The following is a constructed example, but it represents a real category of agent error: a model modernises historical language while presenting the edit as a harmless navigation improvement. The specific wording is illustrative; the failure mode is what matters.

The diff shows this:

- Bush described the memex as a hypothetical device for associative trails 
  through information.
+ Bush invented the memex as an early personal knowledge management system.

This is not merely a style edit. It changes the claim.

The original sentence is careful. It describes the memex as a hypothetical device and focuses on associative trails through information. The revised sentence makes it sound as if Bush invented a realised personal knowledge management system, and it retrofits modern terminology onto a historical essay.

This is a typical LLM-style maintenance error. The model makes the sentence sound more contemporary and conceptually useful, but in doing so it changes the historical claim.

Under the rules in schema.md, this edit should be rejected. The agent may improve navigation around a source note, but it must not rewrite the original source summary or claims without explicit human approval.

11. Record one cycle, not two separate stories

The constructed memex rewrite above is a separate teaching example. The actual log from my Codex run recorded a different set of decisions: one accepted bridge-page repair, one intentionally unresolved teaching example, and several deferred concept candidates.

A single maintenance cycle can produce more than one decision. The maintenance log can record all of that in one entry:

## 2026-05-24

### Agent task

Review current maintenance reports and apply one small mechanical repair only.

### Files reviewed

- `AGENTS.md`
- `wiki/schema.md`
- `agent-maintenance-brief.md`
- `wiki/audit.md`
- `wiki/graph-health.md`
- `wiki/index.md`
- `wiki/sources/as-we-may-think.md`
- `maintenance-log.md`

### Accepted changes

- Added `wiki/Source: Vannevar Bush - As We May Think.md` as a bridge page to the existing source note `wiki/sources/as-we-may-think.md`, so the exact target `[[Source: Vannevar Bush - As We May Think]]` resolves without changing source-note content.

### Rejected changes

- Did not resolve `[[concepts/compiled-knowledge|Compiled knowledge]]` in this cycle because `wiki/index.md` explicitly says it is intentionally left unresolved for the graph-health example.

### Reason for rejection

Resolving the intentionally unresolved `[[concepts/compiled-knowledge|Compiled knowledge]]` example would work against the current repo guidance embedded in `wiki/index.md`.

### Deferred changes

- `[[Coding agents]]` remains deferred because there is no existing target page and creating a new concept page would be broader than a mechanical repair.
- `[[Knowledge systems]]` remains deferred for the same reason.
- `[[Knowledge-intensive NLP]]`, `[[Non-parametric memory]]`, and `[[Dense vector retrieval]]` remain deferred because they are absent concepts rather than path mismatches.
- Possible additional bridge pages for `[[Karpathy LLM Wiki]]`, `[[Obsidian Graph View]]`, and `[[RAG Paper]]` were deferred to keep this patch to one repair.

### Human reviewer notes

Review whether additional bridge pages should be preferred over new concept pages for exact-title source links.

This is the maintenance log doing real work. It does not only say what changed. It also records what the agent deliberately did not change, and why. That matters because the remaining unresolved links are not all the same kind of issue: one was intentionally unresolved, some were absent concept candidates, and some may become future bridge-page repairs.

The log therefore becomes more than a task summary. It becomes an audit trail for editorial judgement: what was accepted as mechanical, what was rejected as contrary to the current demo design, and what was deferred because it would require a broader decision.

12. Review the actual diff

After the agent edits files, inspect the working tree:

git status
git diff

In VS Code, you can also use the Source Control panel to inspect changed files visually. The exact interface depends on the agent and editor, but the principle is stable: inspect the actual file state, not only the agent’s explanation.

For an LLM Wiki, my diff review checklist is:

Diff review checklist

1. Did the agent change only the files relevant to the task?
2. Did it preserve source-note claims?
3. Did it change any wikilink targets?
4. Did it create new concept pages?
5. Did it merge different page types?
6. Did it add links only because words sounded related?
7. Did it update maintenance-log.md with the relevant decisions?

After reviewing the file changes, check the log separately: would a future reader understand what was accepted, rejected, or deferred, and why?

This may feel strict for a small Markdown wiki. That is intentional. Small projects are where habits are easiest to build. If the wiki grows to hundreds or thousands of notes, unclear maintenance decisions become much harder to untangle.

13. What the agent should not do

A coding agent can make maintenance faster, but it should not become the authority over the knowledge base. The human still decides which structures are meaningful, which are premature, which are mechanical, and which should remain untouched.

In my actual maintenance run, the important result was not that the agent reduced every unresolved link. It was that the unresolved links were separated into different decision categories.

Intentional teaching example: [[Compiled knowledge]]. Likely decision: leave untouched. In this demo vault, wiki/index.md explicitly says that [[Compiled knowledge]] is intentionally left unresolved for the graph-health example. Fixing it would make the graph cleaner, but it would also remove the teaching case.

Deferred concept candidates: [[Coding agents]] and [[Knowledge systems]]. Likely decision: defer. These may become useful pages later, but creating them would be broader than a mechanical repair. They need a clear source basis and an editorial reason to exist.

Absent technical concepts: [[Knowledge-intensive NLP]], [[Non-parametric memory]], and [[Dense vector retrieval]]. Likely decision: defer. These are not path mismatches. Creating them would expand the wiki’s conceptual scope, so they require human review.

Possible bridge-page candidates: [[Karpathy LLM Wiki]], [[Obsidian Graph View]], and [[RAG Paper]]. Likely decision: review later. These may be valid exact-title bridge pages, but adding several bridge pages in one cycle would make the patch broader than necessary.

Accepted bridge-page repair: [[Source: Vannevar Bush - As We May Think]]. Likely decision: accept with review. This was a mechanical repair because it pointed an unresolved exact target to an existing source note without changing source-note content.

A good agentic maintenance run should not simply reduce the number of unresolved links. It should distinguish between a mechanical path repair, an intentional teaching example, a deferred concept page, and a broader editorial decision.

14. Commit only after human review

When the patch is reviewed, the human should make the final commit. Start by checking the worktree:

git status
git diff

One practical detail matters here. If the agent creates a new file, plain git diff may not show its contents because untracked files are not included in the normal diff. In my run, the new bridge page appeared in git status as an untracked file:

?? "wiki/Source: Vannevar Bush - As We May Think.md"

Open the new file directly in the editor, or ask Git to include it in the diff view without fully staging it:

git add -N "wiki/Source: Vannevar Bush - As We May Think.md"
git diff

After reviewing the actual file changes, stage only the files that belong to the maintenance patch. For this example, that may look like:

git add "wiki/Source: Vannevar Bush - As We May Think.md"
git add maintenance-log.md
git add agent-maintenance-brief.md
git commit -m "Add source bridge page and update maintenance log"

Do not automatically stage unrelated changes. In my run, the worktree also contained pre-existing changes such as AGENTS.md and wiki/.obsidian/workspace.json. Those should be reviewed separately rather than bundled into the maintenance commit.

That commit is the boundary between agent proposal and human acceptance. The agent can prepare changes, but the commit records what the human chose to keep.

If part of the patch is wrong, revert it before committing. For example:

git restore maintenance-log.md

For an untracked file created by the agent, remove it only after checking that it is not needed:

rm "wiki/Source: Vannevar Bush - As We May Think.md"

You can also use VS Code’s Source Control panel to discard selected files or hunks. The exact command matters less than the discipline: do not commit a change merely because the agent’s chat summary sounds plausible.

15. A minimal cycle to try

If you want to try this method, start small. Use a demo wiki or a copy of your real notes first.

1. Commit a clean checkpoint.
2. Run the maintenance script against the actual wiki root.
3. Ask the agent to read AGENTS.md, schema.md, and agent-maintenance-brief.md.
4. Ask for no more than three proposed changes.
5. Apply one mechanical repair first.
6. Inspect git status and git diff.
7. Review any untracked files created by the agent.
8. Update maintenance-log.md.
9. Commit only the reviewed maintenance files.

Conclusion

The first article in this series built the wiki. The second article made its structure visible. This third article turns maintenance into a repeatable, reviewable workflow.

The practical ingredients are simple. wiki/schema.md defines the rules. AGENTS.md gives the agent persistent instructions. scripts/wiki_maintenance_cycle.py generates a maintenance brief. maintenance-log.md records human decisions. The coding agent can inspect the project, propose small repairs, apply selected edits, and leave the working tree ready for review.

The diff is where the method either works or fails. If the agent adds a bridge page for a missing source target, the diff confirms the repair. If the agent quietly rewrites a source claim, the diff exposes the problem. If the agent proposes a speculative concept page, the diff lets the human decide whether the page is justified or premature.

The chat is where the agent explains itself.

The schema is where the wiki defines its rules.

The maintenance log is where decisions are remembered.

But the diff is where the human sees what actually changed.

References

• Andrej Karpathy, “LLM Wiki” GitHub Gist and related LLM knowledge-base framing. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• OpenAI Codex documentation: Codex CLI, including local terminal usage and the ability to read, change, and run code in the selected directory. https://developers.openai.com/codex/cli
• OpenAI Codex documentation: Codex IDE extension for VS Code and compatible editors. https://developers.openai.com/codex/ide
• OpenAI Codex documentation: IDE extension features, including Agent mode and VS Code-compatible editor support. https://developers.openai.com/codex/ide/features
• OpenAI Codex documentation: AGENTS.md project instructions. https://developers.openai.com/codex/guides/agents-md
• OpenAI Codex documentation: quickstart guidance, including CLI installation and Git checkpoints. https://developers.openai.com/codex/quickstart
• OpenAI Codex documentation: best practices for permissions, sandboxing, constraints, and verification. https://developers.openai.com/codex/learn/best-practices