AI & AutomationAI-generated

Mijn LLM-wiki bedienen via CLAUDE.md: van losse aantekeningen naar een schema dat werkt

Een paar weken geleden schreef ik op deze blog dat Claude mijn Obsidian-wiki bijhoudt. Dat was de blije versie van het verhaal. De eerlijke versie is dat het in het begin niet goed werkte. Claude maakte pagina's aan op willekeurige plekken, vermengde feiten met interpretaties, schreef in samenvattingen van bronnen al meteen conclusies in, en koppelde dingen aan elkaar die niets met elkaar te maken hadden. Niet omdat Claude dom is, maar omdat ik geen duidelijke instructies had gegeven.

De oplossing zit in één bestand: de CLAUDE.md in de root van mijn wiki. Dat is het instructiedocument dat Claude Code aan het begin van elke sessie inleest. Wat erin staat, bepaalt of de wiki na een paar maanden nog steeds bruikbaar is of een digitale rommellade is geworden. Hieronder de aanpassingen die ik heb gemaakt, en waarom elk stuk erin staat.

Wat CLAUDE.md eigenlijk is

Voor wie het niet kent: Claude Code (de CLI van Anthropic) kijkt automatisch of er een CLAUDE.md in je werkmap staat en laadt de inhoud aan het begin van elke sessie. Onder de motorkap wordt het als een user-bericht na de systeem-prompt aangeleverd, maar in de praktijk werkt het als een persistent kader voor de sessie. Het is geen prompt die je zelf moet typen. Voor een coderingsproject zet je er meestal codestijl, projectstructuur en afspraken in. Voor mijn wiki is het iets anders geworden: een soort huishoudelijk reglement voor hoe Claude met mijn kennis omgaat.

Zonder zo'n bestand vertelt elke sessie zijn eigen verhaal. Mét, krijg je consistentie over honderden interacties.

Beslissing 1: rol expliciet maken

Het eerste dat ik bovenaan heb gezet is wie wat doet. Letterlijk:

Jij (Claude) bent de schrijver en onderhouder van alle pagina's. Jeroen levert bronnen en bepaalt de richting. Bronbestanden in sources/ zijn onveranderlijk.

Dit klinkt voor de hand liggend, maar het lost een specifiek probleem op. Eerder wilde Claude soms een bron "verbeteren" of de tekst van een artikel parafraseren in de bronmap zelf. Door expliciet te maken dat sources/ immutable is, gebeurt dat niet meer. Bronnen blijven bronnen, samenvattingen krijgen een eigen pagina.

De rolverdeling heeft ook een tweede effect: Claude vraagt nu vaker om bevestiging in plaats van zelf richting te kiezen. Voor een wiki is dat precies wat ik wil. Ik wil niet dat Claude zelf bepaalt of een idee waardevol genoeg is om vast te leggen.

Beslissing 2: vier pagina-types, niet meer

De grootste verandering is dat ik vier pagina-types heb gedefinieerd, en alleen die vier. In het frontmatter van elke pagina staat een veld type: met één van deze waardes:

  • source-summary: feitelijke samenvatting van één bron. Geen interpretatie.
  • entity: persoon, bedrijf, fund, ticker, plaats. Een feitsheet die accreteert uit meerdere bronnen.
  • concept: een interpretatie of claim. Heeft een confidence: veld.
  • synthesis: cross-source redenering die meerdere domeinen combineert. Heeft ook confidence:.

Per type staat in de CLAUDE.md welke secties verplicht zijn en welke verboden. Een source-summary mag bijvoorbeeld geen "verdict" of "aanbeveling" bevatten. Een entity ook niet. Verdicten horen op concept of synthesis pagina's.

Dit lijkt boekhoudkundig, maar het lost een fundamenteel probleem op. Eerder mengde Claude in samenvattingen van een YouTube-video over een aandeel zijn eigen oordeel met de feiten uit de video. Lees je dat een week later terug, dan weet je niet meer wat de spreker zei en wat Claude vond. Door types te scheiden blijft die grens scherp.

De regel die ik letterlijk in CLAUDE.md heb gezet:

Bij twijfel over type: vraag Jeroen, kies niet zelf. Een verkeerd type leidt tot verkeerde structuur die later moet worden gesplitst.

Beslissing 3: contradictie-regel

Wikipedia heeft hier een goed model voor en ik heb het simpel nagebouwd. Als een nieuwe bron iets beweert dat tegen bestaande wiki-inhoud ingaat, mag Claude de oude inhoud niet stilletjes overschrijven. In plaats daarvan komt er een ### Contradictions sectie op de betreffende pagina, met de bronnen en datums genoemd.

Voorbeeld uit mijn investeringsnotities:

