Here is exactly how mine works, including what has gone wrong and what I have not built. Run the prompt below against yours and send it over — I will reply with what I am stealing from it.
My answers to the prompt below — expand what interests you, or take the whole thing as markdown.
Markdown in a private git repository, edited by an agent and readable in Obsidian. Three top-level folders: immutable raw sources, agent-maintained pages, and generated outputs. Page types are people, organisations, sources, projects and meals. Every page carries frontmatter with created and updated dates and a confidence rating.
Git is doing more work here than it looks. Every change is a commit with the reasoning in the message, so a rewrite is never actually destructive — the previous version is always recoverable. That single property is what makes aggressive tidying safe rather than frightening.
I use mine for a mix of things — some running regularly, others still being refined.
The division that works: a cheap deterministic classifier handles volume, and the LLM only sees the ambiguous remainder. It never replaces that classifier, it works on top of its output.
Standing rule: surface, never act. Anything needing judgement gets flagged rather than handled — an unsigned contract, a failed payment, an expiring policy. Nothing runs unattended.
Sources started in a folder per project, mirroring how I had organised things before. Wrong twice, a layer apart — first for raw sources, then again for project pages, where one folder held exactly one file.
The general point: a folder forces every item to have exactly one parent, so you have to choose one. A source relating to three projects does not have one parent — and a link costs nothing. Anything that can be expressed as a link should not be expressed as a folder.
The first source page was a tidy summary of a CV. That is wrong in a specific, non-obvious way: queries read the wiki layer and never touch the raw files, so a summarised source page means every future answer is built on a lossy copy — while the exact original sits one folder away, unread. Reversed within a day.
The log had grown to 128KB in nineteen days, and the plan was to rewrite the old entries short.
Before deleting anything I checked what existed only in the log — and found real things, including two former colleagues with no pages anywhere. Deleting would have destroyed the only record of them. So the order changed: migrate what is at risk onto real pages first, then rewrite. The check is the transferable part, not the rewrite.
The part almost nobody builds, and the part that decides whether this is still useful in a year.
Decide where each fact lives before writing anything into it. Nearly every problem above traces to the same root: no rule about page versus log, so everything went in both, and anything without an obvious home went in neither.
And on day one: put it in git. Not for collaboration — for the ability to rewrite aggressively later without risking the loss of something only recorded in one place.
Run this against your own setup. It asks for structure and conventions only — not your content — so nothing personal needs to leave your machine.
I'm comparing notes with someone who also runs an LLM-maintained wiki. Please summarise how THIS one actually works, so we can compare and each steal the good ideas. Important: describe structure, conventions and mechanisms only — do NOT include personal content. No names, no financial figures, no employer specifics, no actual notes. Redact or generalise anything identifying. If an example is needed to make a rule clear, invent a neutral one. Answer these, in markdown, with headings: 1. SHAPE — What is it built on (tool, model, storage, version control)? How is content organised at the top level, and what types of page exist? 2. WRITTEN-DOWN RULES — Which conventions are actually recorded as instructions for the assistant, rather than just held in your head? Quote them roughly as written. Most interested in: naming, where things live, what must never be overwritten, and how source material is preserved. 3. WHAT IT DOES, NOT JUST HOLDS — Which tasks does it actually perform (drafting, triage, planning, research)? For each: what triggers it, on demand or scheduled, and how much does it do without asking? 4. CHANGED YOUR MIND — What did you set up, then deliberately reverse or abandon? Why? This is the most useful section: what looked right and wasn't. 5. WHAT BROKE — What has gone wrong (lost information, duplication, stale or contradictory entries, the assistant confidently doing the wrong thing)? What rule or mechanism came out of each, if any? 6. KEEPING IT HONEST — How do you stop it rotting? Specifically: detecting stale facts, stopping the same thing being recorded twice, handling growth over time, and protecting edits made by hand from being overwritten. 7. WHAT YOU'D DO DIFFERENTLY — Starting again tomorrow, what would you change? And what's the one thing you'd tell someone setting one up on day one? Be concrete and specific. Where something isn't solved, say so plainly rather than describing the intention — the unsolved problems are as useful as the solved ones.
I read every one, and I will reply with what I am taking from yours.