agent-lessons

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:

1. Abgrenzungstest (oben). Gehört es woandershin (Insight / Hack / These / Prompt-Lib), dort hinweisen statt hier anlegen.
2. 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.
3. 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).
4. Max. eine Rückfrage, falls Kontext oder Themen unklar. Nicht ausfragen.
5. 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.
6. Kurze Bestätigung im Chat, kein Report.

---

Modus 2: Recall

Trigger: „gib mir relevante Inputs zu …", „was haben wir zu … gelernt", „Lessons zu …".

Ablauf:

1. 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).
2. 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").
3. 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.
4. 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.

1. 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ß).
2. 1 Kandidat (nie mehr — sonst Pflichttermin, den Paul wegklickt). Eine konkrete Frage, die die Lesson referenziert: „noch gültig? oder woanders wieder begegnet?"
3. 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).
4. 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.
5. 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.