# 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

```bash
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.