Meeting Digest

Werkzeuge: Aufrufe von Schritten und Rollenoperationen (pm.*, email.*, calendar.*, docs.*, files.*, comms.*). Löse jede Operation über Context/agent-config.md → Tool Stack und den dort benannten Adapter (.claude/adapters/README.md) auf. Eine auf none gesetzte Rolle → überspringe diesen Schritt.

Hole alle Meetings für einen Zieltag, finde die Notizen oder das Transkript für jedes Meeting, erstelle eine strukturierte Zusammenfassung und speichere sie lokal. Der Zieltag ist standardmäßig heute; übergib „yesterday", um den vorherigen Tag zu verarbeiten.

Konfiguration

Lies zu Beginn Context/agent-config.md. Verwende:

timezone — für alle Datumsberechnungen
base_directory — für die Dateipfadkonstruktion und Idempotenzprüfung
calendar_exclusions — Liste von Meeting-Titel-Mustern, die übersprungen werden sollen
Tool Stack → Meeting-Notizen — woher die Meeting-Inhalte kommen

Lies die Ziele-Datei (Pfad in agent-config), um in Schritt 4 Projekt- und Meilenstein-Namen zu erkennen.

Anleitung

Führe alle Schritte nacheinander aus. Frage zwischen den Schritten nicht um Bestätigung, es sei denn, es wird ausdrücklich eine Pause angefordert.

Schritt 1 — Alle nicht verarbeiteten Meetings des Zieltags abrufen

Phase A — Kalender: die Meeting-Liste holen

Berechne das Zieldatum in der Zeitzone des Benutzers. Standard = heute; wenn der Benutzer „yesterday" übergeben hat, subtrahiere einen Tag.
calendar.events(Start des Zieldatums, Ende des Zieldatums) in der Zeitzone des Benutzers.
Filtere auf echte Meetings. Entferne jedes Ereignis, bei dem:
- summary mit einem Muster in calendar_exclusions übereinstimmt
- es sich um einen Fokus-Zeit- oder Arbeitsort-Block handelt
- die attendees-Liste leer ist oder nur den Benutzer enthält (Einzelblöcke)
Sortiere chronologisch (ältestes zuerst). Dies ist die geordnete Liste der zu verarbeitenden Meetings.

Phase B — Idempotenzprüfung

Für jedes Meeting:

