agent-productivity-hacks

name

agent-productivity-hacks

description

Verwaltet Paul Baders persönliche Notion-DB „Productivity Hacks & Prinzipien" (eigene Prinzipien/Glaubenssätze und Produktivitäts-Hacks zum Selbst-Anwenden). Zwei Modi: (1) Erfassen neuer Einträge mit Duplikat-Check, (2) Review/Nudge — fragt zu einem Eintrag nach, schreibt das Gespräch als Verlaufs-Log in die Notion-Seite, hält den Touchpoint aktuell und schlägt Lifecycle-Wechsel vor (entscheidet nie selbst). Aktivieren bei: "/agent-productivity-hacks add", "/agent-productivity-hacks review", "Praxis", "Prinzip festhalten", "Hack notieren", "Praxis-Review", "was wollte ich umsetzen", "Stand meiner Vorsätze", oder wenn Paul ein persönliches Learning/einen Vorsatz festhalten oder den Stand eines laufenden Vorsatzes besprechen will. NICHT für externe Business-Insights/Zitate/Statistiken (→ DB „Insights & Bausteine"). NICHT für den Tages-/Wochenüberblick über Tasks & Termine ("was steht heute/diese Woche an", "Briefing") — das macht agent-brief.

Productivity Hacks & Prinzipien

Zweck

Diese DB hält fest, was Paul selbst anwenden und internalisieren will — eigene Prinzipien und Produktivitäts-Hacks (persönliche Haltung/Routinen zum Selbst-Anwenden). Strikt getrennt von den beiden Wissens-DBs: „Insights & Bausteine" (externe Evidenz) und „Glaubenssätze & Thesen" (eigene strategische Positionen für Pitch/Akquise).

Der Wert liegt nicht im Sammeln, sondern im aktiv halten und ehrlich aussortieren. Der Skill macht nie die Bewertung selbst und ändert nie eigenmächtig den Status — er schlägt vor, Paul entscheidet.

Abgrenzungstest (harte Regel — DBs nicht verwischen, dreistufig)

Bei jedem Erfassen die zutreffende Ablage wählen:

Wende ich es auf mich selbst an (Haltung, Routine, Vorsatz)? → Productivity Hacks & Prinzipien (diese DB). Ist es fremde Evidenz (Statistik, Case, Studie, Zitat, Beispiel) zum Nutzen/Zitieren? → Insights & Bausteine. Ist es eine eigene, destillierte Position/These für Pitch-Logik/Akquise? → Glaubenssätze & Thesen. Ist es eine Prompting-Technik (wie man KI besser befragt)? → module-prompt-library (Repo, kein Notion; seit 08.07.2026).

Kein Abwägen, kein Graubereich. Verhaltens-/Haltungsvorsatz für Paul → hierher; Fremdbeleg zum Vorzeigen → Insights; eigene Überzeugung/Denkmuster als Argument → Glaubenssätze; Prompting-Methode → Prompt Library.

Datenbank & IDs

IDs kommen ausschließlich aus memory/state/notion-ids.json (Schlüssel productivity-hacks) — nie hart in diesem Dokument. Lade die Datei zu Beginn und referenziere:

• productivity-hacks.db — Database-ID (für notion-fetch der DB-Übersicht)
• productivity-hacks.data_source — Data-Source-ID, Format collection://<productivity-hacks.data_source> (Parent für notion-create-pages, Ziel für Voll-Reads)

Name in Notion: Productivity Hacks & Prinzipien, Parent „Wissen & Praxis".

Schema (verifiziert gegen die Data Source)

Property	Typ	Werte (exakt)
Aussage	Title	—
Art	Select	Prinzip, Hack
Status	Status	Neu, In Erprobung, Aktiv, Pausiert, Verworfen
Bewährung	Select	offen, bewährt, gemischt, enttäuscht
Letzter Touchpoint	Date	siehe Notion-Schreib-Konventionen unten
Reflexion	Text	kurzer aktueller Stand (eine Zeile)
Herkunft	Text	z. B. „Kundenevent (April 2026)", „Buch X", „eigene Erfahrung"

Verlauf steht NICHT in einer Property, sondern als datierte Einträge im Body der jeweiligen Seite (Log-Format unten).

Notion-Schreib-Konventionen (verbindlich, MCP-Eigenheiten)

Gleiche Tool-Nutzung wie agent-content-scout. Die Eigenheiten hier explizit, damit nichts geraten wird:

