SamuelChien/mega-skills-collection

Aktionspunkte → Todoist + E-Mail-Entwürfe

Konfiguration — vor dem Start lesen

../config/user.json lesen (wird aufgelöst zu ~/executive-assistant-skills/config/user.json). Extrahieren und während des gesamten Vorgangs verwenden:

• name, full_name — um Ihre Aktionspunkte in Meeting-Notizen zu identifizieren (z.B. "Gonto (Martin)")
• whatsapp — für die Ergebnislieferung
• workspace — absoluter Pfad zum OpenClaw-Workspace

Fahren Sie erst fort, wenn Sie diese Werte haben.

Debug-Protokollierung (PFLICHT)

Lesen Sie ../config/DEBUG_LOGGING.md für die vollständige Konvention. Verwenden Sie python3 {user.workspace}/scripts/skill_log.py action-items <level> "<message>" ['<details>'] bei jedem wichtigen Schritt. Protokollieren Sie VOR und NACH jedem externen Aufruf (gog, mcporter, todoist-cli). Bei jedem Fehler protokollieren Sie den vollständigen Befehl und stderr, bevor Sie fortfahren.

Schritte

0. Überprüfen Sie den heutigen Kalender auf Meetings (BEIDE Konten)

Bevor Sie Granola abfragen, rufen Sie die tatsächlichen heutigen Meetings aus BEIDEN Kalendern ab, um zu wissen, was Sie erwartet:

python3 {user.workspace}/scripts/skill_log.py action-items INFO "Starte Ausführung der Aktionspunkte"

# Heutiges Datum im Format YYYY-MM-DD und morgiges Datum ermitteln
TODAY=$(date -u -d "$(TZ=America/Argentina/Buenos_Aires date +%Y-%m-%d)" +%Y-%m-%d)
TOMORROW=$(date -u -d "$(TZ=America/Argentina/Buenos_Aires date -d '+1 day' +%Y-%m-%d)" +%Y-%m-%d)

# BEIDE Kalender prüfen
gog --account {user.primary_email} --no-input calendar list primary --from "${TODAY}T00:00:00-03:00" --to "${TOMORROW}T00:00:00-03:00" --json 2>&1
gog --account {user.work_email} --no-input calendar list primary --from "${TODAY}T00:00:00-03:00" --to "${TOMORROW}T00:00:00-03:00" --json 2>&1

Protokollieren Sie die Ergebnisse: python3 {user.workspace}/scripts/skill_log.py action-items DEBUG "Gefundene Kalenderereignisse" '{"primary": N, "work": M, "total": N+M}'

Führen Sie Ereignisse aus beiden Kalendern zusammen. Filtern Sie nach Meetings mit Teilnehmern (überspringen Sie Solo-/persönliche Ereignisse). Dies liefert die Grundwahrheit darüber, welche Meetings heute stattgefunden haben — verwenden Sie sie, um Granola-Ergebnisse gegenzuprüfen und Meetings zu erfassen, die Granola möglicherweise übersehen hat.

KRITISCHE Datumssyntax: Verwenden Sie explizite ISO8601-Daten mit dem Offset -03:00. Verwenden Sie KEINE relativen Ausdrücke wie +1 day, today oder tomorrow in gog-Flags — diese werden möglicherweise nicht unterstützt. Berechnen Sie immer die tatsächlichen Datumsstrings.

1. Heutige Meetings von Granola abrufen

Zeitzonen-Hinweis: Granola speichert Meeting-Zeiten in UTC. Für ART (UTC-3) bedeutet die Abfrage von "heute", dass sowohl das heutige als auch das morgige Datum in UTC verwendet werden. Z.B. für den 3. März ART, Abfrage mit custom_start: "2026-03-03" und custom_end: "2026-03-04", um alle ART-Tages-Meetings zu erfassen.

mcporter call granola list_meetings --args '{"time_range": "custom", "custom_start": "<heute YYYY-MM-DD>", "custom_end": "<morgen YYYY-MM-DD>"}'