Leite den erwarteten Dateinamen der Notizen her: YYYY-MM-DD - [Meeting-Name].md unter Verwendung des Kalender-summary. Bereinige den Namen: Ersetze /, \, : und | durch -, entferne Emojis, fasse wiederholte Leerzeichen zusammen.
Prüfe, ob eine Datei mit diesem Namen bereits in [base_directory]/Context/Meeting Notes/ existiert.
Wenn sie existiert und bereits einen ## Summary-Abschnitt hat → überspringe dieses Meeting. Ausgabe: „Notizen für [Meeting-Name] existieren bereits — überspringe.“
Wenn sie als Roh-Notizen existiert (kein ## Summary) → verwende ihren Inhalt als Quelle und fahre fort.
Wenn sie nicht existiert → fahre mit Phase C fort.

Phase C — Meeting-Inhalt finden

Überprüfe Quellen in dieser Reihenfolge und verwende die erste, die Inhalt hat:

Roh-Notizen-Datei — aus Phase B Schritt 4.
Konfigurierte Quellen — jeder Eintrag in agent-config → Meeting-Notizen-Quellen, in der Reihenfolge. Typische:
- Kalenderanhänge — ein Notiz-Dokument, das an das Ereignis angehängt ist → files.read mit seiner Datei-ID. „Nicht gefunden" bedeutet, dass es nicht mit dem Benutzer geteilt wird — überspringe stillschweigend
- docs.meeting_notes(date) — Treffer auf Titel oder Zeitfenster (±30 Min.); lese mit docs.read
Kalenderereignisbeschreibung — verwende sie nur, wenn sie echte Notizen enthält, nicht nur eine Tagesordnung oder einen Videolink.
Frage den Benutzer — liste die Meetings, die noch keinen Inhalt haben, in einer Nachricht auf: „Keine Notizen gefunden für: [Liste]. Füge Notizen oder ein Transkript für diejenigen ein, die du zusammengefasst haben möchtest, oder sage „skip".“

Wenn ein Meeting immer noch keinen Inhalt hat → markiere es als „keine Notizen verfügbar" und überspringe es.

Phase D — Bericht

Nach der Verarbeitung aller Meetings berichte:

Wie viele zusammengefasst wurden
Wie viele übersprungen wurden (mit Grund: bereits vorhanden / keine Notizen)

Schritt 2 — Kontext lesen

Bevor du Notizen-Inhalte verarbeitest, lies:

GOALS.md — um aktive Projekte und Ziele zu verstehen
Context/Memory/brain.md — um zu verstehen, wie der Benutzer denkt, seinen Wortschatz und was er als Entscheidung vs. Diskussion betrachtet

Schritt 3 — Notizen-Inhalt analysieren

Extrahiere für jedes Meeting mit Inhalt vier Dinge:

A. Zusammenfassung 2–3 Sätze. Ergebnis-zuerst: Worum ging es in dem Meeting und was war das wichtigste Ergebnis oder die wichtigste Änderung. Keine Liste der behandelten Themen — eine einzige kohärente Ergebnisaussage. Verwende die Stimme des Benutzers: direkt, ohne Bemühungsrahmen, führe mit dem Ergebnis.

B. Entscheidungen Explizite Zusagen, die die Richtung geändert, etwas festgelegt oder eine offene Frage geschlossen haben. Nur echte Entscheidungen — keine Vorschläge, keine Vielleichts. Format: was wurde entschieden und wer hat die Entscheidung getroffen (falls zuschreibbar).

C. Aktionspunkte Konkrete nächste Schritte mit einem benannten Verantwortlichen. Wende diese Logik pro Punkt an:

Wenn die Notiz eine bestimmte Person mit hoher Sicherheit als Treiber nennt → ordne ihr zu
Wenn die Zuständigkeit mehrdeutig oder geteilt ist → ordne dem Benutzer zu
Füge ein Projektmanagement-Element oder Projekt nur ein, wenn es explizit im Meeting erwähnt wurde (durch Schlüssel, Namen oder eindeutigen Bezug). Rückschlüsse oder Vermutungen sind nicht erlaubt — wenn keines erwähnt wurde, lasse die Projektspalte leer (—)
Notiere das vorgeschlagene Fälligkeitsdatum, falls im Meeting erwähnt, ansonsten leer lassen

D. Offene Fragen / Blockierer Ungelöste Fragen, aufgeworfene Blockierer oder Themen, die für ein zukünftiges Meeting zurückgestellt wurden. Diese kommen nur in die Notizen-Datei.

Schritt 4 — Projektverweise

Halte nur einen Punktschlüssel oder einen Projektnamen fest, wenn er explizit im Meeting erwähnt wurde — durch Schlüssel (z. B. ENG-123), durch Namen (z. B. „der Onboarding-Revamp-Meilenstein") oder durch eindeutigen Bezug.

Ziehe keine Rückschlüsse, suche nicht nach oder errate keine Projekte aus dem Meeting-Kontext. Es ist besser, das Feld leer zu lassen, als ein falsches zuzuweisen.

Schritt 5 — Notizen-Datei für das Meeting schreiben

Speichere die Zusammenfassung in Context/Meeting Notes/ mit diesem Dateinamensformat: YYYY-MM-DD - [Meeting-Name].md

Verwende den Kalender-summary als Meeting-Namen.

Dateiformat:

# [Meeting-Name]
*[YYYY-MM-DD] | [Dauer falls verfügbar] | [Teilnehmer aus dem Kalender falls verfügbar]*

## Zusammenfassung
[2–3 Sätze ergebnisorientierte Zusammenfassung. Was ist passiert und was hat sich geändert.]

## Entscheidungen
- [Entscheidung 1 — wer sie getroffen hat, falls bekannt]
- [Entscheidung 2]

## Aktionspunkte
| # | Aufgabe | Verantwortlicher | Projekt | Fällig |
|---|---------|------------------|---------|--------|
| 1 | [Aufgabenbeschreibung] | [Name / ich] | [Projektname (KEY-123) oder —] | [Datum oder —] |
| 2 | ... | ... | ... | ... |

## Offene Fragen & Blockierer
- [Frage oder Blockierer — was ist ungelöst und warum ist es wichtig]

## Kontext
[Hintergrund, Links oder Rahmeninformationen aus dem Meeting, die für zukünftige Referenzen nützlich sind. Maximal 3–5 Aufzählungspunkte.]

Wenn Roh-Notizen die Quelle waren (Phase B Schritt 4), behalte sie unter einem ## Roh-Notizen-Abschnitt am Ende — lösche niemals die Notizen des Benutzers.

Vor dem Speichern füge [[Wiki-Links]] zur Notiz für die Obsidian-Graphenkonnektivität hinzu:

Alle namentlich erwähnten Personen → [[Name]]
Alle Punktschlüssel → [[KEY-123]]
Schlüsselkonzepte, Projekte und Themen, die in mehreren Notizen wiederkehren → [[Konzept]]
Verlinke nur sinnvolle Erwähnungen — nicht jedes Wort, nicht innerhalb von Codeblöcken oder URLs

Bestätige dem Benutzer: „Meeting-Notizen gespeichert unter Context/Meeting Notes/[Dateiname].md“

Schritt 6 — Auf bestehende Aufgaben und Blockierer abgleichen

Nach dem Speichern:

Prüfe, ob eine Entscheidung oder ein Blockierer aus diesem Meeting mit einer offenen Aufgabe in Tasks/ zusammenhängt — wenn ja, vermerke es inline.
Wenn ein Blockierer aufgeworfen wurde, der bereits in GOALS.md als bekannter Blockierer existiert, markiere es: „Dieser Blockierer ([Name]) wurde auch in [vorherigem Kontext] aufgeworfen. Erwäge, ob er systemisch ist.“
Wenn das Meeting ein regelmäßiges 1:1 mit einer benannten Person ist, die ein Dokument in Context/121s/ hat, füge einen Sitzungsprotokolleintrag zu ihrem Dokument hinzu: Datum, 1-zeilige Zusammenfassung, alle neu hinzugekommenen offenen Punkte.

Meeting-Notizen enthalten personenbezogene Daten und werden niemals committet oder gepusht.

Schritt 7 — Zusammenfassung im Chat anzeigen

Nachdem alle Notizen lokal gespeichert wurden, zeige eine kombinierte Zusammenfassung für die gesamte Tagesübersicht an.

Struktur: Meeting → Thema → Entscheidungen + Aktionen unter jedem Thema.

📝 **Meeting-Übersicht abgeschlossen — [YYYY-MM-DD]** | [N] zusammengefasst | [N] übersprungen

*[Meeting-Name]*
  [Thema / Ziel oder Meilenstein]
    Entscheidungen
      - [Entscheidung]
      - [Entscheidung]
    Aktionspunkte
      - [Aufgabe] → [Verantwortlicher] [Fällig falls bekannt]

  [Thema 2]
    Entscheidungen
      - [Entscheidung]
    Aktionspunkte
      - [Aufgabe] → [Verantwortlicher]

Notizen gespeichert unter `Context/Meeting Notes/`

Gruppierungsregeln:

Erste Ebene: Meeting-Name
Zweite Ebene: Thema, Ziel oder Meilenstein, das/die in diesem Meeting besprochen wurde – verwende den einfachen Namen, niemals einen nackten Issues-Schlüssel
Dritte Ebene: Entscheidungen und Aktionspunkte als beschriftete Unterabschnitte unter jedem Thema
Wenn ein Thema keine Entscheidungen hat, lasse den Unterabschnitt Entscheidungen weg. Wenn es keine Aktionspunkte hat, lasse den Unterabschnitt Aktionspunkte weg.
Wenn ein Meeting nur ein Thema hat, zeige den Themennamen dennoch an — klappe ihn nicht ein
Lasse die Projektspalte bei Aktionspunkten in der Chat-Zusammenfassung weg — sie gehört nur in die Notizen-Datei

Schritt 8 — Angebot zur Aktualisierung des Entscheidungsprotokolls

Dieser Schritt wird nur ausgeführt, wenn mindestens eine Entscheidung aus allen zusammengefassten Meetings extrahiert wurde.

Frage einmal in einer einzigen Nachricht:

„Möchtest du eine dieser Entscheidungen in das Entscheidungsprotokoll eines PRD eintragen?

Entscheidungen von heute:

[Meeting-Name] [Thema] 1. [Entscheidung] 2. [Entscheidung]

Wenn ja, sag mir, welches Dokument (eine lokale Datei in Context/Document Hub/ oder eine Seite im Docs-Tool) und welche Entscheidungsnummern hinzugefügt werden sollen.“

Nummeriere die Entscheidungen fortlaufend über alle Meetings hinweg, damit der Benutzer sie anhand der Nummer referenzieren kann.

Warte auf die Antwort des Benutzers.

Wenn nein / überspringen: beende den Skill.
Wenn ja: fahre mit den folgenden Schritten für jedes von ihnen angegebene Dokument fort.

Für jedes bereitgestellte Dokument:

A. Das Dokument abrufen

Lokale Datei → lese sie.
Docs-Tool-Seite → docs.read.

B. Das Entscheidungsprotokoll finden

Scanne nach einem Abschnitt, dessen Überschrift „Decision Log", „Decisions Log" oder „Decisions" (Groß-/Kleinschreibung egal) enthält.

Wenn ein Entscheidungslog-Abschnitt mit einer Tabelle existiert: neue Zeilen werden an sie angehängt.
Wenn ein Entscheidungslog-Abschnitt existiert, aber keine Tabelle: füge die Tabelle direkt unter der Überschrift ein.
Wenn kein Entscheidungslog-Abschnitt existiert: füge einen neuen ## Entscheidungslog-Abschnitt und eine Tabelle am Ende des Dokuments ein.

C. Die Zeilen erstellen

Für jede vom Benutzer ausgewählte Entscheidung erstelle eine Tabellenzeile:

| [YYYY-MM-DD] | [Entscheidungstext] | [Status] |

Datum: das Meeting-Datum.
Entscheidung: exakter Text aus der Zusammenfassung — nicht umschreiben.
Status: Entschieden wenn explizit und endgültig. Ausstehend wenn der Text „TBD", „to be confirmed", „pending", „waiting on" enthält oder als ungelöst markiert wurde.

Wenn die Tabelle noch nicht existiert, erstelle sie zuerst mit dieser Kopfzeile:

| Datum | Entscheidung | Notizen/Status |
|-------|--------------|----------------|

D. Vorschau, dann aktualisieren

Zeige die hinzuzufügenden Zeilen an. Für eine lokale Datei schreibe sie. Für eine Docs-Tool-Seite warte auf das explizite OK des Benutzers, dann docs.update(ref, "Decision Log", rows) — ändere nur diesen Abschnitt.

E. Bestätigung

„Decision Log aktualisiert in [Dokumenttitel] — [N] Entscheidung(en) hinzugefügt.“

Randfälle

Keine Entscheidungen gefunden: Schreibe „Keine Entscheidungen getroffen — Diskussions-/Update-Meeting." Erfinde keine Entscheidungen.
Keine Aktionspunkte gefunden: Schreibe „Keine Aktionspunkte."
Meeting ist ein Standup oder <5 Min: Führe die Zusammenfassung dennoch durch, aber halte die Zusammenfassung auf einen Satz begrenzt.
Mehrere Notizen stimmen mit demselben Ereignis überein: Verwende diejenige, die der Startzeit des Ereignisses am nächsten ist.
Eine Quelle ist nicht verfügbar: Überspringe sie stillschweigend und fahre mit der nächsten in Phase C fort.
Docs-Seite nicht gefunden (Schritt 8): Melde den Fehler, bitte den Benutzer, die URL zu überprüfen, und biete einen erneuten Versuch an.
Entscheidungslog-Abschnitt mehrdeutig (Schritt 8): Wenn mehrere Überschriften passen könnten (z. B. „Key Decisions" und „Decision Log"), zeige beide und frage, an welche angehängt werden soll.
Doppelte Entscheidungen (Schritt 8): Scanne vor dem Einfügen vorhandene Zeilen. Wenn derselbe Entscheidungstext bereits vorkommt, überspringe ihn und notiere die Überspringung.

priscilarwagner/meeting-digest

Was ist meeting-digest?

In Ihrer bevorzugten KI fragen

Dokumentation