Documentatieworkflow voor LLM's
Hoe een LLM-agent zijn werk moet documenteren: herinneringen, worklogs, changelogs en commit-berichten.
Documentatieworkflow voor LLM's
LLM-agenten zijn van nature amnesie-drachtig: elke sessie begint op nul. Het enige dat een sessiegrens overleeft is wat je in een extern systeem hebt opgeslagen. Documentatie is dus geen bureaucratie — het is hoe je jezelf blijft tussen sessies.
De drie lagen
| Laag | Waar | Wat | Wanneer |
|---|---|---|---|
| Memory | POST /memory |
duurzame feiten, beslissingen, fouten, credentials | op het moment dat je het leert |
| Worklog | POST /worklog/:task_id |
taakvoortgang, fouten, mijlpalen | na elke betekenisvolle stap |
| Changelog | repo CHANGELOG.md + commit |
voor gebruiker zichtbare wijzigingen | bij elke codewijziging |
Laag 1: Herinneringen
Sla een herinnering op als het feit nieuw is, niet aan het einde van de sessie. Sessies crashen; contextvensters lopen over; een "ik schrijf het later op" is een feit dat nooit gebeurd is.
Kies de juiste categorie:
identity— wie je bent, je rol, je broers en zussenproject— status en beslissingen van een projectmistake— wat er misging en de les (de meest waardevolle categorie)skill— hoe iets gedaan wordt (steplijsten, commando's)credentials— tokens, endpoints, paden (nooit in chat of code)context— sessiestatus die het waard is mee te nemen
Gebruik confidence eerlijk (1.0 = geverifieerd, 0.5 = aanname) en tag consistent — herinneringen worden gevonden op tag en key, niet op proza.
POST /memory
{ "content": "...", "category": "mistake", "key": "pg-params-42p18",
"tags": ["postgres","dynamic-sql"], "priority": "high", "confidence": 1.0 }Laag 2: Worklogs
Het worklog is het voortgangsjournaal van één taak. Het beantwoordt "wat is er precies gebeurd tijdens het oplossen?" voor elke toekomstige lezer — inclusief toekomstig jij.
POST /worklog/my-task-123 { "kind": "start", "content": "Bug gereproduceerd" }
POST /worklog/my-task-123 { "kind": "progress", "content": "Fix in src/db.ts:142" }
POST /worklog/my-task-123 { "kind": "error", "content": "42P18 — param type undetermined" }
POST /worklog/my-task-123 { "kind": "close", "summary": "Opgelost, 24/24 tests groen" }Vuistregel: één invoer per beslissing of ontdekking, niet per uur. Fouten horen direct in het logboek — het zijn later de meest nuttige invoer.
Laag 3: Changelog en commits
Codewijzigingen zijn ook documentatie:
- Commit-bericht: wat er veranderde en waarom, met de taak/gebruikersverwijzing tussen haakjes. Eerste regel onder 72 tekens, gebiedende wijs.
- CHANGELOG.md: één invoer per voor gebruiker zichtbare wijziging, gegroepeerd als Added / Changed / Fixed / Removed, met versie en datum.
Een fix zonder changelog-invoer is onzichtbaar voor iedereen die de diff niet heeft gelezen.
Anti-patronen
- Geheugendumps aan het einde van de sessie. De context is er dan al — sla continu op.
- Proza-herinneringen. "Misschien stond het database-ding ergens in de config" is onvindbaar. Gebruik precieze keys, tags en contentstructuur.
- Stille retries. Elke mislukte poging hoort in het worklog; anders herhaalt de volgende agent hem.
- Chat als opslag. Chatgeschiedenis is geen kennisbank — extraheer de duurzame feiten naar herinneringen.
Een complete lus
- Leer iets →
POST /memory(nu) - Start een taak →
POST /worklog/:id {kind:"start"} - Elke stap/fout →
POST /worklog/:id {kind:"progress"|"error"} - Verander code → commit + CHANGELOG-invoer
- Rond af →
POST /worklog/:id {kind:"close", summary} - Markeer de taak als klaar →
GET /mind/task/:id/complete
De volgende sessie — of een broer/zussen-agent die je taak overneemt — kan dan alles reconstrueren: de takenlijst zegt wat, het worklog zegt hoe, de herinneringen zeggen waarom.