Aufnahme-zu-Obsidian

Was macht Aufnahme-zu-Obsidian?

Verwandle ein Meeting oder eine Vorlesung in einen in sich geschlossenen, vollständig verknüpften Teil eines Obsidian-Vaults. Beide Modi teilen sich die Pipeline, die Konventionen und den Verifikationsschritt; sie unterscheiden sich darin, was extrahiert wird und wie die Notizen geformt werden.

	Meeting-Modus	Vorlesungsmodus
Zweck	sich merken, was entschieden wurde und wer was bis wann macht	die Ideen jederzeit schnell wiedererlernen
Hub	ein Meeting-Hub pro Sitzung + eine Serien-MOC mit einem Eintrag pro Meeting	eine MOC pro Vorlesung
Hauptnotizen	ADR-ähnliche Entscheidungsprotokolle; Themennnotizen für dauerhaftes Wissen	Anker-Notizen (dicht) + Atom-Notizen (eine Idee pro Notiz)
Rückverfolgbarkeit	Transkript-Zeitstempel [00:12:34] bei Entscheidungen und Aktionspunkten	PDF++-Folienlinks [[deck.pdf#page=5]]; Zeitstempel für nur gesprochene Inhalte
Referenz	references/meeting-mode.md	references/lecture-mode.md

<skill> bezeichnet den Ordner, in dem sich diese Datei befindet.

1. Pipeline

Materialien ──► 1 Setup ──► 2 Transkribieren ──► 3 Modus wählen ──► 4 Notizen-Schreiber ──► 5 Verifizieren ──► 6 Bericht
             config,      scripts/          meeting oder      schreibt Notizen     check_vault
             python       transcribe.py     vorlesung          (ein Subagent)       scan_secrets

1.1 Setup

Notieren Sie zuerst die Startzeit: Führen Sie date +%s aus und behalten Sie die Zahl; die Verifikation prüft nur Notizen, die danach geschrieben wurden.

Lesen Sie <skill>/config.toml. Es legt das Transkriptions-Backend/Modell/Sprache, die Diarisierung, notes.output_language, notes.default_mode und die Vault-Ordnernamen fest (notes_dir, moc_dir, meetings_dir, sources_dir; Standardwerte werden unten verwendet). Der Interpreter für die Skripte ist runtime.python; falls leer, verwenden Sie ~/.local/share/recording-to-obsidian/venv/bin/python. Nennen Sie ihn $PY – das ist eine Notation: Schreiben Sie in Befehlen die vollständigen, literalen Pfade des Interpreters und der Skripte, einen Befehl pro Aufruf, ohne Shell-Variablen oder cd … &&-Ketten (Agenten-Berechtigungsregeln entsprechen dem literalen Befehl, und Variablen machen ihn unprüfbar). Wenn er nicht existiert, sagen Sie dem Benutzer, er solle install.sh ausführen (README) – installieren Sie nicht per pip in die eigenen Python-Umgebungen des Benutzers.

Klären Sie die Fakten, bevor Sie fortfahren (fragen Sie nur nach Dingen, die Sie nicht ableiten können):

• Vault – der Pfad des Benutzers, andernfalls das aktuelle Arbeitsverzeichnis, wenn es .obsidian/ enthält oder der Benutzer „dieses Vault“ gesagt hat; schreiben Sie nur darin;
• Materialien – absolute Pfade aller Dateien; klassifizieren Sie jede nach Erweiterung: Audio/Video, Untertitel (.srt/.vtt), Folien (.pdf/.pptx), Notebooks/Code, Bilder/Fotos, Dokumente;
• Titel, Serie/Kurs, Datum – vom Benutzer, aus Dateinamen oder den Materialien; erfinden Sie niemals ein Datum oder eine Teilnehmerliste (schreiben Sie „TBD“ und sagen Sie es);
• Ausgabesprache – notes.output_language, sofern der Benutzer keine andere verlangt hat.

1.2 Transkribieren

Für jede Aufnahme ohne passende Untertiteldatei (gleicher Stamm) führen Sie aus:

$PY <skill>/scripts/transcribe.py <aufnahme> -o <scratch>/transcripts

• <scratch> ist ein temporärer Ordner außerhalb des Vaults (z.B. $TMPDIR/recording-to-obsidian-<date>-<slug>), der für alle Zwischendateien verwendet wird.
• Optionen bei Bedarf: --model small (schneller, grober), --language en (Erkennung überspringen), --diarize (Sprecher-Labels; benötigt install.sh --diarize und ein Hugging Face-Token in der Umgebungsvariablen, die durch diarize.hf_token_env angegeben wird). Beim ersten Ausführen wird das Modell heruntergeladen, was Minuten dauern kann; es gibt Fortschritte auf stderr aus – lassen Sie es abschließen.
• Es schreibt <stem>.srt und <stem>.txt (eine [HH:MM:SS] Sprecher N: text-Zeile pro Segment) und gibt eine JSON-Zusammenfassung aus (Sprache, Modell, Dauer, Sprecher, Bereinigungsstatistiken, Dateipfade). Behalten Sie diese Zusammenfassung: Sprache, Modell und Diarisierung fließen in den Quellen-Abschnitt der Notizen ein.
• Vorhandene Untertitel aus beliebigen Tools können auf die gleiche Weise normalisiert werden: $PY <skill>/scripts/transcribe.py talk.vtt -o <scratch>/transcripts (kein Modell beteiligt; Wiederholungsschleifen werden gefaltet und eine .txt mit Zeitstempeln wird geschrieben).
• Lange Aufnahmen sind in Ordnung: Das Skript verarbeitet stundenlanges Audio; teilen Sie die Datei nicht auf.

Wenn die Transkription fehlschlägt, melden Sie die Fehlerzeile; $PY <skill>/scripts/transcribe.py --check zeigt, was fehlt.

1.3 Modus wählen

Ein expliziter Modus vom Benutzer (oder notes.default_mode anders als auto) gewinnt. Ansonsten:

1. Folien, Notebooks, Labor-Code oder Handouts unter den Materialien → Vorlesung.
2. Lesen Sie sonst die ersten ~5 Minuten des Transkripts und überfliegen Sie den Rest:

Meeting-Signale	Vorlesungs-Signale
mehrere Sprecher mit vergleichbarer Redezeit	ein dominanter Sprecher erklärt
Agenda, Status-Updates, „wo stehen wir bei…“	„heute werden wir behandeln…“, „letzte Woche sahen wir…“
Vorschläge, diskutierte Abwägungen, „gehen wir mit…“, „einverstanden“	Definitionen, Ableitungen, durchgerechnete Beispiele, Übungen
Besitzer und Daten: „kannst du das bis Freitag übernehmen?“	Publikumsfragen, gestellt zum Verständnis, nicht zur Entscheidung
Projekte, Kunden, Fristen, Risiken	Kurs-/Vorlesungsnummerierung, Lektüre, Hausaufgaben

3. Gemischte Fälle gehen nach Zweck: Design-Reviews, Planungen, Retros, Debriefings und 1:1 sind Meetings; aufgezeichnete Tech-Talks, Trainings, Seminare und Tutorials sind Vorlesungen, selbst mit etwas Diskussion.

Notieren Sie die Wahl und die zwei oder drei Signale, die sie bestimmt haben (sie kommen in den Bericht). Wenn es eine echte Patt-Situation gibt und Sie fragen können, fragen Sie; ansonsten wählen Sie und sagen Sie warum.

1.4 Ausführungsmodell: Orchestrator + ein Notizen-Schreiber

Das Lesen eines gesamten Transkripts, eines Decks Seite für Seite und von Notebooks sowie das Schreiben dutzender Dateien füllt einen Kontextfenster schnell, also teilen Sie die Rollen auf:

• Orchestrator – die Sitzung, die die Anfrage erhalten hat. Sie erledigt 1.1–1.3 (Transkriptionsausgabe bleibt auf der Festplatte; sie liest nur genug vom Transkript, um den Modus zu wählen), übergibt das Schreiben an einen Notizen-Schreiber-Subagenten, führt dann die Verifikation in 1.5 durch und erstellt den Bericht.
• Notizen-Schreiber – ein Subagent, der die gesamte Schreibarbeit für den gewählten Modus in seinem eigenen Kontext erledigt: jedes Material lesen, planen, schreiben, selbst prüfen. Ein Meeting oder eine Vorlesung passt bequem in einen Kontext; teilen Sie keine Seiten oder Transkript-Abschnitte auf mehrere Agenten auf (das würde Querverweise verlieren und Notizen duplizieren).

Erledigen Sie die Arbeit selbst, anstatt zu delegieren, wenn kein Subagenten-Tool verfügbar ist, wenn ein Subagent nicht tun könnte, was der Job benötigt (siehe Bilder, Skripte ausführen, Dateien schreiben). Im Meeting-Modus dürfen Sie auch direkt schreiben, wenn das Meeting kurz genug ist, dass die Aufgabenbeschreibung so lang wäre wie die Arbeit (eine Aufnahme unter ~15 Minuten ohne Folien oder Dokumente). Der Vorlesungsmodus verwendet immer den Notizen-Schreiber, es sei denn, ein Subagent ist nicht verfügbar oder kann den Job nicht erledigen: Ein Deck muss Seite für Seite gelesen werden, und das gehört in den Kontext des Schreibers, nicht in Ihren. Sagen Sie im Bericht, was Sie gewählt haben. Die Verifikation (1.5) wird niemals übersprungen. Für mehrere Sitzungen verwenden Sie einen Notizen-Schreiber pro Sitzung, nacheinander, wenn sie an dieselbe MOC anhängen.

Aufgabenbeschreibung für den Notizen-Schreiber – er beginnt ohne Kontext, geben Sie ihm also alles:

• den absoluten Pfad dieses Skills; den Modus; die zu befolgenden Dateien: references/meeting-mode.md oder references/lecture-mode.md, plus references/note-templates.md, references/transcript-processing.md, references/mermaid-style.md;
• Vault-Pfad, Scratch-Ordner, $PY, Ausgabesprache, Titel/Serie/Datum (oder „ableiten“), Ordnernamen aus der Konfiguration;
• absolute Pfade aller Materialien und der Transkriptdateien, mit der Transkriptionszusammenfassung (Sprache, Modell, Sprecher);
• die bestehende Serien-/Kurs-MOC und die vorherige Sitzung Hub/MOC, falls vorhanden; alles, was der Benutzer spezifisch verlangt hat;
• Regeln: nur innerhalb des Vaults schreiben; niemals bereits bestehende Notizen ändern, außer den dokumentierten Anhängen; keine Geheimnisse;
• was zurückzugeben ist: den Berichtsblock aus Abschnitt 3 plus alles, was er nicht auflösen konnte.

1.5 Verifizieren (Orchestrator)

Wenn der Notizen-Schreiber zurückkommt, überprüfen Sie seine Arbeit unabhängig, anstatt seiner Zusammenfassung zu vertrauen:

$PY <skill>/scripts/check_vault.py <vault> --since <Epochensekunden beim Start des Jobs>
$PY <skill>/scripts/scan_secrets.py <vault>/sources

check_vault.py muss mit issues: 0 enden; beheben Sie auch Warnungen, es sei denn, es gibt einen Grund dagegen (sagen Sie welchen). Es löst Links so auf, wie Obsidian es tut (Dateiname oder Teilpfad, Groß-/Kleinschreibung ignorierend, #heading/|alias ignorierend, Code-Blöcke überspringend), daher ist ein gemeldeter defekter Link auch in Obsidian defekt. Es prüft: defekte [[Links]]/Einbettungen/Markdown-Links, PDF++-Links ohne .pdf, Frontmatter (title, type, date_created), Hub-Abdeckung (jede neue Notiz ist von einer MOC oder einem Meeting-Hub verlinkt; jeder Meeting-Hub von einer MOC), Geheimnisse; Warnungen für Notizen ohne Verbindungen, unstylisiertes Mermaid und mehrdeutige Links.

Überprüfen Sie dann, was die Skripte nicht können:

• keine bereits bestehende Notiz wurde geändert, außer den dokumentierten Anhängen (Serien-MOC-Eintrag, ersetzter Entscheidungsstatus, „nächster“-Link der vorherigen Vorlesungs-MOC);
• Meeting-Modus: jede Entscheidung hat ein Protokoll oder ist explizit nebensächlich; jeder Aktionspunkt hat einen Besitzer (oder TBD), ein Fälligkeitsdatum (oder TBD) und einen Zeitstempel;
• Vorlesungsmodus: die MOC listet jede neue Notiz genau einmal auf; die Granularität und Anker-Ziele der Vorlesung-Selbstprüfung sind erfüllt.

Beheben Sie kleine Probleme direkt; senden Sie größere mit der genauen Liste an den Notizen-Schreiber zurück. Führen Sie check_vault.py erneut aus, bis es 0 Probleme meldet. Löschen Sie den Scratch-Ordner (er enthält die WAV- und Seitenbilder), es sei denn, der Benutzer möchte ihn behalten.

2. Gemeinsame Konventionen

Vault-Layout – Notizen sind flach; Navigation erfolgt über MOCs und Hubs, nicht über Ordner.

vault/
├── notes/                         # Atom-, Anker-, Entscheidungs- und Themennnotizen (flach)
├── meetings/<serie>/              # Meeting-Hubs: „YYYY-MM-DD <titel>.md“
├── moc/<serie oder kurs>/         # Serien-MOC (Meetings) / eine MOC pro Vorlesung
└── sources/<serie oder kurs>/<YYYY-MM-DD oder Vorlesung_NN>/
    ├── <prefix>_transcript.srt / .txt
    ├── <prefix>.pdf               # Folien, für PDF++-Links
    ├── slide_images/  whiteboard_photos/  notebooks/
    └── structured_slides.json     # optionaler Seiten-für-Seite-Lesebericht

Geben Sie jeder Datei, die in sources/ kopiert wird, einen Serien-/Kurs- + Sitzungs-Präfix (Atlas_2026-11-12_transcript.srt, Optics101_L03.pdf, Optics101_L03_p08.jpg): Obsidian löst Links nach Dateinamen auf, daher würden zwei Sitzungen, die beide transcript.srt oder page-08.jpg enthalten, querverlinken. Ordnernamen verwenden den Serien-/Kursnamen mit Leerzeichen durch - ersetzt.

Dateinamen – der menschenlesbare Titel, keine IDs (Meeting-Hubs sind die Ausnahme: sie beginnen mit dem Datum, damit sie sortiert werden). Vermeiden Sie / \ : * ? " < > | # ^ [ ]; schreiben Sie — anstelle von :. Titel sind spezifisch genug, um allein zu stehen: Rate limits verwenden einen Token-Bucket pro API-Key.md, nicht Ratenbegrenzung.md.

Frontmatter – jede Notiz beginnt mit YAML-Frontmatter mit mindestens title, type und date_created. type ist moc, meeting, decision oder topic (Meeting-Modus) und moc, anchor oder atomic (Vorlesungsmodus). Modus-spezifische Felder sind in references/note-templates.md. Tags sind in Kleinbuchstaben und Kebab-Case auf Englisch: ein Serien-/Kurs-Tag, 2–4 Themen-Tags, ein Typ-Tag; verwenden Sie bereits im Vault vorhandene Tags wieder, bevor Sie neue erfinden.

Sprache – output_language = "auto" bedeutet: Schreiben Sie in der Sprache der Materialien (der erkannten Sprache des Transkripts oder der Folien). Wenn sich die Ausgabesprache von der Sprache der Materialien unterscheidet, behalten Sie technische Begriffe in der Originalsprache und glossieren Sie sie beim ersten Vorkommen: Chinesische Notizen aus einem englischen Meeting: 功能开关 (feature flag); englische Notizen aus einem deutschen Vortrag: error propagation (Fehlerfortpflanzung) – verwenden Sie dann die Form, die natürlich liest. Code, Befehle, Pfade, Produkt- und Toolnamen werden niemals übersetzt. Überschriften folgen der Ausgabesprache.

Links – jeder [[Wikilink]] muss zu einer Notiz oder Datei im Vault auflösbar sein. Verlinken Sie auf eine bestehende Notiz, anstatt eine Dublette zu schreiben. Verwenden Sie einen Pfad ([[sources/Atlas/2026-11-12/Atlas_2026-11-12_transcript.srt|transkript]]), wenn ein nackter Name mehrdeutig sein könnte. PDF++-Seitenlinks behalten immer .pdf: [[Optics101_L03.pdf#page=5|Folie S.5 "Snell's law"]].

Zeitstempel – zitieren Sie [HH:MM:SS] aus dem Transkript für jede Entscheidung, jeden Aktionspunkt und jede Behauptung, die nur aus Sprache stammt. Sie sind der Prüfpfad zurück zur Aufnahme.

Geheimnisse – schreiben Sie niemals Anmeldeinformationen in den Vault. Bevor Sie Notebooks oder Code in sources/ kopieren, führen Sie $PY <skill>/scripts/scan_secrets.py --redact <copy> auf der Kopie aus (Werte werden zu <REDACTED>, Variablennamen bleiben). Gesprochene Passwörter, Kartennummern oder sensible persönliche Daten in einem Meeting werden ebenfalls nicht protokolliert – schreiben Sie „Anmeldeinformationen wurden mündlich geteilt (nicht hier aufgezeichnet)“.

Visualisierungen – lesen Sie references/mermaid-style.md, bevor Sie ein Mermaid-Diagramm schreiben: Es enthält die Palette und die Regeln, die Diagramme rendern lassen. Ungültige Syntax ist schlimmer als kein Diagramm.

Modus-Ausgaben

• Meeting → references/meeting-mode.md: 1 Hub, 1 Entscheidungsprotokoll pro wesentlicher Entscheidung, 0–N Themennnotizen für wissenswertes Wissen, ein Eintrag angehängt an die Serien-MOC (bei erster Nutzung erstellt), Transkript in sources/ kopiert.
• Vorlesung → references/lecture-mode.md: 1 MOC, 8–15 Anker-Notizen für ein normales Deck mit 30+ Seiten, im Durchschnitt mindestens eine Atom-Notiz pro Inhaltsfolie, Folien/Notebooks/Transkript in sources/ kopiert.

3. Bericht

Meeting-Modus:

Meeting 2026-11-12 — <titel>  (Serie: <serie>)   Modus: meeting (Signale: …)
  Transkript: 00:41:07, mlx:whisper-large-v3-turbo, 3 Sprecher, en → Notizen en
  Hub: meetings/<serie>/2026-11-12 <titel>.md
  Entscheidungen: 3 (Protokolle: 3)   Aktionspunkte: 7 (Besitzer TBD: 1, fällig TBD: 2)
  Themennnotizen: 2   Offene Fragen: 2   Risiken: 1
  Serien-MOC: moc/<serie>/MOC — <serie>.md (Eintrag angehängt)
  check_vault: Probleme 0, Warnungen 0
  Ungelöst: <Sprecher nicht Namen zugeordnet, unklare Passagen, …>

Vorlesungsmodus:

Vorlesung NN — <thema>   Modus: vorlesung (Signale: …)
  Folien: 45 Seiten (Inhalt 37)    Wissenspunkte: 68
  Notizen: 56 atomar + 12 Anker     Archetypen: Konzept=34, Praxis-Demo=6, …
  Notizen pro Inhaltsfolie: 1.5     Anker mit ≥2 reichen Elementen: 12/12
  Mermaid: 14 (Typen: Sequenz, Mindmap, Flussdiagramm, …)
  Quellen: Optics101_L03.pdf, Optics101_L03_transcript.srt, notebook_classification.py
  MOC: moc/optics101/MOC — Optics101.md (erstellt)
  check_vault: Probleme 0, Warnungen 0
  Ungelöst: <nicht gefundene referenzierte Notizen, …>