ingest-deep

name	ingest-deep
description	Deep ingest of a source (PDF/Markdown/URL/DOCX/PPTX/XLSX) in Karpathy multi-turn pattern. Forced Markdown conversion, block-refs to the source rendered as a discreet ↗ symbol. Mandatory step 1 is triage (cluster match, source diversity, tension hint).
trigger	ingest.deep|deep.ingest|karpathy|sense.?making|multi.?turn.*ingest|tiefe.*ingest|deep.?dive.*quelle
source	bundled
requiredTools	["ingest_triage","ingest_deep","ingest_document","read_file","write_file","update_frontmatter","get_frontmatter","ask_followup_question","move_file"]

/ingest-deep -- Karpathy Multi-Turn Deep-Ingest

TL;DR -- Pflicht-Workflow (lies das zuerst, in dieser Reihenfolge)

Egal ob die Quelle neu oder schon teilweise ingested ist, egal ob Stub-Notes existieren: du folgst exakt dieser Sequenz, KEIN Schritt darf uebersprungen werden.

Erster Aufruf in jedem Run: update_todo_list mit genau diesen fuenf User-sichtbaren Steps (Labels strikt uebernehmen, keine eigenen Plan-Labels erfinden):

1. Triage + Entscheidung (Ingest / Spaeter / Verwerfen)
2. Output-Modus + Themen-Auswahl
3. ingest_deep (Block-IDs in der Quelle setzen)
4. Sense-Making-Note oder Zettel schreiben
5. Backlinks in der Quelle setzen

Danach folgst du diesen Tool-Calls in dieser Reihenfolge:

1. ingest_triage auf die Quelle (Tool-Call).
2. Triage-Karte + Empfehlung im Chat zeigen (Text-Antwort).
3. ask_followup_question mit Optionen "Ingest / Spaeter / Verwerfen". STOPPE hier und warte auf User-Antwort.
4. Themen-Tabelle im Chat zeigen (Text-Antwort), aus den destillierten Insights der Quelle.
5. ask_followup_question "Welche Themen uebernehmen?" (Options: ["Alle"], Antwort als "Alle" oder Nummern-Liste). STOPPE und warte.
6. ask_followup_question Output-Modus (Sense-Making / Multi-Zettel / Nur Source-Note / Doch nicht ingesten). STOPPE und warte.
7. ingest_deep mit output_mode="source-only" und block_anchors aus den ausgewaehlten Themen (Tool-Call).
8. write_file fuer Sense-Making oder Zettel (1-N Tool-Calls je nach Modus). Entfaellt bei "Nur Source-Note".
9. update_frontmatter der Source-Note (Notizen: += alle neuen Notes). Entfaellt bei "Nur Source-Note" / "Doch nicht ingesten".

Existierende Stub-Notes (Notes, die schon vorhanden sind aber leer oder fast leer): Sie sind KEIN Resume-Trigger. Behandele sie wie Namens-Kollisionen in Step 4: User via ask_followup_question fragen ob ergaenzen oder Variante anlegen. Niemals stillschweigend mit write_file ueberschreiben, niemals den Skill-Workflow ueberspringen "weil es ja schon Notes gibt".

Details zu jedem Schritt unten. Aber: die obige 7-Punkt-Liste ist die Wahrheit. Wenn du im Detail-Text etwas zu finden glaubst, das mit der Liste konkurriert, gewinnt die Liste.

Wann nutzen

Tiefe Sense-Making-Notes fuer Forschungs-PDFs, lange Webclips, fachliche DOCX/PPTX, Zettelkasten-Material. Erwartung: 5-15 Minuten Dialog, persistente Vault-Aenderungen, Block-genaue Provenance.

Nicht fuer schnelle Inbox-Aufnahme (-> /ingest), nicht fuer Meeting-Transkripte (-> /meeting-summary).

Kosten-Disziplin (vor jedem Tool-Call lesen)

Karpathy-Multi-Turn ist teuer. Halte den Token-Verbrauch klein:

• Maximal 2 Tool-Calls vor dem User-Approval, maximal 1 Tool-Call beim eigentlichen Schreiben. Bei 32 Messages und einem 410-Seiten-PDF im Kontext kostet ein einziger Run > 10 EUR.
• STOP-on-Error. Wenn ein Tool fehlschlaegt, brich ab und sag dem User was er tun soll. Nicht in Retry-Loops verfallen.
• Keine Erkundungs-read_document-Calls. Quelle wurde dem Agent schon als <attached_document> oder Vault-File gegeben.
• Kein list_files als Workaround. Wenn der Pfad unklar ist, frag den User.

Sprache, Stil und Zeichensatz

Pflicht fuer alle Chat-Texte und alle erzeugten Notes:

• Sprache: Source ist deutsch -> Output deutsch. Source ist englisch -> Output englisch. Niemals Sprachen mischen (kein einleitendes "I'll start by..." wenn der Rest auf Deutsch ist).
• Umlaute korrekt: ä, ö, ü, ß. Nicht ae, oe, ue, ss schreiben.
• Keine em-dashes (—) und keine en-dashes (–). Stattdessen Punkt, Komma, Klammer oder Worte wie "und", "aber", "also". Gilt sowohl fuer Chat-Antworten als auch fuer den Body / das Frontmatter der erzeugten Notes.
• Keine generischen AI-Floskeln: kein "landscape", "leverage", "robust", "seamless", "delve", "crucial", "nuanced". Aktive Stimme, konkrete Worte.

Vorbereitung (interner Step -- NICHT in update_todo_list aufnehmen)

Diese Vorbereitung ist Skill-intern und wird vom User nicht im Plan gesehen. Das Plugin-UI zeigt nur die Steps 1-5; "Templates lesen" laeuft still im Hintergrund.

Obsidian-Settings lesen:

read_file path=".obsidian/app.json" und merke dir aus dem JSON:

• attachmentFolderPath -- Zielordner fuer Binaries (PDF/DOCX/PPTX/XLSX). Default Attachements/. NIEMALS hardcoden, immer aus app.json.
• newFileFolderPath -- Zielordner fuer neue Markdown-Notes (Source-Mirror, Sense-Making, Zettel). Default Inbox/.

Diese zwei Pfade ersetzen ueberall im Skill <attachmentFolderPath> und <defaultOutputFolder>.

Naming-Convention lesen (Pflicht):

read_file path="Tools & Settings/Templates/Dateinamens-Konventionen.md" und uebernimm das dort dokumentierte Schema fuer ALLE Notes und Binaries, die der Skill erzeugt oder verschiebt. Kurzfassung:

• Quellen / Binaries: Autor-Jahr_Titel.<ext> (z.B. Gibson-2026_How-AI-Changes-the-IT-Operating-Model.pdf). Bindestrich zwischen Autor und Jahr, Unterstrich zwischen Jahr und Titel, Bindestriche innerhalb des Titels.
• Mehrere Autoren: Autor1-und-Autor2-Jahr_Titel oder Autor-et-al-Jahr_Titel.
• Kein Autor: Organisationsname statt Autor (ZDF-2024_Lanz-Interview-Baerbock.md).
• Sense-Making / Zettel / MOC: keine strenge Regel, lesbarer Konzept-Titel (Jagged Intelligence.md, LLMs als Ghosts.md).
• Keine Leerzeichen in Binaries und Quellennotizen, keine Sonderzeichen ausser - und _.

