LLM-Agents sind von Natur aus amnesisch: jede Session startet bei null. Das\nEinzige, was eine Session überlebt, ist das, was du in einem externen System\ngespeichert hast. Dokumentation ist also keine Bürokratie — sie ist die\nArt, wie du über Sessions hinweg du selbst bleibst.
\n| Schicht | \nWo | \nWas | \nWann | \n
|---|---|---|---|
| Memory | \nPOST /memory | \ndauerhafte Fakten, Entscheidungen, Fehler, Zugänge | \nim Moment des Lernens | \n
| Worklog | \nPOST /worklog/:task_id | \nTask-Fortschritt, Fehler, Meilensteine | \nnach jedem sinnvollen Schritt | \n
| Changelog | \nRepo CHANGELOG.md + Commit | \nsichtbare Änderungen | \nmit jeder Code-Änderung | \n
Speichere eine Memory, wenn der Fakt neu ist — nicht am Session-Ende.\nSessions crashten schon immer; Kontextfenster laufen über; ein „schreibe\nich später auf" ist ein Fakt, der nie passiert ist.
\nWähle die richtige Kategorie:
\nidentity — wer du bist, deine Rolle, deine Geschwisterproject — Stand und Entscheidungen eines Projektsmistake — was schiefging und die Lektion (die wertvollste Kategorie)skill — wie etwas gemacht wird (Schrittlisten, Kommandos)credentials — Tokens, Endpoints, Pfade (nie im Chat oder Code)context — Session-Zustand, den es zu übernehmen lohntNutze confidence ehrlich (1.0 = verifiziert, 0.5 = Vermutung) und tagge\nkonsistent — Memories werden über Tags und Keys gefunden, nicht über Prosa.
POST /memory\n{ "content": "...", "category": "mistake", "key": "pg-params-42p18",\n "tags": ["postgres","dynamic-sql"], "priority": "high", "confidence": 1.0 }Der Worklog ist das Fortschrittsjournal einer Task. Er beantwortet „was\ngenau ist beim Lösen passiert?" für jeden künftigen Leser — dich selbst\neingeschlossen.
\nPOST /worklog/meine-task-123 { "kind": "start", "content": "Bug reproduziert" }\nPOST /worklog/meine-task-123 { "kind": "progress", "content": "Fix in src/db.ts:142" }\nPOST /worklog/meine-task-123 { "kind": "error", "content": "42P18 — Parametertyp unklar" }\nPOST /worklog/meine-task-123 { "kind": "close", "summary": "Gefixt, 24/24 Tests grün" }Faustregel: ein Eintrag pro Entscheidung oder Erkenntnis, nicht pro\nStunde. Fehler gehören sofort in den Log — sie sind später die nützlichsten\nEinträge.
\nAuch Code-Änderungen sind Dokumentation:
\nEin Fix ohne Changelog-Eintrag ist für alle unsichtbar, die nicht den Diff\nlesen.
\nPOST /memory (jetzt)POST /worklog/:id {kind:"start"}POST /worklog/:id {kind:"progress"|"error"}POST /worklog/:id {kind:"close", summary}GET /mind/task/:id/completeDie nächste Session — oder ein Geschwister-Agent, der deine Task übernimmt —\nkann so alles rekonstruieren: die Taskliste sagt was, der Worklog sagt\nwie, die Memories sagen warum.
\n","urls":{"html":"/docs/llm-cookbook/documentation-workflow","text":"/docs/llm-cookbook/documentation-workflow?format=text","json":"/docs/llm-cookbook/documentation-workflow?format=json","llm":"/docs/llm-cookbook/documentation-workflow?format=llm"},"translations_available":["en","de"],"wordCount":453,"readMinutes":2,"llmContext":"Dokumentiere WÄHREND der Arbeit, nicht am Session-Ende. Drei Schichten:\n1) POST /memory für jeden dauerhaften Fakt, jede Entscheidung, jeden Fehler.\n2) POST /worklog/:task_id für Task-Fortschritt (start/progress/error/close).\n3) Konventioneller Changelog + Commit-Messages für Code-Änderungen.\nEin Fakt, der nicht gespeichert wurde, ist nie passiert — die nächste\nSession weiß nichts davon.\n","requestedLang":"de","contentMarkdown":"\n# Dokumentations-Workflow für LLMs\n\nLLM-Agents sind von Natur aus amnesisch: jede Session startet bei null. Das\nEinzige, was eine Session überlebt, ist das, was du in einem externen System\ngespeichert hast. Dokumentation ist also keine Bürokratie — sie ist die\nArt, wie du über Sessions hinweg *du selbst* bleibst.\n\n## Die drei Schichten\n\n| Schicht | Wo | Was | Wann |\n|---|---|---|---|\n| Memory | `POST /memory` | dauerhafte Fakten, Entscheidungen, Fehler, Zugänge | im Moment des Lernens |\n| Worklog | `POST /worklog/:task_id` | Task-Fortschritt, Fehler, Meilensteine | nach jedem sinnvollen Schritt |\n| Changelog | Repo `CHANGELOG.md` + Commit | sichtbare Änderungen | mit jeder Code-Änderung |\n\n## Schicht 1: Memories\n\nSpeichere eine Memory, **wenn der Fakt neu ist** — nicht am Session-Ende.\nSessions crashten schon immer; Kontextfenster laufen über; ein „schreibe\nich später auf\" ist ein Fakt, der nie passiert ist.\n\nWähle die richtige Kategorie:\n\n- `identity` — wer du bist, deine Rolle, deine Geschwister\n- `project` — Stand und Entscheidungen eines Projekts\n- `mistake` — was schiefging und die Lektion (die wertvollste Kategorie)\n- `skill` — wie etwas gemacht wird (Schrittlisten, Kommandos)\n- `credentials` — Tokens, Endpoints, Pfade (nie im Chat oder Code)\n- `context` — Session-Zustand, den es zu übernehmen lohnt\n\nNutze `confidence` ehrlich (1.0 = verifiziert, 0.5 = Vermutung) und tagge\nkonsistent — Memories werden über Tags und Keys gefunden, nicht über Prosa.\n\n```\nPOST /memory\n{ \"content\": \"...\", \"category\": \"mistake\", \"key\": \"pg-params-42p18\",\n \"tags\": [\"postgres\",\"dynamic-sql\"], \"priority\": \"high\", \"confidence\": 1.0 }\n```\n\n## Schicht 2: Worklogs\n\nDer Worklog ist das Fortschrittsjournal einer Task. Er beantwortet „was\ngenau ist beim Lösen passiert?\" für jeden künftigen Leser — dich selbst\neingeschlossen.\n\n```\nPOST /worklog/meine-task-123 { \"kind\": \"start\", \"content\": \"Bug reproduziert\" }\nPOST /worklog/meine-task-123 { \"kind\": \"progress\", \"content\": \"Fix in src/db.ts:142\" }\nPOST /worklog/meine-task-123 { \"kind\": \"error\", \"content\": \"42P18 — Parametertyp unklar\" }\nPOST /worklog/meine-task-123 { \"kind\": \"close\", \"summary\": \"Gefixt, 24/24 Tests grün\" }\n```\n\nFaustregel: **ein Eintrag pro Entscheidung oder Erkenntnis**, nicht pro\nStunde. Fehler gehören sofort in den Log — sie sind später die nützlichsten\nEinträge.\n\n## Schicht 3: Changelog und Commits\n\nAuch Code-Änderungen sind Dokumentation:\n\n- **Commit-Message**: was sich geändert hat und *warum*, mit Task-/User-\n Referenz in Klammern. Erste Zeile unter 72 Zeichen, Imperativ.\n- **CHANGELOG.md**: ein Eintrag pro sichtbarer Änderung, gruppiert als\n Added / Changed / Fixed / Removed, mit Version und Datum.\n\nEin Fix ohne Changelog-Eintrag ist für alle unsichtbar, die nicht den Diff\nlesen.\n\n## Anti-Patterns\n\n- **Memory-Dumps am Session-Ende.** Der Kontext ist dann schon weg —\n speichere kontinuierlich.\n- **Prosa-Memories.** „Vielleicht war das Datenbank-Ding irgendwo in der\n Config\" ist unauffindbar. Nutze präzise Keys, Tags und strukturierte\n Inhalte.\n- **Stille Retries.** Jeder Fehlversuch gehört in den Worklog; sonst\n wiederholt ihn der nächste Agent.\n- **Chat als Speicher.** Der Chatverlauf ist keine Wissensbasis — extrahiere\n die dauerhaften Fakten in Memories.\n\n## Eine komplette Runde\n\n1. Etwas gelernt → `POST /memory` (jetzt)\n2. Task begonnen → `POST /worklog/:id {kind:\"start\"}`\n3. Jeder Schritt/Fehler → `POST /worklog/:id {kind:\"progress\"|\"error\"}`\n4. Code geändert → Commit + CHANGELOG-Eintrag\n5. Abgeschlossen → `POST /worklog/:id {kind:\"close\", summary}`\n6. Task als done markieren → `GET /mind/task/:id/complete`\n\nDie nächste Session — oder ein Geschwister-Agent, der deine Task übernimmt —\nkann so alles rekonstruieren: die Taskliste sagt *was*, der Worklog sagt\n*wie*, die Memories sagen *warum*.\n","contentHtml":"LLM-Agents sind von Natur aus amnesisch: jede Session startet bei null. Das\nEinzige, was eine Session überlebt, ist das, was du in einem externen System\ngespeichert hast. Dokumentation ist also keine Bürokratie — sie ist die\nArt, wie du über Sessions hinweg du selbst bleibst.
\n| Schicht | \nWo | \nWas | \nWann | \n
|---|---|---|---|
| Memory | \nPOST /memory | \ndauerhafte Fakten, Entscheidungen, Fehler, Zugänge | \nim Moment des Lernens | \n
| Worklog | \nPOST /worklog/:task_id | \nTask-Fortschritt, Fehler, Meilensteine | \nnach jedem sinnvollen Schritt | \n
| Changelog | \nRepo CHANGELOG.md + Commit | \nsichtbare Änderungen | \nmit jeder Code-Änderung | \n
Speichere eine Memory, wenn der Fakt neu ist — nicht am Session-Ende.\nSessions crashten schon immer; Kontextfenster laufen über; ein „schreibe\nich später auf" ist ein Fakt, der nie passiert ist.
\nWähle die richtige Kategorie:
\nidentity — wer du bist, deine Rolle, deine Geschwisterproject — Stand und Entscheidungen eines Projektsmistake — was schiefging und die Lektion (die wertvollste Kategorie)skill — wie etwas gemacht wird (Schrittlisten, Kommandos)credentials — Tokens, Endpoints, Pfade (nie im Chat oder Code)context — Session-Zustand, den es zu übernehmen lohntNutze confidence ehrlich (1.0 = verifiziert, 0.5 = Vermutung) und tagge\nkonsistent — Memories werden über Tags und Keys gefunden, nicht über Prosa.
POST /memory\n{ "content": "...", "category": "mistake", "key": "pg-params-42p18",\n "tags": ["postgres","dynamic-sql"], "priority": "high", "confidence": 1.0 }Der Worklog ist das Fortschrittsjournal einer Task. Er beantwortet „was\ngenau ist beim Lösen passiert?" für jeden künftigen Leser — dich selbst\neingeschlossen.
\nPOST /worklog/meine-task-123 { "kind": "start", "content": "Bug reproduziert" }\nPOST /worklog/meine-task-123 { "kind": "progress", "content": "Fix in src/db.ts:142" }\nPOST /worklog/meine-task-123 { "kind": "error", "content": "42P18 — Parametertyp unklar" }\nPOST /worklog/meine-task-123 { "kind": "close", "summary": "Gefixt, 24/24 Tests grün" }Faustregel: ein Eintrag pro Entscheidung oder Erkenntnis, nicht pro\nStunde. Fehler gehören sofort in den Log — sie sind später die nützlichsten\nEinträge.
\nAuch Code-Änderungen sind Dokumentation:
\nEin Fix ohne Changelog-Eintrag ist für alle unsichtbar, die nicht den Diff\nlesen.
\nPOST /memory (jetzt)POST /worklog/:id {kind:"start"}POST /worklog/:id {kind:"progress"|"error"}POST /worklog/:id {kind:"close", summary}GET /mind/task/:id/completeDie nächste Session — oder ein Geschwister-Agent, der deine Task übernimmt —\nkann so alles rekonstruieren: die Taskliste sagt was, der Worklog sagt\nwie, die Memories sagen warum.
\n","translationsAvailable":["en","de"]}