claude-werkzeuge/.vault-tools/obsidian-vault-navigator/references/workflows.md

Workflows

Alle Pfade unten gehen davon aus, dass der Skill unter .claude/skills/obsidian-vault-navigator/ im Vault liegt.

Frage beantworten („was habe ich zu X?")

1. vault_query.py --text x — bei vielen Treffern mit --type oder --path nachschärfen.
2. Trefferliste dem Nutzer als Wikilink-Liste zeigen (--format md), damit er in Obsidian direkt springen kann.
3. Reicht die Zusammenfassung für die Antwort, ist hier Schluss.
4. Sonst die 1–3 relevantesten Notizen öffnen. Bei langen Notizen vorher --format headings und nur den passenden Abschnitt lesen.
5. Kommt bei der Antwort etwas Neues heraus, das später wieder gebraucht wird: als Notiz ablegen oder an die bestehende anhängen.

Neues Code-Projekt

1. Prüfen, ob es das schon gibt: vault_query.py --text "<name>".
2. Passendes Template-Projekt suchen: vault_query.py --type template-project. Die use_when-Zeilen reichen zur Auswahl.
3. Anlegen: new_note.py --type project-code --title "Auth Service" --tags go,oidc --summary "…"
4. Wenn ein Template genutzt wird: dessen Ordner nach 10_Projects/<slug>/ kopieren, dann template_of: <template-slug> ins Frontmatter des neuen Projekts, und im Template-Projekt unter „Abgeleitete Projekte" den Rückverweis eintragen.
5. Area verlinken, repo/lang/stack füllen.
6. build_index.py.

Neue Recherche

1. Frage formulieren — eine Frage, eine Notiz. Passt die Frage nicht in einen Satz, sind es zwei Notizen.
2. new_note.py --type research --title "…" --project <slug>
3. question ins Frontmatter, Antwort zuerst schreiben, Belege darunter.
4. confidence ehrlich setzen; low ist ein nützlicher Wert, kein Makel.
5. Vom auslösenden Projekt aus verlinken, damit die Recherche nicht verwaist.
6. build_index.py.

Template-Projekt anlegen

Ein Template-Projekt entsteht meist rückwärts: Ein Projekt lief gut, die Struktur soll wiederverwendet werden.

1. Projektordner nach 40_Templates/project-templates/<slug>/ kopieren.
2. Projektspezifisches entfernen: Namen, Secrets, Kundendaten, Logs, Zwischenstände.
3. Platzhalter einführen und im Template index.md unter „Anwendung" dokumentieren, welche ersetzt werden müssen.
4. type: template-project, use_when und stack setzen.
5. build_index.py.

Inbox aufräumen

1. vault_query.py --path 00_Inbox --sort updated
2. Pro Notiz einen Zielort vorschlagen — mit der Regel aus references/vault-structure.md als Begründung.
3. Die gesamte Liste als Vorschlag zeigen und auf Freigabe warten. Erst dann verschieben, in Gruppen, nicht alles auf einmal.
4. Beim Verschieben Frontmatter vervollständigen (type, summary, tags).
5. build_index.py, danach vault_doctor.py, um tote Links zu finden, die durchs Verschieben entstanden sind.

Projekt abschließen

1. status: done, updated aktualisieren.
2. Im index.md einen Abschnitt „Ergebnis" ergänzen: was rauskam, was man beim nächsten Mal anders machen würde. Das ist der Teil, der später gelesen wird.
3. Lohnt sich ein Template-Projekt daraus? Siehe oben.
4. Kompletten Ordner nach 90_Archive/<slug>/ verschieben, status: archived.
5. build_index.py, dann vault_doctor.py gegen tote Links.

Wöchentliche Pflege

python3 .claude/skills/obsidian-vault-navigator/scripts/build_index.py --vault .
python3 .claude/skills/obsidian-vault-navigator/scripts/vault_doctor.py --vault .
python3 .claude/skills/obsidian-vault-navigator/scripts/vault_query.py --since 7 --sort updated
python3 .claude/skills/obsidian-vault-navigator/scripts/vault_query.py --status active --stale 90

Daraus wird eine kurze Lage: was ist neu, was liegt fest, was fehlt an Metadaten, was sollte ins Archiv. Änderungsvorschläge sammeln und gebündelt vorlegen, nicht einzeln durchführen.

Migration eines bestehenden Vaults

Der heikelste Fall — hier geht es um Dateien, an denen jahrelang gearbeitet wurde. Nie im Bulk, nie ohne Freigabe, und immer mit einer Rückfahrkarte.

1. Sicherung: Vault in Git nehmen (git init && git add -A && git commit) oder eine Kopie anlegen. Ohne das nicht anfangen — und den Nutzer das bestätigen lassen.
2. Bestandsaufnahme: build_index.py auf dem Vault, so wie er ist. Der Index läuft auch ohne Frontmatter; Typen werden dann aus Pfaden geraten oder auf note gesetzt. Danach vault_doctor.py für den Ist-Zustand.
3. Lage zeigen: Anzahl Notizen, Typverteilung, wie viele ohne Frontmatter, wie viele Waisen, größte Ordner. Erst danach über Struktur reden.
4. Struktur anlegen, ohne Bestehendes anzufassen: die Zielordner erzeugen, CLAUDE.md in die Wurzel, Templates einsortieren.
5. Frontmatter zuerst, Verschieben später. vault_doctor.py --fix-missing erst im Trockenlauf zeigen, dann auf einem Teilbereich mit --apply ausprobieren, Ergebnis gemeinsam ansehen, dann den Rest.
6. In Wellen verschieben, thematisch sortiert: erst die eindeutigen Fälle (klar erkennbare Projekte), dann Research, zuletzt der Rest. Nach jeder Welle build_index.py + vault_doctor.py, tote Links reparieren, Nutzer draufschauen lassen.
7. Restposten landen in 00_Inbox/ und werden nach und nach entschieden. Ein Vault muss nicht an einem Tag fertig sortiert sein.
8. Zusammenfassungen nachziehen: vault_query.py --no-summary liefert die Pflegeliste. Automatisch abgeleitete Summaries sind ein Start, kein Ergebnis — die 30 wichtigsten Notizen von Hand nachschärfen bringt mehr als 300 maschinell erzeugte Sätze.

Wenn der Nutzer in Claude Code arbeitet

Der Vault als Arbeitsverzeichnis öffnen, damit CLAUDE.md greift und die Skript-Pfade stimmen. Ist das Code-Repo eines Projekts das Arbeitsverzeichnis und der Vault liegt woanders, immer --vault <pfad> mitgeben — die Skripte brauchen kein Arbeitsverzeichnis im Vault.

Ein Muster, das sich lohnt: Am Ende einer Coding-Session die Projektnotiz aktualisieren (Stand, offene Punkte, getroffene Entscheidungen) und build_index.py laufen lassen. Die nächste Session beginnt dann mit einer Abfrage statt mit dem Wiederlesen des Repos.