Falls die Konvention-Note fehlt: nutze die Kurzfassung oben. Niemals das alte Schema Autor-Jahr-Titel (drei Bindestriche) verwenden -- das fehlt der Underscore und bricht Sebastians Sortierung.

Templates lesen:

Default-Pfade (vom First-Run-Wizard angelegt):

• DE: Templates/Notiz Template.md
• EN: Templates/Note Template.md

read_file path="Templates/Notiz Template.md" (oder EN-Variante). Wenn der Pfad fehlschlaegt, nicht retryen, nicht andere Pfade durchprobieren -- nutze den Inline-Default unten. Den Setting-Token (<settings.x.y>- Platzhalter im Skill-Text) NICHT als Pfad-String an read_file uebergeben.

Aus dem Template den Frontmatter-Block zwischen den beiden ---- Zeilen extrahieren. Achtung: Das Notiz Template.md schliesst mit ---\n---\n (zwei Trenner direkt hintereinander). Nimm nur den ERSTEN Frontmatter-Block, ignoriere das zweite ---. Der Template-Block ist ein verbatim String der dann pro write_file mit Werten befuellt wird.

Inline-Default (Fallback wenn Template-Read fehlschlaegt):

---
Zusammenfassung:
Themen:
Konzepte:
Quellen:
Meeting-Notizen:
Notizen:
Projekte:
Personen:
Kategorie:
  - Quellen-Notiz
tags:
Permanent: false
uid:
---

Frontmatter-Hygiene (Pflicht fuer JEDE Note die der Skill erzeugt)

Gilt fuer alle Frontmatter-Bloecke -- ob ingest_document-Mirror, Sense-Making-Note, Zettel oder MOC-Stub. Nicht nur Step 4.

1. Kategorie -- IMMER - Quellen-Notiz (DE) bzw. - Source note (EN). Alles, was der Skill aus einer Quelle ableitet (Sense-Making-Note, Zettel, Multi-Zettel), traegt diese Kategorie. Nicht - Notiz, nicht - Konzept, nicht - MOC, nicht - Permanent. Ausnahme: der Source-Mirror selbst (PDF/DOCX/etc.-Markdown-Spiegel) traegt - Quelle, weil er die Quelle IST.

   Das Template (Notiz Template.md) bietet oft mehrere Optionen zur Auswahl an (- Notiz, - Quellen-Notiz, ...). Diese sind Auswahl- Optionen, NICHT alle gleichzeitig aktiv. Aus der Liste IMMER nur - Quellen-Notiz behalten, die anderen entfernen.

2. ALLE String-Werte IMMER doppel-gequotet. Keine Ausnahmen, keine "wenn"-Klauseln, keine Pruefung ob Sonderzeichen drin sind. Strings sind alle Werte hinter einem Doppelpunkt, die KEINE der folgenden Sonderformen sind:

   • YAML-Liste (- ... darunter eingerueckt)
   • Boolean (true, false)
   • Zahl (42, 2026)
   • Leerer Wert (Feld ohne Inhalt)

   Beispiel:

   Zusammenfassung: "Gartner-Analyse von Miles Gibson: Wie KI das IT-Betriebsmodell veraendert."
   Autor: "Miles Gibson"
   URL: "https://www.gartner.com/document/code/846639"
   Typ: "Analyst Report"
   Jahr: 2026
   Permanent: false
   Themen:
     - "[[IT Operating Model]]"
   

   Jahr: 2026 und Permanent: false sind ungequotet, weil Zahl bzw. Boolean. Alles andere ist gequotet, auch Autor: "Miles Gibson" und URL: "https://..." -- auch wenn da kein offensichtliches Sonderzeichen drin steckt.

   Innerhalb von gequoteten Strings escape " mit \". Quotes um das Feld, nicht um die ganze Zeile.

   Verbot: Nie ein String-Feld ohne Quotes. Zusammenfassung: Gartner-Analyse... ist ein Bug, selbst wenn der Text harmlos aussieht -- der naechste Doppelpunkt oder das naechste Komma bricht den Parser.

3. Themen / Konzepte als YAML-Liste aus Wikilinks: Nicht als Komma-String, nicht als reine Strings. Jeder Eintrag ist ein gequoteter Wikilink, damit der Obsidian-Graph eine Kante zur Themen-/Konzept-Note hat:

   Themen:
     - "[[LLMs]]"
     - "[[Jagged Intelligence]]"
     - "[[Agentic Engineering]]"
   Konzepte:
     - "[[Ghost-Metapher]]"
     - "[[Verifiability]]"
   

   Komma-getrennt oder ohne Wikilinks bedeutet: keine Graph-Kante, kein Anschluss an MOCs / Theme-Hubs.

   Themen-Quelle ist die Triage-Karte (Pflicht): Uebernimm IN Themen: JEDE verwandte Note und jeden Cluster, den die Triage- Karte (Step 1) genannt hat -- als gequotete Wikilinks. Konkret:

   • Cluster-Match -> Themen: (z.B. "[[AI Agents]]")
   • Jeder Eintrag aus Verwandte Notes (Vault) -> Themen: (z.B. "[[Coding Agents]]", "[[GitHub Copilot Beast Mode v3.1]]")
   • Plus die thematischen Hubs aus dem Konzept-Titel der Note selbst (wenn z.B. "Jagged Intelligence" das Konzept ist und kein Triage-Hit, trotzdem mit aufnehmen).

   Diese Verlinkung ist das Hauptdeliverable des Skills neben den Notes selber. Wenn die Triage 5 verwandte Notes gefunden hat und die landen nicht im Frontmatter, ist der Run unvollstaendig -- pruefe das vor attempt_completion. Lieber zwei thematisch schwaechere Wikilinks als keine.

   Konzepte: kommen aus den Take-Aways selber (die Schluessel- begriffe der einzelnen Themen, z.B. "[[Ghost-Metapher]]", "[[Verifiability]]", "[[Jagged Intelligence]]").

   Personen: ebenfalls als gequotete Wikilink-Liste. Der Autor der Quelle gehoert immer rein (- "[[Miles Gibson]]"), plus weitere im Text genannte relevante Personen. Auch hier sind Unresolved Links OK. Nicht mit Autor: (Single-String-Feld) verwechseln -- beide koexistieren.

   Unresolved Links sind OK: Wenn ein Thema/Konzept noch keine Note im Vault hat, schreibe den Wikilink trotzdem -- Obsidian behandelt das als "Unresolved Link", und der Graph zeigt es als gepunkteten Knoten. Am Ende des Runs (vor attempt_completion): gib eine kurze Uebersicht der neuen Unresolved Links: "Neue Cluster-Vorschlaege: [[X]], [[Y]] -- als MOC anlegen?" via ask_followup_question. Bei Ja: schreibe eine Stub-MOC-Note (<defaultOutputFolder>/<Cluster>.md) mit Frontmatter Kategorie: - MOC und einem Base-Codeblock, der alle Notes mit Themen: [[<Cluster>]] listet.

4. Leere Felder nicht entfernen. Das Template enthaelt absichtlich leere Slots (Projekte:, Notizen:, etc.) -- der User fuellt die spaeter manuell. Stehen lassen.

