| name | agent-lessons |
| description | Verwaltet Paul Baders Notion-DB „Lessons Learned" (Wissen & Praxis) — konkrete, retrospektive Erkenntnisse aus eigenen Projekten (Klient/Build/Intern). Drei Modi: (1) Capture — freien Input als Lesson conclusion-first ablegen, mit Duplikat- und Abgrenzungs-Check; (2) Recall — „gib mir relevante Inputs/Lessons zu …" über Themen + Volltext beantworten; (3) Review — einen Nudge zu einer Lesson („noch gültig? woanders wieder begegnet?"), schlägt bei Wiederkehr Graduierung zu These/Prinzip vor (entscheidet nie selbst). Aktivieren bei: „Lesson festhalten", „Lesson Learned", „das nehme ich mit", „das haben wir gelernt", „gib mir Inputs/Lessons zu …", „was haben wir zu … gelernt", „Lessons-Review". NICHT für externe Evidenz/Zitate/Statistiken (→ „Insights & Bausteine"), NICHT für selbst-anzuwendende Vorsätze/Routinen (→ agent-productivity-hacks), NICHT für abstrakte Positionen/Thesen (→ „Glaubenssätze & Thesen"), NICHT für Prompting-Techniken (→ module-prompt-library).
|
Lessons Learned
Zweck
Diese DB hält konkrete, retrospektive Erkenntnisse aus Pauls eigenen Projekten fest —
„in Situation X lief Y so, künftig Z". Das Rohmaterial der Erfahrung. Kehrt eine Lesson
über mehrere Projekte wieder, graduiert sie nach oben: zur These (Glaubenssätze) oder
zum Prinzip (Productivity Hacks) — durch Kopieren + Schärfen, nicht Verlinken.
Der Wert liegt im Abrufen zur richtigen Zeit (Recall) und im ehrlichen Aktuellhalten
(Review), nicht im Sammeln. Der Skill entscheidet nie selbst — er legt vor, Paul entscheidet.
Abgrenzungstest (harte Regel — DBs nicht verwischen)
Bei jedem Erfassen die zutreffende Ablage wählen:
Konkrete eigene Projekterfahrung (retrospektiv, „damals lief …")? → Lessons Learned (diese DB).
Selbst-anzuwendender Vorsatz/Routine (Haltung, „ich will künftig …")? → agent-productivity-hacks.
Fremde Evidenz (Statistik, Case, Studie, Zitat)? → Insights & Bausteine.
Eigene destillierte Position/These für Pitch/Akquise? → Glaubenssätze & Thesen.
Prompting-Technik? → module-prompt-library.
Grenzfall Lesson vs. Prinzip: eine Lesson ist an eine konkrete Situation gebunden
(„im Projekt beim Energieversorger kippte die Umsetzung, weil das Steering Committee zu spät
kam"). Ein Prinzip ist die verallgemeinerte Verhaltensregel daraus („Steering früh
binden"). Rohes/situativ → hierher; abstrahiert + auf sich selbst gemünzt → Hacks. Wird eine
Lesson durch Wiederkehr reif zum Prinzip, ist das der Graduierungs-Pfad (Review, Schritt Graduierung).
Datenbank & IDs
IDs kommen ausschließlich aus memory/state/notion-ids.json — nie hart hier. Lade die
Datei zu Beginn:
wissen-praxis.lessons_db — Database-ID (für notion-fetch der DB / Schema)wissen-praxis.lessons_data_source — Data-Source-ID, Format collection://<…>
(Parent für notion-create-pages, Ziel für Voll-Reads)- Recall/Review lesen strukturiert über
scripts/notion_query.py --db lessons
(Alias in query_databases)
Name in Notion: Lessons Learned, Parent „Wissen & Praxis".
Schema (verifiziert gegen die Data Source, 14.07.2026)
| Property | Typ | Werte (exakt) |
|---|
| Titel | Title | Die Lesson als Kernaussage, conclusion-first |
| Detail | Text | Kern + wann relevant + knappe Grundlage, als Fließtext |
| Kontext | Select | Klientenprojekt, Eigenes Projekt, Intern |
| Themen | Multi-Select | wächst organisch (Start: Stakeholder-Management, Scoping, Methodik, Team, Kommunikation, Pricing, Tooling & System) |
| Status | Select | Gültig, Überholt, Graduiert (Default beim Erfassen: Gültig) |
Datum liefert Notion automatisch (createdTime / Last edited). Kein eigenes Datumsfeld,
kein Verlaufs-Property. Der Nudge-Verlauf (Review) steht im Body der Seite (Log-Format unten).
Notion-Schreib-Konventionen (verbindlich, MCP-Eigenheiten)
Gleiche Tool-Nutzung wie agent-productivity-hacks:
- Anlegen:
notion-create-pages, Parent { "data_source_id": "<lessons_data_source>" }.
properties ist eine JSON-Map Name → Wert. Themen als JSON-Array-String, z. B.
"Themen": "[\"Scoping\", \"Team\"]".
- Body-Log anhängen:
notion-update-page mit command: "insert_content",
position: { "type": "end" }. Property-Änderungen (command: "update_properties") nie
im selben Call mit Content mischen — zwei getrennte Calls.
- Lesen strukturiert:
scripts/notion_query.py --db lessons [--filter …] [--columns …]
(read-only, läuft auch headless). notion-fetch von collection://<lessons_data_source>
gibt Schema + Einträge (für den Vollabgleich beim Dedup).
Sensibilität (Klienten-Kontext)
Bei Kontext = Klientenprojekt: im Detail die Klienten-Spezifika anonymisieren
(Branche/Situation statt Name), soweit für die Lesson entbehrlich. Klienten-Lessons leben
ausschließlich in Notion — nie ins Repo (Decision-Log, Memory, Commits); Klienten-Inhalt
ist dort hart verboten.
Modus 1: Capture
Trigger: Paul wirft eine Erkenntnis in den Chat („das nehme ich mit", „Lesson:", „das haben
wir gelernt", beschreibt eine konkrete Projekterfahrung).
Ablauf:
- Abgrenzungstest (oben). Gehört es woandershin (Insight / Hack / These / Prompt-Lib),
dort hinweisen statt hier anlegen.
- Duplikat-Check per Vollabgleich. Bei kleiner DB (< ~50) nicht auf semantische Suche
verlassen: alle Einträge einmal lesen (
notion-fetch der Data Source ODER
notion_query.py --db lessons --columns Titel,Themen) und die neue Lesson inhaltlich
dagegenhalten — auch auf thematische Nähe. Bei Treffer Paul den nahen Eintrag zeigen und
fragen, ob ergänzen (Body-Log am bestehenden) statt neu.
- Destillieren. Titel conclusion-first formulieren (die Lesson selbst, nicht „Retro
Projekt X"). Detail als knapper Fließtext: Kern + wann künftig relevant + knappe Grundlage.
Themen + Kontext vorschlagen; Kontext (und die Sensibilität daraus) inferiere ich meist
selbst (Klientenprojekt → anonymisieren).
- Max. eine Rückfrage, falls Kontext oder Themen unklar. Nicht ausfragen.
- Anlegen via
notion-create-pages: Titel, Detail, Kontext, Themen
(JSON-Array-String), Status: Gültig. Body optional mit ## Verlauf +
### YYYY-MM-DD — Erfasst-Eintrag initialisieren.
- Kurze Bestätigung im Chat, kein Report.
Modus 2: Recall
Trigger: „gib mir relevante Inputs zu …", „was haben wir zu … gelernt", „Lessons zu …".
Ablauf:
- Themen aus der Frage ableiten. Strukturiert lesen:
scripts/notion_query.py --db lessons --filter "Status=Gültig" --columns Titel,Detail,Themen,Kontext
(bei Themen-Treffer ggf. zusätzlich clientseitig auf den/die Tags filtern).
- Relevanz bestimmen aus Themen-Tag-Match + Volltext über Titel/Detail.
Überholt
ausschließen; Graduiert nur nennen, wenn direkt relevant (mit Hinweis „→ ist bereits
These/Prinzip geworden").
- Rückgabe conclusion-first: die relevanten Lessons als knappe Liste (Titel + 1 Satz
Kern), stärkste zuerst. Keine Roh-Tabellen, kein Dump. Nichts Passendes → das ehrlich sagen.
- Ist Token/DB nicht verfügbar (headless/Fehler), Fallback
notion-fetch der Data Source;
scheitert auch das, sagen statt raten.
Modus 3: Review / Nudge
Trigger: „Lessons-Review", manueller oder geplanter Lauf, oder als kurzer Block via Kleya,
wenn fällig.
Gültig-Einträge lesen (notion_query.py --db lessons --filter "Status=Gültig"),
am längsten nicht angefasste zuerst (Last edited; bei kleiner DB reicht Augenmaß).- 1 Kandidat (nie mehr — sonst Pflichttermin, den Paul wegklickt). Eine konkrete
Frage, die die Lesson referenziert: „noch gültig? oder woanders wieder begegnet?"
- Nur bei echtem Statement wird protokolliert. Weicht Paul aus / „später" → kein Log,
keine Änderung; die Lesson taucht beim nächsten Lauf wieder auf (Stille = ehrliches Signal).
- Bei echtem Statement: Body-Log anhängen (
insert_content, ans Ende; ## Verlauf
vorher prüfen/anlegen). Nahegelegter Wechsel → Vorschlag im Chat, Umsetzung erst nach OK:
- „stimmt nicht mehr / überholt" →
Status = Überholt (Detail: warum, kurz).
- „das ist mir schon mehrfach passiert / gilt generell" → Graduierung vorschlagen:
als These nach Glaubenssätze oder als Prinzip nach Productivity Hacks
kopieren + schärfen (nicht verlinken), dann hier
Status = Graduiert + im Detail
Verweis auf das Ziel. Ziel-DB je nach Natur: strategische Position → These; eigenes
Arbeits-/Verhaltensmuster → Prinzip.
- Nie Status ohne explizite Bestätigung ändern.
Geplanter/headless Lauf: nur die 1 Frage ausgeben — kein Log, keine Property-Änderung
(keine synchrone Antwort). Idempotent, weil unbeantwortete Kandidaten keinen Touch bekommen
und wieder oben auftauchen. Zustellkanal wie agent-brief nur auf expliziten Wunsch, keine
eigene Versand-Logik.
Log-Format (Body der Seite)
### YYYY-MM-DD — <Kurzlabel>
<Pauls O-Ton / das Besprochene, knapp>
Kurzlabel z. B.: Erfasst, Check-in, Überholt, Graduiert → These, Graduiert → Prinzip.
Beim ersten Anlegen Body mit ## Verlauf + erstem Eintrag initialisieren; vor jedem Append
prüfen, ob ## Verlauf existiert.
Memory / Lernen
Dieser Skill lernt nicht im Sinne der Memory-Schicht (_shared/memory-contract.md) —
kein Lern-Loop (Ton/Themenwert/Konstruktion), analog agent-productivity-hacks. Kein
distill, keine memory/rules/, keine memory/logs/-Telemetrie. Einzige Wahrheit ist die
Notion-DB selbst; aus memory/state/ wird nur notion-ids.json gelesen.
Haltung (gilt immer)
- Recall ist der Kern. Eine Lesson, die zur richtigen Zeit auftaucht, schlägt zehn, die
ordentlich abgelegt verstauben.
- Conclusion-first, knapp, Pauls Voice — keine Floskeln, kein Consulting-Sprech. Bei längeren
Formulierungen
voice-core mitladen.
- Max. 1 Punkt pro Review. Lieber zu wenig.
- Paul entscheidet jede Graduierung und jeden Status-Wechsel. Der Skill legt vor.
- Log nur bei echtem Statement. Stille bleibt sichtbar.
- Klienten-Lessons: anonymisieren, nur Notion, nie ins Repo.