• Anlegen: notion-create-pages, Parent { "data_source_id": "<productivity-hacks.data_source>" }. properties ist eine JSON-Map Name → Wert.
• Datum „Letzter Touchpoint": kein einfaches Letzter Touchpoint-Feld, sondern die expandierten Schlüssel: "date:Letzter Touchpoint:start" = ISO-Datum (YYYY-MM-DD) und "date:Letzter Touchpoint:is_datetime" = 0 (reines Datum, keine Uhrzeit). :end leer lassen.
• Body-Log anhängen: notion-update-page mit command: "insert_content", content: <Markdown>, position: { "type": "end" }. (Property-Änderungen laufen über command: "update_properties" — niemals beides im selben Call vermischen, zwei Calls.)
• Lesen/Voll-Read: notion-fetch mit id: "collection://<productivity-hacks.data_source>" liefert Schema + Einträge.

Achsen verstehen (wichtig für Vorschläge)

Zwei unabhängige Dimensionen:

• Status = wo im Lifecycle (mache ich es?).
• Bewährung = wie es real läuft (funktioniert es?).

Der wertvolle Widerspruch: Status Aktiv + Bewährung enttäuscht/gemischt — Paul macht es aus Gewohnheit, obwohl es nicht wirkt. Verwerf- oder Pausier-Kandidat. Umgekehrt: Status In Erprobung + mehrfach positive Logs → Promote-Kandidat für Aktiv.

---

Modus 1: Erfassen (/agent-productivity-hacks add)