5. uid: Feld: leer lassen. Wenn ein UID-Plugin installiert und per Auto-Generation konfiguriert ist (typisch via vault.on-create), uebernimmt das Plugin den Wert nach dem Schreiben automatisch.

UID-Plugin: Wir steuern es nicht aus dem Skill heraus. Wenn der User ein UID-Plugin (z.B. note_uid_generator) mit Auto-Generation konfiguriert hat, befuellt das Plugin das uid:-Feld eigenstaendig beim Note-Create. Skill schreibt uid: leer und macht keine execute_command-/call_plugin_api-Aufrufe dazu.

Step 0: Source-Typ erkennen (Pflicht, vor allem anderen)

Quelle kommt entweder als Chat-Attachment (User hat eine Datei in den Chat gezogen) oder als Vault-File (Datei liegt schon im Vault). Das macht einen riesigen Unterschied fuer die naechsten Schritte.

Indikator	Source-Typ
<attached_document name="..." format="pdf" pages="N"> ohne vault_path-Attribute	Chat-Attachment
<attached_document ... vault_path="...">	Vault-File (mit attachment-Hint)
User hat einen vault-relativen Pfad genannt (z.B. Attachements/Foo.pdf)	Vault-File
Keine der obigen Indikatoren	Nachfragen

Step 0a (Chat-Attachment): erst in Vault speichern

Chat-Attachments leben nur einen Turn. Der attachment_index ist ab Turn 2 nicht mehr gueltig. Fuer Karpathy-Multi-Turn brauchst du also einen Vault-Pfad VOR dem Dialog.

Ablage-Regel (verbindlich):

Source-Typ	Ablage-Pfad
PDF	Original-PDF nach <attachmentFolderPath>/<Autor>-<Jahr>_<Titel>.pdf. ingest_document (bzw. ingest_deep mit pdf-mirror) erzeugt zusaetzlich einen Markdown-Mirror in <newFileFolderPath>/<Autor>-<Jahr>_<Titel>.md.
DOCX / PPTX / XLSX	Original nach <attachmentFolderPath>/<Autor>-<Jahr>_<Titel>.<ext>, Markdown-Arbeitsnote nach <newFileFolderPath>/.
Markdown / Webclip	Direkt nach <newFileFolderPath>/<Autor>-<Jahr>_<Titel>.md. Keine Attachements/-Kopie.

<attachmentFolderPath> und <newFileFolderPath> kommen aus der Vorbereitung (.obsidian/app.json), NICHT hardcoden.

Filename-Convention -- aus Tools & Settings/Templates/Dateinamens-Konventionen.md:

Autor-Jahr_Titel.<ext> mit Bindestrich zwischen Autor und Jahr, Unterstrich zwischen Jahr und Titel, Bindestriche innerhalb des Titels. Beispiel: Gibson-2026_How-AI-Changes-the-IT-Operating-Model.pdf. Kein Leerzeichen, keine Sonderzeichen ausser - und _.

Vorgehen:

1. Bestimme den richtigen Filename gemaess Naming-Convention.

2. Chat-Attachment-Binaries werden automatisch im Vault abgelegt. Der AttachmentHandler legt PDFs/DOCX/XLSX beim Drop direkt in <attachmentFolderPath> ab und reicht den Pfad im <attached_document vault_path="...">-Attribut weiter. Lies das vault_path-Attribut, das ist der aktuelle Pfad der PDF.

3. Pfad-Tabelle (verbindlich, niemals verwechseln):

   Datei	Aktueller Pfad	Zielpfad nach diesem Step
   Original-PDF (.pdf)	<vault_path> aus dem Attachment	<attachmentFolderPath>/<Autor>-<Jahr>_<Titel>.pdf
   Markdown-Mirror (.md)	wird erst in Step 4 erzeugt	<newFileFolderPath>/<Autor>-<Jahr>_<Titel>.md

   <attachmentFolderPath> = Attachements/ (oder was in app.json steht). Da gehoeren NUR Binaries hin (.pdf, .docx, .xlsx). <newFileFolderPath> = Inbox/. Da gehoeren NUR Markdown-Notes hin. Niemals einen .md-Mirror nach Attachements verschieben und niemals eine .pdf nach Inbox.

4. PDF an die Convention bringen (move_file):

   • Wenn vault_path schon <attachmentFolderPath>/<Autor>-<Jahr>_<Titel>.pdf ist: nichts zu tun.
   • Wenn nicht (anderer Ordner oder anderer Name): move_file source=<vault_path> destination=<attachmentFolderPath>/<Autor>-<Jahr>_<Titel>.pdf.
   • Wenn vault_path leer ist (PDF nicht im Vault): STOPP. Frag den User via ask_followup_question "Die PDF konnte nicht automatisch ins Vault gespeichert werden -- bitte ziehe sie manuell nach <attachmentFolderPath>/<Autor>-<Jahr>_<Titel>.pdf und melde dich". Niemals stattdessen den Markdown-Mirror nach Attachements verschieben -- das verwechselt Binary und Mirror.

5. Markdown-Mirror erzeugen (ingest_document):

   ingest_document
     source_path="<attachmentFolderPath>/<Autor>-<Jahr>_<Titel>.pdf"
     output_path="<newFileFolderPath>/<Autor>-<Jahr>_<Titel>.md"
   

   source_path zeigt auf das .pdf im Attachments-Folder, output_path ist die .md im Inbox-Folder. Diese Zuordnung ist umgekehrt, wenn du sie verwechselst landet der Mirror in Attachements (Bug!) oder das PDF in Inbox (auch Bug).

6. header_content muss Frontmatter-Hygiene einhalten (siehe Vorbereitung). Konkretes Beispiel fuer den Source-Mirror einer PDF -- so MUSS das aussehen, jedes String-Feld in Quotes:

   ---
   Zusammenfassung: "Gartner-Analyse von Miles Gibson: Wie KI das IT-Betriebsmodell veraendert."
   Autor: "Miles Gibson"
   Jahr: 2026
   URL: "https://www.gartner.com/document/code/846639"
   Notizen:
   Themen:
     - "[[IT Operating Model]]"
     - "[[AI Transformation]]"
     - "[[CIO Leadership]]"
   Konzepte:
     - "[[Co-Leadership]]"
     - "[[Fusion Teams]]"
     - "[[Trust als IT-Deliverable]]"
   Meeting-Notizen:
   Personen:
     - "[[Miles Gibson]]"
   Kategorie:
     - Quelle
   Typ: "Analyst Report"
   tags:
     - gartner
     - ai-transformation
   Permanent: false
   uid:
   ---
   

   Beachte:

   • Zusammenfassung, Autor, URL, Typ: gequotet (Strings).
   • Jahr: 2026, Permanent: false: ungequotet (Zahl/Boolean).
   • Notizen:, Meeting-Notizen:, uid:: leer.
   • Themen, Konzepte, Personen: YAML-Listen mit gequoteten Wikilinks.
   • tags: YAML-Liste mit plain strings (tags brauchen keine Wikilinks, sind kein Graph-Konzept).
   • Kategorie: YAML-Liste mit EINEM Wert (- Quelle fuer den PDF-Mirror, - Quellen-Notiz fuer Sense-Making/Zettel).

7. Nach erfolgreichem Save: weiter mit Step 1 auf Vault-Basis.

