Praxisprojekt Second Brain · Strukturieren
Frontmatter-Schema
Lernziele
- Du schreibst das Frontmatter für jeden der vier Seitentypen nach dem Schema dieser Lektion.
- Du begründest für jedes Feld, welche Abfrage oder Prüfung ohne es nicht ginge.
- Du hältst die Tags klein und lässt unbekannte Felder leer.
Das Frontmatter · engl. frontmatterEin Block mit Metadaten im YAML-Format ganz oben in einer Markdown-Datei, zwischen zwei Zeilen mit drei Bindestrichen. Obsidian zeigt ihn als Eigenschaften der Seite an.Im Glossar macht den Vault abfragbar, auch ohne Volltextsuche. Es kostet beim Schreiben fast nichts. Dataview, Skripte und der Agent selbst finden Seiten darüber nach ihrer Form: alle Konzepte, alle Quellen einer Autorin oder eines Autors, alle Seiten, die seit drei Monaten niemand angefasst hat.
Das Schema
Jede Seite beginnt mit diesen Feldern:
---
title: Kanonischer Name
type: source | entity | concept | synthesis
created: JJJJ-MM-TT
updated: JJJJ-MM-TT
aliases: [andere Namen für dasselbe]
tags: [zwei oder drei]
---
Quellenseiten ergänzen url, author und published. Entitätsseiten ergänzen kind mit einem der Werte person, org, product oder tool. Die Feldnamen bleiben englisch, damit Befehle, Skills und Skripte sie finden.
Bau das Frontmatter einer Seite selbst zusammen. Wechsle den Typ und sieh, welche Felder dazukommen. Leere Felder fehlen im Ergebnis.
Frontmatter bauen
---
title: Retrieval augmented generation
type: concept
created: 2026-11-11
updated: 2026-11-11
aliases:
- RAG
- retrieval-augmented generation
tags:
- to-revisit
---Der Baukasten schreibt Listen untereinander, mit Bindestrich pro Eintrag. So legt Obsidian Listen an, wenn du sie im Bereich Eigenschaften bearbeitest. Die Schreibweise in eckigen Klammern aus dem Schema oben ist ebenfalls gültiges YAML. Obsidian führt aliases und tags als Standard-Eigenschaften vom Typ Liste. Die alten Einzahlformen alias und tag unterstützt Obsidian seit Version 1.9 nicht mehr als Standard-Eigenschaften.
Warum jedes Feld zählt
type steuert jede Strukturabfrage und jede Lint-Prüfung. Ohne das Feld kannst du weder zählen, wie viele Konzepte du hast, noch Quellen finden, an denen kein Konzept hängt.
updated macht Überprüfung möglich. Veraltete Konzeptseiten sind nach unserer Einschätzung der Hauptweg, auf dem ein Vault verrottet, und ohne Datum findest du sie nicht. Der Befehl /stale listet Konzeptseiten, deren updated älter als neunzig Tage ist.
aliases lässt Links zusammenfinden, wenn dasselbe Ding drei Namen hat. Mehr dazu in der Lektion Namen und Aliase.
url auf einer Quellenseite unterscheidet ein Zitat von einer Behauptung. Eine Quellenseite ohne URL lässt sich nicht überprüfen.
Tags
Zwei oder drei pro Seite, aus einem kleinen, kontrollierten Vokabular, das du wirklich pflegst.
Tags scheitern auf eine bestimmte Weise: Das Vokabular wächst, bis es nichts mehr bedeutet. Fünfzig Tags, jeder einmal benutzt, sind schlechter als gar keine. Sie erwecken den Eindruck einer Ordnung und leisten nichts davon.
Halte die Liste in der CLAUDE.mdDie Anweisungsdatei, die Claude Code zu Beginn jeder Session liest. Claude Code lädt sie aus dem Startordner und aus jedem Ordner darüber und hängt die Inhalte aneinander.Im Glossar und weise den Agenten an, nur vorhandene Tags zu nutzen. Braucht er einen neuen, schlägt er ihn dir ausdrücklich vor, bevor er ihn verwendet.
Ordner und Links tragen die Struktur. Tags sind für Eigenschaften quer dazu, die in keines von beiden passen: unverified, to-revisit, disputed. Der Befehl /tags listet alle Tags mit ihrer Häufigkeit und schlägt vor, Einzelstücke und Beinahe-Synonyme zusammenzulegen.
Leere Felder
Kennst du einen Wert nicht, lass das Feld weg. Ein fehlendes published heißt: unbekannt, und das kann der Agent ehrlich sagen. Ein geratenes Datum steht drei Wochen später als Tatsache auf einer Konzeptseite.
Das Schema stabil halten
Ein neues Feld im Schema heißt: entweder jede Seite nachträglich ergänzen oder mit einem gemischten Vault leben, in dem Abfragen die ältere Hälfte übersehen.
Leg das Schema früh fest, halte es klein und ändere es nur mit gutem Grund. Änderst du es, lass einen Nachtrag über den ganzen Vault in einem Durchgang laufen. Der Befehl /schema prüft das Frontmatter gegen das Schema, meldet fehlende Pflichtfelder, falsche Typen, kaputte Datumsangaben und Tags außerhalb des Vokabulars und behebt die mechanischen Fehler selbst.
/schema
Merksätze
- Jede Seite hat title, type, created, updated, aliases und tags. Quellen ergänzen url, author und published, Entitäten kind.
- type trägt alle Abfragen und Prüfungen, updated findet veraltete Seiten, url macht Quellen prüfbar.
- Zwei oder drei Tags aus einer Liste in der CLAUDE.md, neue nur auf ausdrücklichen Vorschlag.
- Ein leeres Feld heißt unbekannt. Ein geratenes wird später zur falschen Tatsache.
- Das Schema bleibt klein und stabil. Jede Änderung bekommt einen Nachtrag über den ganzen Vault.
Prüf dich selbst
Denkfrage
Warum ist ein fehlendes published besser als ein geschätztes?
Ein fehlendes Feld sagt ehrlich, dass das Datum unbekannt ist, und der Agent gibt das so weiter. Ein geschätztes Datum sieht aus wie ein echtes. Der Agent übernimmt es in Konzeptseiten, und nach einigen Wochen ist nicht mehr zu erkennen, dass es nie belegt war.
Denkfrage
Du willst ein neues Feld confidence einführen. Was gehört zu dieser Änderung?
Du trägst das Feld mit seinen erlaubten Werten in das Schema in der CLAUDE.md ein. Dann lässt du einen Nachtrag über alle bestehenden Seiten in einem Durchgang laufen und prüfst mit /schema, dass keine Seite fehlt. Sonst übersehen Abfragen alle Seiten, die vor der Änderung entstanden sind.
Prüf dich selbst
Schema im Vault
0 von 5 erledigt
Quellen
- Obsidian Help: Properties
Eigenschaftstypen, Standard-Eigenschaften, Listen-Schreibweise, Einzahlformen seit 1.9 entfallen.