Sammeln Sie Meeting-IDs und -Titel. Protokollieren: python3 {user.workspace}/scripts/skill_log.py action-items INFO "Gefundene Granola-Meetings" '{"count": N, "titles": [...]}'

Quervergleich mit Kalender: Vergleichen Sie Granola-Meetings mit den Kalenderereignissen aus Schritt 0. Wenn ein Kalendermeeting mit Teilnehmern keine Granola-Übereinstimmung hat (durch Zeitüberschneidung innerhalb von 15 Minuten), protokollieren Sie eine Warnung — es wurde möglicherweise nicht aufgezeichnet. Fahren Sie mit dem fort, was Granola hat, notieren Sie jedoch nicht übereinstimmende Meetings in der Ausgabe.

Überspringen, wenn keine Meetings (weder von Granola noch aus dem Kalender).

2. Granola nach MEINEN Aktionspunkten + E-Mail-Triggern abfragen

mcporter call granola query_granola_meetings --args '{"query": "Was sind alle persönlichen Aktionspunkte, Folgemaßnahmen und Verpflichtungen von {user.name} ({user.full_name}) aus diesen Meetings? Nur Dinge, die ER erledigen muss, nicht das, was andere zugesagt haben. Fügen Sie für jeden Punkt die spezifische Person, Firma, das Projekt oder den Kandidatennamen hinzu — niemals generische Referenzen. Identifizieren Sie außerdem: alle Zusagen, etwas per E-Mail zu tun (Vorstellungen, Folgemaßnahmen, Senden von Dokumenten, Teilen von Informationen, Vernetzen von Personen usw.) und ob das Meeting ein ERSTES Meeting mit dieser Person/Firma war oder eine Folgemaßnahme.", "document_ids": ["<id1>", "<id2>", ...]}'

Übergeben Sie ALLE Meeting-IDs. Bewahren Sie Zitationslinks.

3. Todoist-Aufgaben erstellen

Hinweis: Laden Sie die Umgebungsvariablen im selben Befehl — jeder Shell-Aufruf ist eine neue Sitzung.

Lesen Sie {user.workspace}/skills/todoist-api/SKILL.md für die CLI-Nutzung. Erstellen Sie für jeden Aktionspunkt:

source {user.workspace}/.env && todoist-cli add "<ausführbarer Titel>" --description "<Kontext: Meeting-Name, Meeting-Datum/-Uhrzeit, wer hat angefordert, Granola-Link>" --priority <1-4> --labels "<relevant>"

Aufgabenbeschreibung MUSS enthalten:

• Meeting-Name (z.B. "Braintrust Weekly")
• Meeting-Datum und -Uhrzeit (z.B. "Mi 5. März, 15:00 ART")
• Wer hat angefordert / Kontext
• Granola-Zitationslink

Regeln:

• Nur Ihre Aktionen: Granola-Zusammenfassungen listen oft "nächste Schritte" ohne klare Eigentümerschaft auf. Seien Sie skeptisch — wenn die Aktion der anderen Person gehören könnte (z.B. "eigene Inhalte verdauen", "Verfügbarkeit prüfen", "sich melden"), erstellen Sie KEINE Aufgabe. Erstellen Sie im Zweifelsfall eine FOLGEAufgabe ("Ping X zu Y") anstatt einer Eigentümeraufgabe.
• Verpflichtungen anderer erfassen: Wenn die andere Person gesagt hat, dass sie etwas tun wird (z.B. "Ich melde mich in 2 Tagen"), erstellen Sie eine Folge-/Ping-Aufgabe mit dem entsprechenden Fälligkeitsdatum, nicht eine Aufgabe, die Sache selbst zu erledigen.
• Spezifität: Jede Aufgabe MUSS den spezifischen Namen der Person/Firma/des Projekts enthalten
• Fälligkeitsdaten: Wenn ein implizites Datum vorhanden ist, verwenden Sie --due mit natürlicher Sprache
• Labels: Markieren Sie: intro, follow-up, email, urgent nach Bedarf
• Priorität: 4=dringend/zeitkritisch, 3=zugesagte Ergebnisse, 2=allgemeine Folgemaßnahmen, 1=normal