Kein Versuch, im naechsten Turn nochmal attachment_index 0 zu nutzen. Es wird fehlschlagen.

Step 0b (Vault-File): direkt weiter

Continue mit Step 1.

Step 1: Triage + Decision (Pflicht-Sequenz, drei Aktionen)

Step 1 besteht aus genau drei Aktionen, alle drei sind Pflicht, KEINE darf uebersprungen werden. Wenn du nach Aktion 1 direkt zu Step 2 gehst, hast du den User uebergangen.

Aktion 1: ingest_triage aufrufen. Aktion 2: Karte + Empfehlung im Chat an den User zeigen. Aktion 3: ask_followup_question stellen, auf Antwort warten.

---

Aktion 1: ingest_triage aufrufen

Tool: ingest_triage

ingest_triage
  source_uri="vault://<path>"
  query="<2-5 zentrale Themen / Konzepte aus der Quelle, kommagetrennt>"

Voraussetzung: Source ist ein Vault-File. Bei Chat-Attachments hat Step 0a die Datei bereits in den Vault gespeichert.

query ist Pflicht-Parameter fuer eine echte Triage. Der Tool durchsucht damit Vault (semantic index), Memory (Facts) und History (past chats), damit die Triage-Karte verwandten Kontext aus dem gesamten Wissensbestand zeigt -- nicht nur Cluster-Klassifikation der einen Datei. Ohne query fallback auf basename + Frontmatter-Themen, das ist meist zu unscharf. Leite die Query aus dem <attached_document>- oder Note-Body ab (Titel + Hauptthemen).

URI-Format strikt:

Quelle	Korrekte URI	Falsch (wird abgelehnt)
Vault-File	vault://Attachements/foo.pdf	file:///foo.pdf
Vault-Note	vault://Notes/foo.md	foo.md
Webclip	https://example.com/x	example.com/x

file://-URIs werden vom Tool abgelehnt: Chat-Attachments leben nur einen Turn, jeder spaetere Read schlaegt zwingend fehl. Wenn die Datei nicht im Vault liegt -> erst Step 0a (in Vault speichern), nicht mit file:// triagen.

Output ist eine Triage-Karte:

• Cluster-Match aus der Ontologie
• Source-Domain-Diversity-Hint
• Verwandte Notes (Vault) -- top-K aus semantic index
• Verwandte Facts (Memory) -- token-overlap im Fact-Store
• Verwandte Chats (History) -- LIKE-Match in past conversations
• Empfehlung: Ingest / Spaeter / Verwerfen

---

Aktion 2: Karte + Empfehlung im Chat zeigen

Zeig die Karte dem User -- inklusive der drei Recherche-Bloecke. Direkt danach formulierst du eine eigene Empfehlung (nicht nur "hier ist die Karte"). Format:

Empfehlung: <Ingest | Spaeter | Verwerfen>

<2-3 Saetze Begruendung, die auf die konkreten Hits aus der Karte referenziert.>

• Anschluss-Punkte: <welche bestehenden Notes / Facts / Chats schliessen direkt an? Konkret benennen, mit [[Wikilinks]].>
• Luecken / Mehrwert: <was im Vault noch nicht gibt, was diese Quelle bringen wuerde.>
• Risiken: <Echo-Chamber (Source-Diversity-Warnung), Dubletten (gleiche Source schon ingested), Widersprueche zu Bestand.>

Beispiele:

• Empfehlung: Ingest. Karpathy-Talk uebersetzt das LLM-Mental-Model von "Tier" auf "Ghost"; das ergaenzt deine bestehenden Notes zu [[Coding Agents]] und [[GitHub Copilot Beast Mode v3.1]] um die konzeptionelle Klammer. Anschluss an Memory-Fact "5x-Multiplikator ohne Coding Agents". Luecke: kein Material zu "Verifiability als Engineering-Skill". Risiko: gering, andere Karpathy-Talks im Vault decken den Software-3.0-Aspekt schon ab.
• Empfehlung: Spaeter. Cluster bereits 4 Notes aus medium.com, Source-Diversity-Warnung 80%. Erst gegenposition-Material aus primaeren Quellen suchen.

---

Aktion 3: Decision via ask_followup_question (Pflicht, kein Skip)

Decision nach der Empfehlung IMMER via ask_followup_question. Auch wenn die Empfehlung "Ingest" lautet, auch wenn die Quelle in einem frueheren Run schon teilweise ingested wurde, auch wenn der User /ingest-deep selbst aufgerufen hat -- du wartest auf seine explizite Entscheidung:

ask_followup_question
  question: "Wie weiter mit dieser Quelle?"
  options: ["Ingest (Empfehlung folgen)", "Spaeter", "Verwerfen"]

Du machst KEINE Tool-Calls fuer Step 2 oder spaeter, bevor diese ask_followup_question gelaufen ist und der User geantwortet hat. Schick die ask_followup_question und stoppe. Nicht direkt hinterher Tool-Calls queueen.

Der /ingest-deep-Aufruf ist die Absicht, einen Ingest-Workflow zu starten -- nicht die Zustimmung, den Ingest tatsaechlich durchzufuehren. Die Triage-Empfehlung kann die Entscheidung umdrehen ("Spaeter" wegen Echo-Chamber-Risiko, "Verwerfen" weil schon vollstaendig ingested).

• Ingest -> Step 2.
• Spaeter -> Skill-Abbruch mit folgenden persistenten Effekten:
  • Triage-Log behaelt die Decision "spaeter" (das hat ingest_triage schon erledigt -- nicht erneut aufrufen).
  • Die Quelle bleibt unangetastet in ihrem aktuellen Folder (z.B. Inbox).
  • Keine derived Notes, kein Frontmatter-Update.
  • Beim naechsten /ingest-deep-Aufruf auf dieselbe Quelle zeigt die Triage-Karte "bereits triaged (spaeter)" und der User kann die Decision aendern. Sag dem User in der Abschluss-Antwort kurz: "Auf 'spaeter' gesetzt -- die Quelle bleibt in {Folder}. Beim naechsten /ingest-deep kannst du erneut entscheiden."
• Verwerfen -> Skill-Abbruch:
  • Triage-Log behaelt die Decision "verwerfen".
  • Quelle bleibt liegen (Skill loescht nichts).
  • Sag dem User: "Als nicht-relevant markiert. Wenn du die Datei loeschen willst, mach das manuell."

Wenn ingest_triage einen Fehler zurueckgibt (KnowledgeDB nicht offen, Pfad ungueltig, etc.): nicht retryen. Skip Triage, weiter mit Step 2 mit dem User informiert.

Step 2: Themen-Auswahl + Output-Modus

Pflicht-Reihenfolge: Zuerst Themen-Tabelle (Step 2a), dann Auswahl-Frage (Step 2b), dann Output-Modus (Step 2c). Niemals Tabelle ueberspringen -- der User entscheidet immer konkret welche Insights uebernommen werden, egal in welchem Output-Modus.

Step 2a: Themen destillieren + Tabelle rendern (Chat-Text)

Lies die Source (falls nicht schon im Kontext) und identifiziere die konkreten Themen / Insights / Take-Aways.

