Regelwerk, Agenten, Skills und Werkzeuge veröffentlichen
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]>
This commit is contained in:
Pascal MichelandClaude Opus 5 committed
commit
c064c729ed
82 files changed
+13428
No files matched your search
@@ -0,0 +1,128 @@
|
||||
# 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.
|
||||
Reference in new issue
Block a user