Keine geteilten Aufgaben für aufeinanderfolgende Schritte (PFLICHT)

Erstellen Sie niemals separate Aufgaben für Schritte, die Teil desselben Workflows sind. Wenn die Aktion "X vorbereiten und dann X senden" ist — das ist EINE Aufgabe, nicht zwei. Beispiele:

• ❌ "Angebot erstellen" + "Angebot senden" → ✅ "Angebot erstellen und senden"
• ❌ "Entwurf schreiben" + "E-Mail senden" → ✅ "Entwurf schreiben und E-Mail an X senden"
• ❌ "Präsentation prüfen" + "Präsentation teilen" → ✅ "Präsentation prüfen und mit X teilen"

Eine Aufgabe pro Absicht. Der Benutzer wird die Schritte natürlicherweise in der Reihenfolge ausführen.

Aufgaben-Deduplizierung (PFLICHT)

Bevor Sie eine Aufgabe erstellen, führen Sie eine Duplikatsprüfung gegen offene Todoist-Aufgaben durch:

1. Vorgeschlagenen Titel normalisieren (Kleinschreibung, Satzzeichen trimmen, Leerzeichen zusammenziehen)
2. Offene Aufgaben durchsuchen (source {user.workspace}/.env && todoist-cli list --filter "!completed") und normalisierten Inhalt vergleichen
3. Nahezu identische Vorstellungsaufgaben als Duplikate behandeln (z.B. "Vorstellung David zu Marcos" vs "Vorstellung David (n8n) zu Marcos Nils")
4. Wenn Duplikat vorhanden: KEINE neue Aufgabe erstellen; Meeting-Kontext bei Bedarf an vorhandene Aufgabenbeschreibung anhängen
5. In der Ausgabe Deduplizierungsentscheidungen unter "Übersprungen als Duplikate:" melden

4. Folge-E-Mails entwerfen

Für JEDE E-Mail, die entworfen werden muss (Vorstellungen, Folgemaßnahmen, VC-Antworten, Senden von Dokumenten usw.):

• Lesen und befolgen Sie ~/executive-assistant-skills/email-drafting/SKILL.md — es ist die alleinige Quelle der Wahrheit für alle Entwurfsregeln, Stil, Vorlagen, Humanisierung und Zustellung
• Entwurfsauslöser aus Meeting-Notizen identifizieren:
  • Zugesagte Vorstellungen oder Folgemaßnahmen
  • Zugesagte Dokumente/PDFs/Präsentationen
  • Erstgespräch mit einem VC oder neuen Lead
  • Jede Zusage, jemandem eine E-Mail zu schreiben
• Wenn Sie sich nicht sicher sind, ob ein Entwurf erstellt werden soll → ENTWERFEN SIE IHN
• Ausnahme: Die Nur-Angebots-Verpflichtungsregel unten überschreibt dies. Wenn die Verpflichtung darin besteht, zuerst ein Angebot zu erstellen, entwerfen Sie KEINE E-Mail — erstellen Sie nur eine Todoist-Aufgabe.
• HGP-Präsentation: {user.workspace}/assets/HGP_Deck_2025.pdf — anhängen mit --attach {user.workspace}/assets/HGP_Deck_2025.pdf. Sagen Sie „Hypergrowth Partners-Präsentation“ im E-Mail-Text (nicht „Einseiter“ oder „unsere Präsentation“)
• Beim Entwerfen von Vorstellungen für bekannte Kontakte: Suchen Sie gesendete E-Mails nach früheren Vorstellungen an sie, verwenden Sie dasselbe Format, denselben Ton und dieselbe Beschreibung

Spezifische, harte Anforderungen für Vorstellungen (PFLICHT)

