Wachstumsprotokoll-Skill
Das Problem: Die meisten Leute schreiben "Fehler in X behoben" als Lerntagebuch. Das ist ein Tagebucheintrag, kein Lernartefakt. Ein echtes Wachstumsprotokoll extrahiert das Muster, damit du es beim nächsten Mal wiedererkennst.
Dieser Skill lehrt: Wie man Lerneinträge schreibt, die sich über mehrere Sitzungen hinweg aufbauen. Funktioniert mit jedem Notizsystem – Markdown-Dateien, Notion, Obsidian, einfacher Text. Die Vorlagen sind generisch; passe sie an deine Umgebung an.
Wann aktivieren
- Nach einer komplexen Aufgabe (mehrere Dateien, neue Funktion, Architekturänderung)
- Nach einem Fehlschlag, Fehler oder einem "Das war schwieriger als erwartet"-Moment
- Wenn du überprüfen möchtest, was du über einen Zeitraum gelernt hast
Wann NICHT aktivieren: Triviale Änderungen (Tippfehlerkorrektur, einzeilige Anpassungen, Konfigurationswertänderungen ohne Fehlersuche). Der Schwellenwert: War bei dieser Aufgabe Fehlersuche, Nacharbeit, Rollback oder eine nicht offensichtliche Entscheidung erforderlich? Wenn ja → Eintrag schreiben. Wenn nein → überspringen.
Die drei Regeln
Regel 1: Fehler > Erfolge
Ein Fehler ist nährstoffdichter als ein Erfolg. Ein einzelner Bug, der 2 Stunden zum Finden brauchte, lehrt mehr als 3 Features, die beim ersten Versuch funktionierten.
Schlecht: "Erfolgreich den Login-Flow implementiert."
Gut (Webentwicklung): "Login-Flow: Session-Token wurde nicht persistent, weil das Cookie SameSite standardmäßig auf Lax in Chrome 128+ gesetzt war. Muster: Immer explizit SameSite=None; Secure setzen, wenn Cross-Origin. Erkennungssignal: Auth bricht nach Browser-Update oder beim Überqueren von Origin-Grenzen."
Gut (Datenpipeline): "CSV-Import schlug bei leeren Zeilen stillschweigend fehl, weil pandas.read_csv(dropna=False) Zeilen mit Breite Null 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 dies grundlegend dasselbe wie etwas, das ich bereits aufgezeichnet habe?"
Gleiche Ursache, anderes Symptom → 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). In einen Eintrag über "Erfassungslücken nach Aufgaben" zusammenführen.
Regel 3: Muss übertragbar sein
Jeder Eintrag muss 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 extrahiert man ein Muster aus einem konkreten Ereignis:
- Beschreibe das Ereignis in einem Satz
- Frage iterativ "warum?", bis du zur Ursache gelangst (normalerweise 3-5 Warums)
- Verallgemeinere: "Um welche Klasse von Problemen handelt es sich?" (nicht "Chrome-128-Fehler", sondern "Browser-Standardänderung, die bestehendes Verhalten bricht")
- Formuliere als: "Beim nächsten Mal, wenn ich [Signal] sehe, werde ich [Aktion] ausführen."
- Benenne das Signal: Welche spezifische Beobachtung sagt 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 zugrunde liegende Mechanismus, nicht nur das Symptom
### Das Muster (übertragbar)
- Beim nächsten Mal [ähnliche Situation] werde ich [spezifische Aktion] ausführen.
- Signal zum Erkennen: [welche Beobachtung sagt mir, dass dieses Muster aktiv ist?]
### Verwandt
- [Eintragsname](../pfad/zum/verwandten-eintrag.md)
Eintragstypen
Alle vier Typen verwenden die obige Vorlage. Der Typ bestimmt, welche Abschnitte das meiste Gewicht haben:
| Typ | Wann verwenden | Schwerpunkt | Beispieltitel |
|---|---|---|---|
| Fehlschlag | Etwas ist kaputtgegangen, erforderte Fehlersuche oder Nacharbeit | Ursache | "Konfigurationsvererbung ≠ Verhaltensvererbung über Sitzungen hinweg" |
| Methodik | Ein wiederholbarer Prozess ergab sich aus der Arbeit | Kontext / Muster | "PPT → Offenes-Buch-Prüfungsvorbereitung: Dreischichtige Struktur" |
| Mustererkennung | Eine wiederverwendbare Einsicht über Werkzeuge, Systeme oder Denken | Musterabschnitt | "PR-Beschreibungsvorlage: Beschreibe die Lücke, nicht das Feature" |
| Fähigkeitsänderung | Eine messbare Verbesserung der Fähigkeiten | Kontext (vorher vs. nachher) | "Git: Von Clone/Push zu unabhängigem PR mit 12 Commits" |
Qualitäts-Checkliste
Bevor du einen Wachstumsprotokoll-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 in vorhandenen Einträgen nach Duplikaten gesucht? (Bole-Prinzip)
- Ist die Ursache vom Symptom unterschieden?
- Sind verwandte Erinnerungen verknüpft?
- 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, kein Muster)
- Vermeide: Den Git-Commit-Nachricht wortwörtlich kopieren (Commits beschreiben, was sich geändert hat; Protokolle extrahieren, warum es wichtig ist)
- Vermeide: Für jeden Commit einen Eintrag schreiben (nur wenn ein Muster auftaucht)
- Vermeide: Den übertragbaren Satz auslassen (ohne ihn ist es nur ein Tagebuch – das ist nicht verhandelbar)
- Vermeide: Dasselbe Muster unter verschiedenen Titeln zu duplizieren (verstößt gegen das Bole-Prinzip – vor dem Schreiben suchen)
Speicherung
Speichere Einträge dort, wo du Notizen aufbewahrst. Übliche Muster:
- Markdown-Dateien in einem
growth-log/-Verzeichnis (eine Datei pro Tag:YYYY-MM-DD.md) - Ein dedizierter Abschnitt in Notion, Obsidian oder deiner Notiz-App
- Einfache Textdateien mit einer einheitlichen Namenskonvention
Wähle eine Konvention und bleibe dabei. Durchsuchbarkeit ist wichtiger als Format.
Falls du Delivery Gate verwendest
Der delivery-gate Stop-Hook prüft anhand von Dateisystem-Zeitstempeln, ob Lerndateien heute geändert wurden. Dieser Skill lehrt was zu schreiben ist – 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 bearbeitet?
→ Veraltet (keine Datei geändert): blockieren – "Was hast du gelernt?"
→ Aktuell (Datei bearbeitet): bestehen – dieser Skill stellt sicher, dass der Inhalt nützlich ist
Erzwingung ohne Methodik → leere Einträge. Methodik ohne Erzwingung → vergessene Erfassungen. Beide sind eigenständig nützlich; zusammen schließen sie den Kreislauf.