• Anzahl ergibt sich aus dem Inhalt, nicht aus dem Format. Eine dichte Source kann 15 eigenstaendige Themen tragen, eine duenne 3. Eine lange Source mit wenig Substanz auch nur 2-3. Keine Mindest- oder Soll-Anzahl -- nimm exakt das, was die Quelle hergibt.
• Einzeln benannt, nicht in "Buckets" gruppieren ("Code-bezogenes", "Praxis-bezogenes" sind keine Themen, sondern Sammelkategorien).
• Keine Verduennung. Wenn die Quelle nur 3 echte Insights hat, liste 3 -- erfinde keine zusaetzlichen, damit die Tabelle laenger wirkt. Lieber ehrlich knapp.

Tabelle als Chat-Text vor dem Tool-Call rendern, Format strikt:

| # | Thema | Kernaussage |
|---|---|---|
| 1 | LLMs als Ghosts | Single-context-Wesen ohne Memory zwischen Sessions. |
| 2 | Jagged Intelligence | Punktuelle Spitzenleistung neben krassem Versagen. |
| 3 | Vibe Coding vs. Agentic Engineering | Gefuehlsgeleitet ohne Verifikation vs. mit Taste + Memory. |
| 4 | Verifiability als Kernkompetenz | Bauen wird billig, validieren wird der Engpass. |
| 5 | Taste und Judgment | Was rein Geschmack war, wird Engineering-Skill. |
| ... |  |  |

Kernaussage = 1 knapper Satz, kein Marketing-Sprech.

Step 2b: Auswahl-Frage (welche Themen)

Direkt nach der Tabelle:

ask_followup_question
  question: "Welche Themen aus der Tabelle moechtest du uebernehmen? Klicke 'Alle' oder waehle 'Andere' und tippe die Nummern (z.B. '1,3,5' oder '2-6,9')."
  options: ["Alle"]

allow_multiple ist nicht gesetzt -- der User klickt "Alle" oder waehlt "Andere" und tippt Nummern frei. Parsing der Antwort:

• "Alle", "alle", "all" -> alle Themen aus der Tabelle.
• Komma-Liste wie 1,3,5 -> Nummern 1, 3 und 5.
• Range wie 2-6 -> Nummern 2, 3, 4, 5, 6.
• Gemischt wie 1,3-5,9 -> 1, 3, 4, 5, 9.
• Bei Antwort die du nicht parsen kannst: zurueckfragen via ask_followup_question.

STOPPE nach dem Aufruf, warte auf Antwort.

Step 2c: Output-Modus fuer die ausgewaehlten Themen

Direkt nach der Themen-Antwort:

ask_followup_question
  question: "Wie sollen die ausgewaehlten Themen abgelegt werden?"
  options: [
    "Eine Sense-Making-Note (alle ausgewaehlten Themen gebuendelt)",
    "Mehrere Zettel (ein eigenstaendiger Zettel pro Thema)",
    "Nur Source-Note behalten (Block-IDs setzen, keine derived Notes)",
    "Doch nicht ingesten (spaeter erneut entscheiden)"
  ]

STOPPE nach dem Aufruf, warte auf Antwort. Verarbeite:

• "Eine Sense-Making-Note" -> Step 3 mit den ausgewaehlten Themen, dann Step 4c (Modus A).
• "Mehrere Zettel" -> Step 3 mit den ausgewaehlten Themen, dann Step 4d (Modus B), ein Zettel pro ausgewaehltem Thema.
• "Nur Source-Note behalten" -> Step 3 mit den ausgewaehlten Themen (damit Block-IDs gesetzt werden). KEIN Step 4 (kein write_file fuer Sense-Making/Zettel). Skill endet nach Step 3 mit kurzem Status: "Source-Note + Block-IDs gesetzt, keine derived Notes erzeugt".
• "Doch nicht ingesten (spaeter)" -> Skill-Abbruch wie bei Step 1 Decision "Spaeter": Triage-Log auf "spaeter", keine derived Notes, Source unangetastet.

Die in Step 2b ausgewaehlten Themen sind ab hier die einzigen, die in Step 3 und Step 4 verarbeitet werden.

Step 3: ingest_deep auf der Quelle (source-only)

ingest_deep
  source_path="<vault-relativer Pfad zur Quelle>"
  mode="dialog"
  output_mode="source-only"
  cluster="<aus Triage>"
  block_anchors=[
    "<Anker-Text Thema 1, wortwoertlich aus dem Source-Body>",
    "<Anker-Text Thema 2>",
    ...
  ]

block_anchors ist Pflicht. Pro ausgewaehltem Thema aus Step 2a genau EINE wortwoertliche Phrase aus dem Source-Markdown:

• Wortwoertlich, nicht semantisch. Falsch: "LLMs als Ghosts" -- das ist deine Konzept-Beschreibung, kommt im Transkript nicht so vor. Richtig: "I would describe LLMs as just summoned ghosts" -- exakte Phrase aus der Source.
• 5-10 Woerter -- lang genug fuer Eindeutigkeit, kurz genug damit der Tool die Phrase in einer Source-Zeile findet.
• In Source-Sprache, nicht in Skill-Sprache. Das Karpathy-Transkript ist englisch -> die Anchors sind englisch. Auch wenn die Zettel auf Deutsch geschrieben werden.
• Eine Zeile pro Thema, in der gleichen Reihenfolge wie die Tabelle aus Step 2a.

Vorgehen vor dem Tool-Call:

1. read_file der Source-Note (Markdown / PDF-Mirror).
2. Pro Thema die genaue Original-Phrase identifizieren -- bei Transkripten typisch der Satz, in dem das Konzept zuerst genannt wird.
3. Liste als block_anchors zusammenstellen und ans Tool uebergeben.