Wenn Aktionspunkte Vorstellungen beinhalten, befolgen Sie dies genau:

1. Erstellen Sie einen separaten Vorstellungsentwurf pro Vorstellungspaar (niemals mehrere Vorstellungen in einer generischen Folgemaßnahme zusammenfassen).
2. Betreff muss explizit sein: Vorstellung: <Person A> <> <Person B>.
3. Text muss enthalten:
   • eine Zeile, wer jede Person ist,
   • eine Zeile Kontext, warum diese Vorstellung stattfindet,
   • Abschluss mit Ich überlasse es Ihnen beiden, es von hier aus zu übernehmen. und {user.signature}.
4. Ersetzen Sie NIEMALS Vorstellungsentwürfe durch eine generische Zusammenfassungs-E-Mail wie "Tolles Meeting heute", wenn Vorstellungen zugesagt wurden.
5. Wenn Empfänger-E-Mails bekannt sind, erstellen Sie sofort Gmail-Entwürfe; wenn eine E-Mail fehlt, generieren Sie trotzdem den vollständigen Entwurfstext und melden Sie FEHLENDE_EMAIL: <Name>.
6. Fügen Sie im WhatsApp-Ergebnis einen Abschnitt Erstellte Vorstellungsentwürfe: hinzu, der jedes Vorstellungspaar auflistet und angibt, ob es in Gmail entworfen oder durch fehlende E-Mail blockiert wurde.

Erstgespräch mit VC / erstem Dealflow-Anruf (PFLICHT)

Wenn das Meeting ein ERSTES Gespräch mit einem VC oder einem Dealflow-Unternehmen ist:

1. Erstellen Sie einen Folgeentwurf für das erste Meeting (es sei denn, er wird durch die Nur-Angebots-Regel unten blockiert).
2. Verwenden Sie treffspezifischen Kontext im Text (was besprochen wurde, explizite nächste Schritte, konkrete Angebote), keine generischen Höflichkeiten.
3. Fügen Sie Ihre Positionierung (wie Sie arbeiten) hinzu und hängen Sie {user.workspace}/assets/HGP_Deck_2025.pdf bei, wenn relevant.
4. „Tolles Meeting heute“ ist nur für diese Klasse von Erstmeeting-Folgeemails erlaubt.

Nur-Angebots-Verpflichtungsregel (PFLICHT)

Wenn Sie sich verpflichtet haben, "ein Angebot zu erstellen" (oder gleichwertig: Angebot/Präsentation/Leistungsumfangsentwurf zuerst vorbereiten):

• Erstellen Sie NOCH KEINE ausgehende E-Mail.
• Erstellen Sie eine einzige Todoist-Aufgabe zur Erstellung UND zum Versand des Angebots — z.B. „Beratungsangebot für Gabriel (BairesDev) erstellen und senden“.
• Erstellen Sie KEINE separaten Aufgaben für "erstellen" und "senden" — das ist redundant. Eine Aufgabe deckt den gesamten Lebenszyklus ab.

5. Prüfen, ob vorhandene Todoist-Aufgaben in den heutigen Meetings erledigt wurden

Nach der Verarbeitung der Aktionspunkte prüfen Sie auch, ob vorhandene offene Todoist-Aufgaben während der heutigen Meetings behandelt/abgeschlossen wurden:

1. Offene Aufgaben auflisten: source {user.workspace}/.env && todoist-cli list
2. Für jedes Meeting prüfen, ob die Diskussion eine offene Aufgabe behandelt oder erfüllt hat (z.B. "KI-Strategie mit Colin teilen" → KI-Strategie direkt mit Colin im Anruf besprochen)
3. Wenn eine Aufgabe im Meeting eindeutig erledigt wurde, schließen Sie sie ab: source {user.workspace}/.env && todoist-cli complete <task_id>
4. Abgeschlossene Aufgaben in der Ausgabe melden: "✅ Abgeschlossen: [Aufgabe] — erledigt während [Meeting-Name]"

