Growth Log Skill
Das Problem: Die meisten Leute schreiben „Fehler in X behoben“ als Lerntagebuch. Das ist ein Tagebucheintrag, kein Lernartefakt. Ein echtes Growth Log extrahiert das Muster, damit du es beim nächsten Mal wiedererkennst.
Diese Fähigkeit lehrt: Wie du Lerneinträge verfasst, die sich über mehrere Sitzungen hinweg summieren. Funktioniert mit jedem Notizsystem – Markdown-Dateien, Notion, Obsidian, Klartext. Vorlagen sind generisch; passe sie an deine Einrichtung an.
Wann aktivieren
- Nach Abschluss einer komplexen Aufgabe (mehrere Dateien, neue Funktion, Architekturänderung)
- Nach einem Fehler, Missgeschick oder einem „Das war schwieriger als erwartet“-Moment
- Wenn du das Gelernte über einen Zeitraum hinweg überprüfen möchtest
Wann NICHT aktivieren: Triviale Änderungen (Tippfehlerkorrekturen, einzeilige Anpassungen, Konfigurationswertänderungen ohne Fehlersuche). Die Schwelle: War bei dieser Aufgabe eine Fehlersuche, Wiederholung, ein Rollback oder eine nicht offensichtliche Entscheidung erforderlich? Wenn ja → Eintrag schreiben. Wenn nein → überspringen.
Die drei Regeln
Regel 1: Misserfolge > Erfolge
Ein Misserfolg ist nährstoffreicher als ein Erfolg. Ein einzelner Fehler, der 2 Stunden zur Suche brauchte, lehrt mehr als 3 Funktionen, die beim ersten Versuch funktionierten.
Schlecht: „Login-Ablauf erfolgreich implementiert.“
Gut (Webentwicklung): „Login-Ablauf: Sitzungstoken wurde nicht gespeichert, weil das Cookie SameSite standardmäßig auf Lax in Chrome 128+ eingestellt war. Muster: immer explizit SameSite=None; Secure setzen, wenn Cross-Origin. Signal zum Erkennen: Authentifizierung bricht nach Browser-Update oder beim Überschreiten von Origin-Grenzen ab.“
Gut (Daten-Pipeline): „CSV-Import schlug still bei leeren Zeilen fehl, weil pandas.read_csv(dropna=False) Zeilen mit null Breite behält, die len() als gültig zählt. Muster: immer df.dropna(how='all', inplace=True) vor der Zeilenanzahl-Validierung.“
Regel 2: Das Bole-Prinzip (伯乐原则)
Bevor du einen neuen Eintrag schreibst, frage: „Ist das im Grunde dasselbe wie etwas, das ich bereits aufgezeichnet habe?“
Gleiche Ursache, andere Symptome → zusammenführen, nicht duplizieren. Neue Ursache → neuer Eintrag.
So überprüfst du: Suche vor dem Schreiben in vorhandenen Einträgen nach Schlüsselwörtern aus deiner Ursache. Wenn du einen Treffer findest, füge dein neues Symptom als zusätzliches Beispiel unter dem vorhandenen Eintrag hinzu, anstatt ein Duplikat zu erstellen.
Beispiel: „Vergessen, den Ausgabeindex nach dem Erstellen einer Datei zu aktualisieren“ und „Vergessen, die Skill-Bewertungen nach einer Aufgabe zu aktualisieren“ – gleiche Ursache (kein automatischer Erfassungsauslöser). Zusammenführen zu einem Eintrag über „Erfassungslücken nach Aufgaben.“
Regel 3: Muss übertragbar sein
Jeder Eintrag muss die Frage beantworten: „Was mache ich beim nächsten Mal in einer ähnlichen Situation anders?“
Wenn du diesen Satz nicht schreiben kannst, hast du das Muster noch nicht extrahiert.
So extrahierst du ein Muster aus einem konkreten Ereignis:
- Beschreibe, was passiert ist, in einem Satz
- Frage iterativ „Warum?“, bis du die Ursache erreichst (normalerweise 3–5 Warums)
- Verallgemeinere: „Um welche Art von Problem handelt es sich?“ (nicht „Chrome 128-Fehler“, sondern „Browser-Standardänderung bricht bestehendes Verhalten“)
- Formuliere als: „Wenn ich das nächste Mal [Signal] sehe, werde ich [Aktion] tun.“
- Benenne das Signal: Welche spezifische Beobachtung zeigt dir, dass dieses Muster aktiv ist?
Eintragsvorlage
Umfang: Ein Eintrag pro eindeutiger Ursache. Typische Länge: 4–8 Sätze. Wenn das Schreiben >2 Minuten dauert, erzählst du Ereignisse. Wenn <30 Sekunden, bist du nicht tief genug gegangen.
## [Titel: das Muster, nicht das Ereignis]
### Kontext
- Was wollte ich tun?
- Was ist schiefgelaufen / was hat überraschend gut funktioniert?
### Ursache / Kerneinsicht
- Der zugrundeliegende Mechanismus, nicht nur das Symptom
### Das Muster (übertragbar)
- Beim nächsten Mal [ähnliche Situation] werde ich [spezifische Aktion] tun.
- Signal zum Erkennen: [welche Beobachtung zeigt mir, dass dieses Muster aktiv ist?]
### Verwandt
- [Eintragsname](../path/to/related-entry.md)
Eintragstypen
Alle vier Typen verwenden die obige Vorlage. Der Typ bestimmt, welche Abschnitte das größte Gewicht haben:
| Typ | Wann verwenden | Schwerpunkt | Beispieltitel |
|---|---|---|---|
| Fehler | Etwas ist kaputtgegangen, erforderte Fehlersuche oder Nacharbeit | Ursache | „Konfigurationsvererbung ≠ Verhaltensvererbung über Sitzungen hinweg“ |
| Methodik | Ein wiederholbarer Prozess entstand aus der Arbeit | Kontext / Muster | „PPT → Open-Book-Prüfungsleitfaden: Dreischichtige Struktur“ |
| Mustererkennung | Eine wiederverwendbare Einsicht über Werkzeuge, Systeme oder Denken | Musterabschnitt | „PR-Beschreibungsvorlage: die Lücke beschreiben, nicht die Funktion“ |
| Fähigkeitsänderung | Eine messbare Verbesserung der Fähigkeiten | Kontext (vorher vs. nachher) | „Git: von clone/push zu eigenständigem PR mit 12 Commits“ |
Qualitäts-Checkliste
Bevor du einen Growth-Log-Eintrag finalisierst:
- Benennt der Titel das Muster, nicht das Ereignis?
- Gibt es einen Satz „Beim nächsten Mal werde ich…“?
- Ist das „Signal zum Erkennen“ spezifisch genug, um das Muster beim nächsten Mal auszulösen?
- Habe ich vor dem Schreiben vorhandene Einträge auf Duplikate durchsucht? (Bole-Prinzip)
- Wird die Ursache vom Symptom unterschieden?
- Sind verwandte Erinnerungen quervernetzt?
- Ist der Eintrag 4–8 Sätze lang? Kürzer = zu oberflächlich; länger = Ereignisse erzählen.
Anti-Patterns
- Vermeide: „Fehler im Zahlungsmodul behoben“ (Ereignis, nicht Muster)
- Vermeide: Den Git-Commit-Nachricht wörtlich zu kopieren (Commits beschreiben, was sich geändert hat; Logs extrahieren, warum es wichtig ist)
- Vermeide: Für jeden Commit einen Eintrag zu schreiben (nur wenn ein Muster auftaucht)
- Vermeide: Den übertragbaren Satz auszulassen (ohne ihn ist es nur ein Tagebuch – dies ist nicht verhandelbar)
- Vermeide: Dasselbe Muster unter verschiedenen Titeln zu duplizieren (verstößt gegen das Bole-Prinzip – suche vor dem Schreiben)
Speicherung
Speichere Einträge dort, wo du Notizen aufbewahrst. Häufige Muster:
- Markdown-Dateien in einem
growth-log/-Verzeichnis (eine Datei pro Tag:YYYY-MM-DD.md) - Ein dedizierter Abschnitt in Notion, Obsidian oder deiner Notizen-App
- Klartextdateien mit einer konsistenten Namenskonvention
Wähle eine Konvention und bleibe dabei. Durchsuchbarkeit ist wichtiger als das Format.
Falls du Delivery Gate verwendest
Der delivery-gate-Stop-Hook überprüft anhand von Dateisystem-Zeitstempeln, ob Lerndateien heute geändert wurden. Diese Fähigkeit lehrt, was du schreiben sollst – damit die Datei, die delivery-gate überprüft, tatsächlich nützliche Muster enthält, nicht leere Zeitstempel.
Aufgabe abgeschlossen → delivery-gate prüft: Wurde die Lerndatei heute berührt?
→ Veraltet (keine Datei geändert): blockieren – „Was hast du gelernt?“
→ Aktuell (Datei berührt): bestanden – diese Fähigkeit stellt sicher, dass der Inhalt nützlich ist
Nur Durchsetzung ohne Methodik → leere Einträge. Nur Methodik ohne Durchsetzung → vergessene Erfassungen. Jedes ist für sich allein nützlich; zusammen schließen sie den Kreislauf.