Der Tool setzt ^block-N-Suffix an die matchenden Zeilen (idempotent, fuzzy-tolerant gegen Punctuation/Quote-Varianten) und gibt im Result die Map anchor-text -> block-id zurueck. Diese Map ist die einzige Quelle der Wahrheit fuer die [[<Source>#^block-N|↗]]-Links in Step 4 -- nimm die Block-IDs direkt von dort. Erfinde niemals Block-Ref-Nummern.

Wenn das Tool-Result eine "WARNUNG: N Anchor(s) wurden nicht gefunden" zeigt: Die Anchors haben nicht gematcht. Optionen:

1. read_file Source, suche bessere Phrasen, ruf ingest_deep erneut mit den korrigierten block_anchors auf.
2. Wenn auch der zweite Versuch nicht matched: schreibe den Zettel ohne #^block-Suffix, referenziere nur [[<Source>]]. Setze NIEMALS einen falschen Block-Ref (z.B. ^block-1 von einem alten Run) als Ersatz -- das fuehrt zu Mis-Provenance.

output_mode IST IMMER source-only. Andere Modi NICHT nutzen. Sense-Making und Zettel kommen in Step 4 vom Skill selber.

Bei PDFs steht der Markdown-Mirror dann in <defaultOutputFolder>/. Die block_anchors referenzieren den Mirror-Text (nicht das PDF- Original, das ist binary).

Wenn ingest_deep fehlschlaegt: nicht retryen, dem User Fehler zeigen, Skill-Ende.

Step 4: Sense-Making oder Zettel selber schreiben

Hier macht der Skill die echte Synthese -- NICHT das Tool. Der Agent schreibt alle Notes nach Step 3 in einem durchgehenden Run, ohne Mid-Run-Pause. Der User muss NICHT pro Note nochmal genehmigen.

Step 4a: Naming-Konvention

Sense-Making-Note und Zettel sind eigenstaendige Konzept-Notes -- sie haben aussagekraeftige Titel, die das Konzept benennen, NICHT den Source-Basename als Prefix.

❌ Falsch	✅ Richtig
Andrej Karpathy ... - Zettel 6 - LLMs als Ghosts.md	LLMs als Ghosts.md
Andrej Karpathy ... - Sense-Making.md	Karpathy zu Vibe Coding und Agentic Engineering.md
Andrej Karpathy ... - Zettel 8 - Taste und Judgment.md	Taste und Judgment als Coding-Kompetenzen.md

Die Verbindung zur Quelle stellt das Frontmatter Quellen: [[<Source>]] plus der Backlink in der Source (Step 5) her.

Bei Namens-Kollision (<Titel>.md existiert): read_file der existierenden Note. Wenn thematisch passend: ueber ask_followup_question fragen ob ergaenzen oder Variante anlegen (<Titel> (<Autor>).md). Niemals stillschweigend ueberschreiben.

Stub-Notes (existierende leere/fast-leere Notes mit passendem Titel) sind nicht anders zu behandeln als jede andere Namens-Kollision -- sie sind kein "Resume-Trigger", der dich an Step 1-3 vorbeischleusst. Auch wenn drei Stubs zur Quelle existieren, durchlaufe Step 1 (Triage

• ask_followup_question), Step 2 (Themen-Auswahl) und Step 3 (ingest_deep) vollstaendig. Erst in Step 4 stellt sich die Frage "existierender Stub fuellen oder neu nennen", und auch dort via ask_followup_question.

Step 4b: Frontmatter komponieren (pro Note)

1. Nimm den Template-Frontmatter-Block verbatim als String.
2. Fuelle die Felder hinter den Doppelpunkten ein.
3. Pflicht-Werte:
   • Quellen: -> [[<Source-basename>]] (bei Multi-Zettel: alle Zettel referenzieren die Source direkt, NICHT eine separate Bibliographie -- die existiert nicht mehr).
   • Kategorie: -> aus dem Template (- Quellen-Notiz / - Source note).
   • Zusammenfassung: -> 1-2-Satz-Quintessenz, NICHT identisch mit dem Body. Frontmatter ist Suchbarkeit, Body ist Ausformulierung.
4. uid: leer lassen. Das UID-Plugin uebernimmt das selbst nach dem Schreiben (siehe Vorbereitung). Kein eigener Tool-Call dafuer.
5. Niemals YAML-Parser nutzen. Block ist String.
6. Niemals doppelte ---. Wenn der Template-Block schon ---\n...\n---\n enthaelt, ist das DER Frontmatter-Block, ueberkleb ihn nicht.

Step 4c (Modus A: Sense-Making-Note -- EIN write_file)

write_file
  path = "<defaultOutputFolder>/<aussagekraeftiger Titel>.md"
  content = """
<TEMPLATE-FRONTMATTER VERBATIM, Werte gefuellt>

# <aussagekraeftiger Titel>

## Kernaussage

<1-3 Saetze, pointiert.>

## Take-Aways

- <Take-Away 1, ausformuliert.> [[<Source>#^block-N|↗]]
- <Take-Away 2.> [[<Source>#^block-M|↗]]
- ...

## Eigene Notizen

<Optional.>
"""

Block-IDs kommen aus dem ingest_deep-Result von Step 3 (Map anchor-text -> block-id). Erfinde keine Nummern. Bei PDF-Page-Refs: [[<Source>.pdf#page=N|↗]].

Frontmatter der Source erweitern: nach dem write_file -- da die Source-Note jetzt die Rolle der Bibliographie spielt, ergaenze ihr Frontmatter via update_frontmatter:

• Zusammenfassung: (falls leer) -> der Abstract.
• Themen: -> Komma-Liste der ausgewaehlten Themen aus Step 2a.

Step 4d (Modus B: Multi-Zettel -- N write_file im Auto-Loop)

KEINE Bibliographie-Note schreiben. Die Source-Note (bzw. der PDF-Markdown-Mirror) IST die Bibliographie -- sie hat schon Frontmatter mit Kategorie: - Quelle und die Block-IDs aus Step 3. Erstelle nur die N Zettel.

Auto-Loop: Schreibe ALLE N Zettel in einem Run, ohne Mid-Run- Pause, ohne User-Approval zwischen den write_file-Calls. Erst nach dem letzten Zettel weiter mit Step 4e.

Pro Take-Away EIN write_file:

write_file
  path = "<defaultOutputFolder>/<Konzept-Titel>.md"
  content = """
<TEMPLATE-FRONTMATTER VERBATIM, Werte gefuellt -- Quellen: [[<Source-basename>]]>

# <Konzept-Titel>

<Ein klar formulierter Gedanke in 1-3 Absaetzen. Eigene Worte, nicht
Source-Wortlaut. Was ist die Insight, warum ist sie relevant?>

## Quelle

[[<Source>]] -- siehe [[<Source>#^block-N|↗]]
"""

Die Block-ID N kommt direkt aus der Map des ingest_deep-Result von Step 3 (jeweiliges Thema -> Block-ID).

Source-Frontmatter erweitern (nach allen Zetteln, EIN update_frontmatter-Call): ergaenze die Source-Note um eine ## Abgeleitete Zettel-Section am Ende des Bodys (nicht im Frontmatter), die einen Base-Codeblock zur dynamischen Auflistung der Zettel enthaelt:

## Abgeleitete Zettel

\`\`\`base
from ""
where Quellen = link(this.file)
sort created asc
\`\`\`

Damit ersetzt die Source-Note die fruehere Bibliographie -- ein Knoten weniger, gleicher Effekt.

Step 4e: Verifizieren (am Run-Ende)

• Falls write_file-Fehler "File already exists" -> Step 4a (Namens-Kollision) anwenden.
• Bei YAML-Errors in Obsidian-Console (Can not update metadata...): die Note hat doppelte --- oder kaputtes Frontmatter. read_file, Frontmatter-Block sauber rekomponieren (Template verbatim + Werte), via write_file ueberschreiben.

Step 5: Backlink in der Quelle (PFLICHT, nicht skippen)

Diese Schritt-Sequenz ist obligatorisch. Der Skill ist nicht abgeschlossen, solange die Quelle nicht zurueck auf ALLE neu erstellten Notes verlinkt -- das ist Kern des bidirektionalen Zettelkasten-Grafen.

Sammle waehrend Step 4 die Pfade ALLER neu erstellten Notes in einer Liste createdNotes (egal ob Sense-Making oder N Zettel).

Reihenfolge in Step 5 ist strikt:

1. Source-Frontmatter lesen:

   get_frontmatter path="<Source-Pfad>"
   

2. Verifikation (AUDIT-024 I-1): Pruefe, dass das Frontmatter Kategorie: - Quelle (oder - Source) traegt. Wenn nicht: STOP und frag via ask_followup_question.
3. Notizen-Liste komponieren: Bestehende Notizen:-Eintraege aus dem get_frontmatter-Result + alle Pfade aus createdNotes (als [[basename]]-Wikilinks). Duplikate entfernen.
4. Frontmatter schreiben (REPLACE -- das Tool kennt kein append):

   update_frontmatter
     path="<Source-Pfad>"
     updates={
       "Notizen": ["[[note-1]]", "[[note-2]]", ...,
                   "[[neu-zettel-1]]", ..., "[[neu-zettel-N]]"]
     }
   

   Wichtig: das update_frontmatter-Tool macht REPLACE auf den Wert -- d.h. du musst die VOLLSTAENDIGE Liste (alt + neu) im updates-Objekt mitgeben. Wenn du nur die neuen reinschreibst, verlierst du die alten. Das war der haeufigste Fehlerfall.

Modi:

• Modus A (Sense-Making): createdNotes = die EINE Sense-Making-Note.
• Modus B (Multi-Zettel): createdNotes = ALLE N Zettel. Es gibt keine Bibliographie mehr -- die Source IST die Bibliographie.

Damit zeigt der Obsidian-Graph die Verbindung Quelle <-> alle abgeleiteten Konzept-Notes.

Output-Konvention (verbindlich)

Pro Aussage in der Sense-Making-Note (oder pro Zettel in Multi-Modus) muss am Satzende ein dezenter Block-Ref-Link stehen:

Letzter Satz der Aussage. [[source-mirror#^block-N|↗]]

Pflicht-Form:

• Display-Text immer nur ↗. Kein "Quelle:", kein "[1]".
• Inline am Satzende, ein Leerzeichen vor dem Link.
• Eine Block-Ref pro Kernaussage.

Verbote

• Keine [1]-Marker im Perplexity-Stil.
• Keine pdfStrategy: 'page-refs' in /ingest-deep (das ist /ingest-Default).
• Keine Halluzinationen: jede Aussage muss aus der Source belegt sein.
• Keine Retry-Loops. Bei Tool-Fehler: STOP, User informieren.
• Kein read_document als Erkundungs-Pre-Pass. Source-Text liegt bereits als <attached_document> oder Vault-File vor.
• Kein list_files zur Pfad-Suche. User fragen ist billiger.
• Bestehende User-Edits in MOC-Files nicht ueberschreiben.
• Kein ingest_deep mit output_mode != source-only. Das Tool generiert dort naive Transkript-Splitter mit <Source> - Zettel N- Titeln. Sense-Making und Zettel kommen aus Step 4 vom Skill selber.
• Kein Source-Prefix in Zettel-/Sense-Making-Titeln. Die Notes sind eigenstaendige Konzept-Notes, ihre Titel benennen das Konzept.
• Kein YAML-Re-Render des Templates. Der Template-Frontmatter-Block ist ein verbatim String, in den Werte hinter den Doppelpunkten eingesetzt werden. Niemals zerlegen und neu zusammensetzen -- das bricht das Frontmatter (Doppel----, verlorene Custom-Felder).
• Keine Transkript-Schnipsel als Zettel-Body. Ein Zettel formuliert EINEN Gedanken in eigenen Worten in 1-3 Absaetzen. Roher Source-Text gehoert nicht in den Body -- referenziere stattdessen via Block-Ref.
• Keine separate Bibliographie-Note bei Multi-Zettel. Die Source-Note (bzw. der PDF-Markdown-Mirror) IST die Bibliographie. Source-Frontmatter wird via update_frontmatter erweitert; der ## Abgeleitete Zettel- Block kommt in den Body, nicht ins Frontmatter. Eine separate <Source> (Bibliografie).md-Note ist Redundanz und wird nicht erzeugt.
• Kein Mid-Run-Pause beim Schreiben der Zettel. Wenn der User in Step 2a 12 Themen ausgewaehlt hat, schreibt Step 4d ALLE 12 Zettel in einem Run. Niemals nach 5 Zetteln stoppen und nachfragen. Der User hat in Step 2 entschieden.
• Keine erfundenen Block-IDs. Nutze nur die ^block-N-Werte aus dem ingest_deep-Result von Step 3 (Map anchor-text -> block-id). Wenn fuer ein Thema kein Block-ID generiert wurde (Anchor matchte nicht), referenziere die Source nur via [[<Source>]] ohne #^block.
• Step 0a (Templates lesen) NICHT in update_todo_list aufnehmen. Das ist Skill-interne Vorbereitung. Der User sieht nur Steps 1-5 im Plan.
• Skill nicht abschliessen ohne Step 5. Solange das Source- Frontmatter Notizen: nicht auf ALLE neu erstellten Notes zeigt, fehlt die bidirektionale Verbindung -- der Zettelkasten ist inkonsistent. Vor attempt_completion: pruefe via get_frontmatter, dass jeder Pfad aus createdNotes in Notizen: steht.
• Skill nicht abschliessen ohne Binary-Ablage. Wenn die Quelle ein PDF/DOCX/XLSX war (Chat-Attachment oder vorher schon im Vault), muss das Original am Ende in <attachmentFolderPath>/<Autor>-<Jahr>_<Titel>.<ext> liegen, mit korrektem Naming. Vor attempt_completion: pruefe ob das Binary dort existiert. Wenn nicht: move_file von der aktuellen Position (Chat-Attachments werden automatisch im Vault gespeichert -- du musst sie nie via Drag-and-Drop anfordern, nur ggf. umbenennen).
• Skill nicht abschliessen ohne Kategorie-Check. Vor attempt_completion: pruefe via get_frontmatter fuer JEDE neu erstellte Note (Sense-Making, Zettel), dass Kategorie: exakt - Quellen-Notiz ist (DE) bzw. - Source note (EN). Wenn nicht (z.B. - Konzept oder - Notiz): via update_frontmatter korrigieren, dann nochmal pruefen.
• update_frontmatter ist REPLACE, nicht APPEND. Bei Notizen: IMMER vorher via get_frontmatter lesen, alte + neue Eintraege zusammen ins updates-Objekt schreiben. Sonst gehen die bestehenden Notizen verloren.
• Keine un-gequoteten Wikilinks im Frontmatter. Quellen: [[Note]] ohne Quotes ist invalid YAML. Immer Quellen: "[[Note]]" oder als gequotete Liste.
• Keine un-gequoteten String-Werte im Frontmatter. Zusammenfassung: Gartner-Analyse..., Autor: Miles Gibson, URL: https://... -- alles falsch ohne Quotes. Strings sind ALLES, was kein YAML-Listen-Eintrag, kein Boolean (true/false) und keine Zahl ist. Auch bei Step 0 (ingest_document mit header_content) gilt das.
• Keine Komma-Strings fuer Listen-Felder. Themen: A, B, C ist EIN String. YAML-Liste mit - Bindestrichen schreiben, sonst greifen Obsidian-Tag-/Property-Filter nicht. Das gilt fuer JEDES Wikilink-Property (Themen, Konzepte, Personen, Quellen, Notizen). Block-Form (Themen:\n - "[[X]]") oder Flow-Form (Themen: ["[[X]]"]) sind beide ok. Auch bei einem einzigen Wert bleibt es eine ein-elementige Liste, damit spaetere Ergaenzungen den Type nicht wechseln muessen.
• Themen und Konzepte sind kategoriegebunden, nicht austauschbar.
  • Themen: zeigt ausschliesslich auf Notes mit Kategorie: Thema (Hub-Notes, breit/generisch, z.B. [[Agentic AI]]).
  • Konzepte: zeigt ausschliesslich auf Notes mit Kategorie: Konzept (spezifisch/abgegrenzt, z.B. [[AI Agents]]).
  • Cluster-Match aus der Triage-Karte ist ein Thema und gehoert nach Themen:. Take-Away-Kernbegriffe sind Konzepte und gehoeren nach Konzepte:. Verwandte-Notes aus der Triage werden je nach Kategorie: der jeweiligen Ziel-Note einsortiert; im Zweifel kurz read_file und das Kategorie:-Feld pruefen.
• Keine multi-value Kategorie. Aus den Template-Optionen genau EINE behalten.
• Kategorie ist NIE - Konzept, - Notiz, - MOC oder - Permanent bei Ingest-Notes. Aus Sources abgeleitete Notes (Sense-Making, Zettel, Multi-Zettel) tragen IMMER - Quellen-Notiz (DE) bzw. - Source note (EN). Das ist nicht verhandelbar -- der Konzept- charakter einer Note steht im Titel und im Body, nicht in der Kategorie. Ausnahme: Source-Mirror selbst, der traegt - Quelle.
• Keine Triage-Karte ohne Empfehlung. Step 1 muss IMMER mit einer expliziten Empfehlung (Ingest / Spaeter / Verwerfen) plus Begruendung enden -- nicht nur die Karte zeigen und User entscheiden lassen ohne Hinweis.
• Kein Skip von Step 1's Decision-Frage. Auch wenn die Empfehlung "Ingest" lautet und Step 1 wenige Sekunden dauern wuerde: die ask_followup_question ist Pflicht. Niemals direkt von Triage zu Step 2 durchlaufen, auch nicht "weil der User ja /ingest-deep aufgerufen hat". Der Skill-Aufruf startet den Workflow, die Decision -Frage entscheidet ob er ueberhaupt durchlaeuft.
• Keine Sprachmischung. Skill-Sprache folgt der Source/User-Sprache. Niemals "I'll start by..." in einem deutschen Run.
• Keine em-dashes (—) oder en-dashes (–) in Chat-Antworten oder erzeugten Notes. Punkt, Komma, Klammer, "und"/"aber" stattdessen.
• Keine semantischen block_anchors. Anchors sind wortwoertliche Source-Phrasen (5-10 Woerter), nicht Konzept-Beschreibungen. Bei Mismatch: lieber kein Block-Ref als ein falscher.
• Keine Themen/Konzepte/Personen als reine Strings -- nicht in der Source-Mirror-Note, nicht in Zettel. Immer als gequotete Wikilinks in YAML-Liste, sonst keine Graph-Kante. Die Frontmatter-Hygiene gilt auch fuer ingest_document's header_content.
• Keine Themen-Auslassung aus der Triage. Wenn die Triage-Karte Cluster-Match und Verwandte Notes (Vault) aufgelistet hat, MÜSSEN diese Wikilinks im Frontmatter der erzeugten Notes (Themen- Feld) erscheinen. Der Skill ist unvollständig wenn die Triage z.B. 5 verwandte Notes gefunden hat und im Frontmatter nur 1 davon steht.
• Kein open_note + execute_command fuer UID-Setzung. Das UID- Plugin (wenn vorhanden) macht's eigenstaendig via Auto-Generation beim Note-Create. Skill-eigene UID-Tool-Calls triggern unnoetige Editor-View-Wechsel und Re-Renders bei Frontmatter-Plugins (z.B. pretty-properties) und sind nicht erlaubt.
• Keine hardcoded Ablage-Pfade. Attachements und Inbox sind Sebastians aktuelle Default-Werte, koennen aber per Obsidian-Setting jederzeit anders sein. Lies .obsidian/app.json und benutze die Felder attachmentFolderPath und newFileFolderPath.
• Keine PDFs in <newFileFolderPath> liegenlassen. Binaries gehoeren nach <attachmentFolderPath>, mit Naming-Convention. Wenn eine PDF dort hineingerutscht ist (z.B. Inbox/foo.pdf), via move_file umziehen vor dem Ingest.
• Keine .md-Datei nach <attachmentFolderPath> verschieben. Auch nicht "weil die PDF gerade nicht da ist". Wenn die PDF fehlt: ask_followup_question an den User, nicht einen anderen File umbenennen. Attachements/ enthaelt NUR Binaries (.pdf, .docx, .xlsx, .pptx). Inbox/ enthaelt NUR Markdown-Notes.
• Kein altes Naming-Schema Autor-Jahr-Titel (drei Bindestriche). Korrekt ist Autor-Jahr_Titel mit Unterstrich zwischen Jahr und Titel -- so wie in Tools & Settings/Templates/Dateinamens-Konventionen.md dokumentiert.
• Keine neuen Ordner erstellen. Erlaubt sind ausschliesslich: Attachements/ (fuer Original-Binaries: PDF/DOCX/PPTX/XLSX), und <defaultOutputFolder>/ (Default Inbox/, fuer alle Markdown-Notes inkl. Mirror, Sense-Making, Bibliografie, Zettel). Kein Sources/, kein Knowledge/<cluster>/. Wenn der defaultOutputFolder fehlt, legt das Plugin ihn beim ersten Schreibvorgang an -- der Skill darf ihn nicht selber via create_folder anlegen.
• Keine Source-Duplikate. Wenn die Quelle bereits als Markdown-Note im Vault liegt, wird sie NICHT in <defaultOutputFolder>/ kopiert. ingest_deep setzt Block-IDs direkt in die Original-Note ein (Frontmatter bleibt erhalten). Ausnahme: PDFs/Office-Files bekommen einen Markdown-Mirror, weil der Originalcontent binaer ist.
• Kein Stale-Mirror-Workaround (BUG-029, Issue #312): Wenn die konkrete Source nicht lesbar ist (Attachment ist weg, Vault-Pfad nicht gefunden, Parser-Fehler), NICHT auf eine gleichnamige Vault-Datei ausweichen (Sources/<basename>-Mirror.md, Notes/<basename>.md, etc.). Eine alte Mirror-Datei ist NICHT die aktuelle Source -- Inhalte koennen veraltet, gekuerzt oder editiert sein. STOP, dem User die genaue Tool-Fehlermeldung zeigen, klaeren wo die Datei liegen soll. Auch nicht den Inhalt aus dem <attached_document>- Block im eigenen Kontext "rekonstruieren" und so tun, als sei das ein verifizierter Read -- entweder das Originaltext-Block explizit als Quelle nennen ODER die Datei in den Vault speichern und neu triagen.

Notfall-Pfad: write_file

Wenn ingest_document und ingest_deep beide fehlschlagen (z.B. Attachment weg, KnowledgeDB nicht initialisiert, Provider-Quota voll):

1. Extrahiere die Page-Struktur aus dem <attached_document>-Block in deinem Kontext (sucht nach ## Page N-Headings).
2. Schreibe via write_file eine Single-Note mit:
   • Frontmatter (source, year, etc.)
   • ## Overview
   • ## Kernaussagen mit pro Aussage [[<basename>#Page <N>|↗]]-Marker -- Page-Number aus dem geparsten Text ableiten
   • ## Originaltext mit dem vollstaendigen geparsten Text
3. Tu das in EINEM write_file-Call. Kein Edit-Loop.