Dadurch bleibt Todoist sauber und spiegelt wider, was tatsächlich passiert ist.

Fehlerbehandlung

• Wenn gog calendar fehlschlägt: Fehler mit vollständigem Befehl + stderr protokollieren (python3 {user.workspace}/scripts/skill_log.py action-items ERROR "gog calendar fehlgeschlagen" '{"command": "...", "stderr": "..."}'), mit dem anderen Konto und/oder nur Granola fortfahren.
• Wenn mcporter call granola mit Authentifizierungsfehlern fehlschlägt: "⚠️ Granola-Authentifizierung abgelaufen, führen Sie mcporter auth granola --reset aus" melden und anhalten.
• Wenn todoist-cli fehlschlägt: Überprüfen, ob .env geladen und der Token gültig ist. Fehler melden.
• Wenn Grain MCP nicht verfügbar ist: Nur mit Granola-Extraktion fortfahren, in der Ausgabe vermerken: "⚠️ Grain nicht verfügbar, Ergebnisse sind nur von Granola."
• Wenn ein Schritt fehlschlägt, nach Möglichkeit mit den verbleibenden Schritten fortfahren — wegen eines einzelnen Fehlers nicht den gesamten Durchlauf abbrechen.

Deduplizierung (KRITISCH — verhindert doppelte Aufgaben)

Deduplizierung auf Meeting-Ebene

• ERSTER SCHRITT vor jeder Verarbeitung: {user.workspace}/state/processed-meetings-YYYY-MM-DD.json lesen (falls vorhanden — Array von Granola-Meeting-IDs)
• Meetings überspringen, deren ID bereits in dieser Liste vorhanden ist — NICHT erneut verarbeiten
• Sofort nach der Verarbeitung jedes Meetings (vor dem nächsten), seine Granola-Meeting-ID an die Datei anhängen. NICHT bis zum Ende warten — nach jedem Meeting schreiben, um Rennbedingungen mit anderen Cron-Jobs zu verhindern.
• Diese Datei ist die alleinige Quelle der Wahrheit dafür, „ob dieses Meeting heute bereits verarbeitet wurde?"

Hinweis: Titel sind für wiederkehrende Meetings mit demselben Namen fragil. Immer nach Granola-Meeting-ID deduplizieren.

Deduplizierung auf Aufgabenebene

• Bevor Sie IRGENDEINE Aufgabe erstellen, prüfen Sie SOWOHL offene ALS AUCH kürzlich abgeschlossene Aufgaben auf nahezu Duplikate:
  1. Offene Aufgaben abrufen: source {user.workspace}/.env && todoist-cli list
  2. Heutige abgeschlossene Aufgaben abrufen: Todoist Sync API completed/get_all mit since=<heute 00:00 UTC> oder source {user.workspace}/.env && todoist-cli list --filter "completed today" verwenden, falls unterstützt
  • Gleiche Person + gleiche Aktionsabsicht = Duplikat (z.B. "Morgane wegen Hank texten" und "Morgane (Braintrust) nach Hank-Anruf texten")
  • Normalisieren: Kleinschreibung, Klammern entfernen, Leerzeichen zusammenziehen
  • Wenn Duplikat in ENTWEDER offenen ODER abgeschlossenen Aufgaben vorhanden ist → ÜBERSPRINGEN, nicht erstellen
• Übersprungene Duplikate in der Ausgabe melden: "⏭️ Übersprungen (bereits vorhanden): [Aufgabe]"
• Warum abgeschlossene Aufgaben prüfen: Der Benutzer hat möglicherweise bereits eine Aufgabe abgeschlossen, die durch einen Post-Meeting-Cron früher am Tag erstellt wurde. Sie erneut zu erstellen, ist falsch — die Arbeit ist erledigt.

Warum beide Ebenen wichtig sind