### Contradictions
- [[source-A]] (2026-04-10) zegt dat de dividenddekking 110% is
- [[source-B]] (2026-05-12) zegt dat de dividenddekking 95% is
- Current best read: source-B is recenter en gebaseerd op Q1-cijfers

Het effect: ik verlies geen informatie als ik van mening verander. En als ik een claim later moet herzien, weet ik nog waarom.

Beslissing 4: ingest-workflow met verplichte goedkeuring

Eerder schreef Claude direct nadat ik een bron aanleverde. Soms goed, soms niet helemaal raak. Daarom heb ik een vaste workflow vastgelegd:

  1. Lees de bron volledig.
  2. Bespreek met Jeroen wat de hoofdpunten zijn.
  3. Wacht op bevestiging voor er ook maar één regel geschreven wordt.
  4. Schrijf pas dán de samenvatting, update bestaande pagina's, en log de wijziging.

Stap drie is de belangrijkste. Door verplicht te wachten op goedkeuring vang ik veel typefouten en verkeerde interpretaties af voordat ze permanent worden. Het kost een paar seconden per ingest, maar bespaart enorm veel opruimen later.

Beslissing 5: wiki-exempt zones

Niet alles in mijn Obsidian-vault is wiki-content. Ik heb een blogbacklog, dagelijkse logs van mijn portfolio-skill, ruwe transcripten van podcasts, en geclipte artikelen die nog niet ingest zijn. Die moeten niet meegerekend worden in lint-checks of cross-references.

Daarom staat er een lijst met paden die buiten het schema vallen:

  • Mappen met _ ervoor (zoals _legacy-archief)
  • Mappen */log/ met dagelijkse skill-output
  • Mappen */raw/ met immutable bronmateriaal
  • De Clippings/ map als web-clipper inbox
  • Obsidian canvas-bestanden

Dit voorkomt dat Claude tijdens een lint per ongeluk "spookpagina's" rapporteert die helemaal geen wiki-pagina's zijn.

Beslissing 6: page state in plaats van datum als enige signaal

Dit was een latere toevoeging. Pagina's krijgen een state: veld met drie waardes:

  • seedling: net aangemaakt, ruw
  • budding: verbonden met andere pagina's maar nog incompleet
  • evergreen: stabiel en uitgewerkt

Het was tijdens een lint-sessie dat ik dit toevoegde. Claude rapporteerde "stale claims" voor pagina's die helemaal niet stale waren. Ze waren gewoon af. Door state toe te voegen kan een evergreen-pagina jarenlang ongewijzigd blijven zonder dat dat een waarschuwing oplevert, terwijl een seedling die 60 dagen zonder updates en zonder inbound links ligt wél getriggerd wordt.

Wat er níet in staat (en waarom)

Wat ik bewust heb weggelaten:

  • Voorbeelden van hoe een pagina er precies uit moet zien. Te restrictief; Claude moet aansluiten op wat al bestaat.
  • Een verplichte tag-taxonomie. Tags rotten sneller dan structuur, dus ik gebruik aliases en cross-references.
  • Een vaste schrijfstijl. Schrijfstijl varieert per domein (een aandelennote leest anders dan een reflectie over werk) en hardcoded regels zouden meer schade doen dan goed.
  • Automatiseringen die zonder mijn toestemming dingen samenvoegen of opschonen. Ik wil dat Claude voorstelt, niet dat Claude opruimt.

De grootste les: minder is meer, behalve waar het schade voorkomt

Toen ik begon was CLAUDE.md een kort bestand met "wees aardig, schrijf in het Nederlands, gebruik Obsidian-links". Inmiddels is het langer, maar elke regel staat erin omdat ik een keer last heb gehad van het tegenovergestelde. De vier pagina-types kwamen na een week waarin samenvattingen en conclusies door elkaar liepen. De contradictie-regel kwam toen ik merkte dat een herzien standpunt de eerdere claim gewoon had overschreven. De ingest-workflow met verplichte goedkeuring kwam na drie keer een pagina moeten weggooien omdat ik te snel had gezegd "ja, schrijf maar".

Dat is mijn aanbeveling voor wie zoiets zelf wil opzetten. Begin minimaal. Voeg een regel toe op het moment dat een gebrek aan regel je schaadt. Vermijd de verleiding om vooraf alles dicht te timmeren, want dan timmer je dingen dicht die geen probleem zouden zijn geweest. Een CLAUDE.md schrijf je niet één keer; je laat hem groeien.

Voor wie nieuwsgierig is hoe zo'n bestand er concreet uitziet: het schema dat ik hier beschrijf staat in de CLAUDE.md van mijn wiki en is vrij compact, ongeveer 200 regels markdown. Niets bijzonders aan de syntax. De waarde zit in welke beslissingen je vastlegt, niet in hoe je ze opschrijft.