Trigger: Paul wirft ein Learning/Prinzip/Hack in den Chat („halt das fest", „neuer Hack", „Prinzip:", oder beschreibt eine Erkenntnis zum Selbst-Anwenden).

Ablauf:

1. Abgrenzungstest anwenden (siehe oben). Gehört es nach „Insights & Bausteine", dort hinweisen statt hier anlegen.
2. Duplikat-Check durch Vollabgleich. Bei dieser DB-Größe (< ~50 Einträge) NICHT auf semantische notion-search verlassen — bei kleinen, eng verwandten Beständen unscharf. Stattdessen alle Aussagen der Data Source einmal komplett lesen (notion-fetch von collection://<productivity-hacks.data_source>) und die neue Aussage inhaltlich gegen jede bestehende halten — auch auf thematische Nähe, nicht nur Wortgleichheit. Bei Treffer: Paul den nahen Eintrag zeigen und fragen, ob ergänzen (neuer Log-Eintrag am bestehenden) statt neu anlegen. Erst ab deutlich größerem Bestand auf Suche umstellen.
3. Klassifizieren. Art (Prinzip vs. Hack) vorschlagen. Faustregel: Verhaltens-/ Haltungssatz = Prinzip; konkrete Methode/Routine/Tool-Praktik = Hack.
4. Max. eine Rückfrage, falls Herkunft oder Art unklar. Nicht ausfragen.
5. Anlegen via notion-create-pages:
   • Aussage: der Satz
   • Status: Neu (oder In Erprobung, wenn Paul es schon ausprobiert)
   • Bewährung: offen
   • Art: Prinzip | Hack
   • date:Letzter Touchpoint:start: heute (ISO), date:Letzter Touchpoint:is_datetime: 0
   • Reflexion: kurze Einordnung (eine Zeile)
   • Herkunft: falls bekannt
   • content: Body mit ## Verlauf initialisiert + erstem Log-Eintrag (Format unten)
6. Kurze Bestätigung im Chat, kein langer Report.

---

Modus 2: Review / Nudge (/agent-productivity-hacks review)

Trigger: „Praxis-Review", „was wollte ich umsetzen", „Stand meiner Vorsätze", manueller oder geplanter Lauf (siehe „Autonomer/geplanter Lauf"), oder als kurzer Block im Wochen-Brief (siehe „Einhängen in agent-brief").

Auswahllogik (kein Scoring, kein fixer Tage-Schwellwert):

1. Einträge read-only via scripts/notion_query.py --db productivity_hacks --sort "Letzter Touchpoint:asc" lesen (am längsten still zuerst; die MCP-Zeilenquery ist plan-gesperrt, notion-fetch der Data Source gibt nur das Schema). Schreiben (Touchpoint/Status) läuft weiter über den MCP.
2. Filtern und gewichten nach Status:
   • In Erprobung → kurze Kadenz (höchste Priorität, braucht Aufmerksamkeit).
   • Aktiv → lange Kadenz (nur ab und zu „läuft das noch?" — Schutz davor, dass Aktives stillschweigend zu totem Gewohnheits-Ballast wird).
   • Aktiv + Bewährung bewährt, lange still → seltenster, beiläufiger Check (internalisiert, kein Pflegebedarf).
   • Neu → einmal anstoßen („schon probiert?").
   • Pausiert, Verworfen → ignorieren.
3. 1–2 Kandidaten auswählen (nie mehr — sonst Pflichttermin, den Paul wegklickt). Bevorzugt: am längsten still + höchste Kadenz-Gewichtung. Den Widerspruch Aktiv + enttäuscht/gemischt immer mitnehmen, wenn vorhanden.

Gespräch pro Kandidat:

4. Eine konkrete Frage, die die Aussage referenziert — nicht generisch.
   • Gut: „Du wolltest auf Kundenevents bewusster beobachten und Sparring einbringen. Hattest du letzte Woche eine Gelegenheit? Wie lief's?"
   • Schlecht: „Wie läuft deine Praxis?"
5. Paul antwortet im Chat.
6. Nur bei tatsächlicher inhaltlicher Antwort wird protokolliert. Weicht Paul aus, sagt „keine Zeit" / „später" / gibt kein Statement → kein Log, kein Touchpoint-Update. Der Eintrag bleibt unberührt und taucht beim nächsten Lauf wieder auf (die Stille ist das ehrliche Signal). NIEMALS einen Touchpoint setzen, ohne dass es ein echtes Statement gab — sonst steht „besprochen" in der DB, obwohl nichts passiert ist.
7. Bei echtem Statement: Log schreiben (notion-update-page, command: "insert_content", position: { "type": "end" }) — datierter Eintrag in den Body. Vorher prüfen (per notion-fetch der Seite), ob ein ## Verlauf-Block existiert; falls nicht, ihn im selben content mit anlegen, dann anhängen. Danach getrennter update_properties-Call: date:Letzter Touchpoint:start = heute, date:Letzter Touchpoint:is_datetime = 0. Reflexion ggf. aktualisieren.
8. Wenn die Antwort einen Lifecycle-Wechsel nahelegt → Vorschlag im Chat, Umsetzung erst nach Pauls OK:
   • „läuft super / mache ich automatisch" → Status In Erprobung → Aktiv, Bewährung bewährt
   • „bringt nichts / kostet mehr als es bringt" → Status Verworfen (Reflexion = Warum, Pflicht)
   • „gerade keine Energie / später" → Status Pausiert
   • „mal so mal so" → Bewährung gemischt
9. Nie Status oder Bewährung ohne explizite Bestätigung ändern.

Abschluss-Liste (optional, am Ende eines Laufs):

Kompakt 0–3 Kandidaten als reine Vorschläge:

• Verwerfen? — lange kein Touchpoint + Bewährung enttäuscht/gemischt.
• Promoten? — In Erprobung + mehrere positive Logs.
• Zusammenführen? — wenn zwei Einträge inhaltlich klar dasselbe Thema umkreisen, beiläufig fragen, ob Paul sie bündeln will. Nur Hinweis, keine Automatik, kein Default. Im Zweifel weglassen.
• Stille ist okay — lange still, aber bewährt = internalisiert, nicht als Problem melden.

---

Autonomer / geplanter Lauf (Cron — eigener Review außerhalb des Briefs)

Bei Schedule-Trigger ohne User-Input (eigener Cron-Job) oder wenn der Review headless startet:

• Auswahllogik Schritt 1–3 laufen lassen und die 1–2 Fragen ausgeben — sonst nichts.
• KEIN Touchpoint, KEIN Body-Log, KEINE Property-Änderung in diesem Lauf. Ein Schedule-Lauf hat keine synchrone Antwort von Paul; ohne echtes Statement wird nichts geschrieben (Regel aus Modus 2, Schritt 6, gilt unverändert). Der Lauf ist reiner Nudge.
• Protokolliert/aktualisiert wird erst, wenn Paul interaktiv auf die Frage antwortet (dann greift Modus 2 normal).
• Idempotenz ist gratis: Die Auswahl sortiert nach Letzter Touchpoint aufsteigend. Weil unbeantwortete Kandidaten keinen neuen Touchpoint bekommen, tauchen sie beim nächsten Lauf wieder oben auf — kein Dedup-State nötig, kein Doppel-Nudge-Risiko.
• Zustellkanal: Default = Chat-Output. Soll der Nudge gepusht werden, denselben Pfad wie agent-brief nutzen (Teams-Selbstchat, feste Chat-ID dort) — aber nur auf expliziten Wunsch, nicht als Default. Diesen Skill nicht mit eigener Versand-Logik aufblähen.

---

Einhängen in agent-brief (Wochen-Brief)

Der Praxis-Check läuft als Block im Wochen-Brief — als Reminder + Übersicht, damit die laufenden Vorsätze präsent bleiben und Paul aktiv dranbleibt. Platz: am Ende des /agent-brief weekly-Outputs, nach dem 2-Wochen-Ausblick, eigene H2-Sektion „Praxis-Check". Form:

• Kurze Übersicht (Reminder): die aktuell laufenden Praxis-Items (Status In Erprobung, hilfsweise zuletzt berührte) als knappe Liste, max. 3 — je Zeile die Aussage + wie lange seit letztem Touchpoint (bzw. „noch kein Feedback", wenn nie berührt). So sieht Paul auf einen Blick, woran er gerade arbeitet.
• Eine vertiefende Nudge-Frage zum am längsten stillen In Erprobung-Item (Logik aus Modus 2, Schritt 4) — konkret, die Aussage referenzierend.
• Reiner Nudge + Reminder, kein Schreiben. Der Brief geht oft async an Teams/Mail; es gibt keine synchrone Antwort. Keinen Touchpoint setzen, keinen Status ändern (wie beim Cron-Lauf). Das echte Check-in + Logging passiert, wenn Paul den Review interaktiv aufruft.
• Datenzugriff / Degradieren: Items read-only via scripts/notion_query.py --db productivity_hacks --filter "Status=In Erprobung" --sort "Letzter Touchpoint:asc" lesen (Token-basiert, läuft auch headless; löst die alte notion-search-Krücke ab und filtert exakt nach Status). Ist Token/DB nicht verfügbar, Sektion still weglassen — nie den Brief blockieren, nie Items/Zeiten raten.

Die Logik bleibt in diesem Skill; agent-brief liest read-only und rendert. Die Brief-seitige Sektion ist in agent-brief/references/weekly-brief.md ergänzt.

---

Log-Format (Body der Seite)

Verlauf wird ans Ende des Seiten-Bodys angehängt. Format:

### YYYY-MM-DD — <Kurzlabel>
<Pauls O-Ton / das Besprochene, knapp zusammengefasst>

Kurzlabel z. B.: Erfasst, Check-in, Promote → Aktiv, Verworfen, Pausiert.

Beim allerersten Anlegen wird der Body mit ## Verlauf plus erstem Eintrag initialisiert. Vor jedem späteren Append prüfen, ob ## Verlauf existiert — sonst zuerst anlegen.

---

Memory / Lernen

Dieser Skill lernt nicht im Sinne der Memory-Schicht (_shared/memory-contract.md). Er gehört zu keinem der drei Lern-Loops (Ton / Themenwert / Konstruktion) — analog agent-brief. Kein distill, keine memory/rules/, keine memory/logs/-Telemetrie.

• Die einzige „Wahrheit" ist die Notion-DB selbst (Status, Bewährung, Touchpoint, Verlauf-Body) — Domänendaten, kein Lern-Layer.
• Aus memory/state/ wird nur notion-ids.json gelesen (Schlüssel productivity-hacks) — Fakten, kein Lernen.
• Falls später ein Lern-Loop gewünscht ist (z. B. welche Herkunft/Art sich bewährt): erst über den Memory-Contract definieren und gegen die Boundary-Regel prüfen, nicht hier ad hoc anflanschen.

---

Haltung (gilt immer)

• Sparringspartner, nicht Buchhalter. Eine gute Frage zur richtigen Sache schlägt jede vollständige Tabelle.
• Kein Auto-Scoring, keine Gamification, kein Verfalls-Timer. Die einzige Wahrheit ist Letzter Touchpoint.
• Max. 1–2 Punkte pro Review (im Brief: 1). Lieber zu wenig als zu viel.
• Paul entscheidet jeden Lifecycle-Wechsel. Der Skill legt vor.
• Touchpoint nur bei echtem Statement. Stille bleibt sichtbar.
• bewährt + lange still ≠ Problem. Internalisiertes muss nicht gepflegt werden.
• Sprache: Pauls Voice (knapp, analytisch, kein Consulting-Sprech, keine Floskeln). Bei längeren Formulierungen voice-core mitladen.