Post-Meeting-Crons feuern pro Meeting. Der tägliche End-of-Day-Cron verarbeitet ALLE Meetings. Ohne Deduplizierung auf Meeting-Ebene wird dasselbe Meeting zweimal verarbeitet. Ohne Deduplizierung auf Aufgabenebene, selbst wenn das Meeting erneut verarbeitet wird (z.B. Dateischreiben fehlgeschlagen), werden einzelne Aufgaben nicht dupliziert.

Deduplizierung ist NICHT VERHANDELBAR

Wenn ein Meeting in processed-meetings-YYYY-MM-DD.json erscheint, verarbeiten Sie es UNTER KEINEN UMSTÄNDEN erneut — selbst wenn Sie denken, der Post-Meeting-Cron "könnte etwas übersehen haben." Der Post-Meeting-Cron hat es bereits bearbeitet. Wenn es Probleme gab, wird der Benutzer manuell eine erneute Ausführung anfordern.

Ausgabe

• Erstellte Aufgaben oder Entwürfe → Aufgaben mit kurzer Zusammenfassung auflisten
• Abgeschlossene Aufgaben (in Meetings erledigt) → mit ✅ auflisten
• Nennen Sie immer die spezifischen Meetings, die verarbeitet wurden (z.B. „aus dem Fyxer-Anruf, dem Braintrust Weekly, dem HGP Staff“) — sagen Sie niemals „aus den heutigen Meetings“
• Keine Meetings oder keine Aktionspunkte → KEINE_ANTWORT

Quervergleich mit Grain (AKTIV — Überprüfung auf Transkriptebene)

Grain MCP ist mit vollem Transkriptzugriff verfügbar. Nach der Extraktion von Aktionspunkten aus Granola:

1. Finden Sie das Meeting in Grain: mcporter call grain.list_attended_meetings --args '{}' Hinweis: Grains Schema unterstützt keine start_date/end_date-Filter. Rufen Sie mit leeren Argumenten auf und filtern Sie die Ergebnisse manuell nach start_datetime, um den heutigen Datumsbereich zu treffen.
2. Rufen Sie das Transkript ab: mcporter call grain.fetch_meeting --args '{"meeting_id": "<grain_meeting_id>"}'
3. Validieren Sie Aktionspunkte gegen das Transkript:
   • Für jeden Aktionspunkt aus Granola prüfen, ob er tatsächlich im Grain-Transkript erwähnt wird
   • Nach verpassten Aktionspunkten suchen — Dingen, die im Transkript besprochen wurden, aber nicht in Granolas Zusammenfassung
   • Doppelter Zusicherungen prüfen: Wenn jemand anderes zugesagt hat, etwas zu tun, stellen Sie sicher, dass die Folgeaufgabe darauf ausgerichtet ist, ihn zu verfolgen, nicht die Aktion selbst auszuführen
   • Wenn Diskrepanzen gefunden werden (fehlende Aktionspunkte, falsche Eigentümerschaft): Protokollieren Sie mit python3 {user.workspace}/scripts/skill_log.py action-items WARN "Transkript-Diskrepanz" '{"meeting": "...", "granola_item": "...", "transcript_evidence": "..."}' und geben Sie dem Granola-Element KEINE Priorität — das Transkript ist die Wahrheit. Verwenden Sie das Transkript, um sich bei Diskrepanzen zu entscheiden.

Warum dies wichtig ist: Granolas KI-generierte Zusammenfassungen verpassen manchmal Aktionspunkte, weisen Eigentümerschaft falsch zu oder erstellen vage „nächste Schritte" ohne klare Eigentumsverhältnisse. Das Transkript gibt immer genaue Fakten wieder.

Abschluss

• WhatsApp-Ergebnis mit einer prägnanten Zusammenfassung senden
• Protokolldatei finalisieren

Wichtig: Überspringen Sie, wenn keine Meetings vorhanden sind (von Granola ODER Kalender). Produzieren Sie niemals eine leere Ausgabe oder Ausgaben mit leeren Listen — sagen Sie einfach KEINE_ANTWORT.