Pascal MichelandClaude Opus 5
2c9a4475fc
Erster Stand des öffentlichen Ausschnitts aus dem Vault. Die .gitignore arbeitet als Positivliste: ausgeschlossen ist alles, eingeschlossen nur, was ausdrücklich wieder aufgenommen wird. Notizen, Projekte, Finanzen, das Sitzungsgedächtnis und settings.local.json bleiben damit außen vor. Der Kundenname in AI/Regelwerk/seo.md ist durch eine neutrale Bezeichnung ersetzt; die Regeln selbst sind unverändert. Co-Authored-By: Claude Opus 5 <[email protected]>
129 lines
6.0 KiB
Markdown
129 lines
6.0 KiB
Markdown
# 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.
|