Was macht sync-project-docs?
Auditiert und aktualisiert die projektbezogenen Kontextdateien von Claude Code. Autonom für CLAUDE.md, Skills und Gedächtnis; zeigt Einstellungen als Vorschläge an, da diese eine explizite Benutzerautorisierung erfordern.
Phase 1 — Orientieren
Wenn das Projekt Git verwendet:
git log --oneline -20
git status --short
Dann git diff HEAD~5 -- <wichtige Dateien unten> um aktuelle Infrastrukturänderungen zu sehen.
Wenn kein Git-Repo vorhanden ist, lies die Verzeichnisstruktur und Schlüsseldateien direkt.
Finde heraus, welche dieser Dateien existieren:
| Suchen nach | Beispiele |
|---|---|
| Paket-/Abhängigkeitskonfiguration | package.json, pyproject.toml, Cargo.toml, go.mod, pom.xml, requirements.txt, Gemfile |
| Befehle | Makefile, justfile, scripts/, package.json Skripte, taskfile.yml |
| Infrastruktur | docker-compose.yml, fly.toml, render.yaml, Procfile, vercel.json, k8s/ |
| Anwendungskonfiguration | config.*, settings.*, config/, application.yml |
| Umgebungsvorlage | .env.example, .env.template, .env.sample |
Ziel: Wissen, welche Arbeit gelandet ist, was in Bearbeitung ist und welche Schlüsseldateien sich geändert haben.
Phase 2 — CLAUDE.md auditieren und aktualisieren
Überprüfe alle projektbezogenen Anweisungsdateien:
ls CLAUDE.md .claude/CLAUDE.md CLAUDE.local.md .claude/rules/ 2>/dev/null
Wenn keine CLAUDE.md existiert: Rufe den Skill init unter sub-skills/init/SKILL.md auf und fahre dann fort.
Wenn CLAUDE.md existiert, lies sie und gleiche jeden Abschnitt mit den Quellen aus Phase 1 ab:
Befehle — vergleiche mit der tatsächlichen Befehlsquelle. Korrigiere geänderte Befehle, füge nützliche neue hinzu, entferne gelöschte.
Architektur/Struktur — vergleiche beschriebene Module und Schlüsseldateien mit dem, was auf der Festplatte existiert. Füge neue hinzu; entferne gelöschte oder umbenannte.
Konfiguration/Umgebungsvariablen — vergleiche mit den tatsächlichen Konfigurationsdateien. Füge neue, zur Laufzeit relevante Einstellungen hinzu; entferne oder korrigiere veraltete.
Einschränkungen und Fallstricke — überprüfe, ob dokumentierte Einschränkungen durch aktuelle Arbeit gelöst wurden.
Umgebungsvorlage: Stelle sicher, dass sie alle Variablen auflistet, die die Konfiguration benötigt. Fehlende Variablen hier zerstören frische Einrichtungen.
@import-Referenzen: Scanne nach @/pfad/zu/datei-Zeilen und überprüfe, ob jede importierte Datei noch existiert. Ein fehlender Import zerstört stillschweigend das Laden des Kontexts.
Größe: Wenn die Datei 200 Zeilen überschreitet, markiere sie — darüber hinaus sinkt die Befolgungsrate und die Kontextkosten steigen. Schlage vor, Details in .claude/rules/-Themendateien zu verschieben.
.claude/rules/: Wenn dieses Verzeichnis existiert, überprüfe, ob pfadbezogene Regeldateien auf Befehle, Modulnamen oder Dateipfade verweisen, die nicht mehr zur aktuellen Codebasis passen. Korrigiere oder markiere veraltete.
CLAUDE.local.md: Wenn diese existiert, führe die gleiche Prüfung wie für CLAUDE.md durch — sie ist die git-ignorierte persönliche Ergänzung und kann ebenfalls veralten.
Sei chirurgisch: Aktualisiere, was veraltet ist, lasse korrekte Inhalte in Ruhe. Sie werden von einer zukünftigen Claude-Sitzung gelesen.
Phase 3 — Projekt-Skills auditieren
ls .claude/skills/ 2>/dev/null
Lese jeden Skill. Zwei Kategorien:
Infrastrukturgekoppelte Skills (ausführen, bereitstellen, migrieren, CI, Integration) referenzieren konkrete Dinge — Befehle, Dienste, Ports, Umgebungsvariablen, Dateipfade. Gleiche jeden mit Phase 1 ab:
- Existieren die referenzierten Befehle noch?
- Stimmen Dienstnamen, Ports und URLs noch?
- Existieren Umgebungsvariablen noch in der Konfiguration?
- Sind Dateipfade und Modulnamen noch gültig?
Korrigiere kleine Abweichungen direkt. Bei umfangreicher Überarbeitung eines Ausführungs-/Start-Skills (neue Startsequenz, große Dienständerungen) frage zuerst:
"Der Run-Skill sieht deutlich veraltet aus. Neu generieren mit
/run-skill-generator(verliert möglicherweise benutzerdefinierte Fallstricke) oder veraltete Abschnitte manuell umschreiben?"
Wenn kein Run-Skill existiert und der Start nicht trivial ist: schlage /run-skill-generator vor, falls verfügbar, oder /run als Fallback.
Prozess-/Workflow-Skills (PR-Vorlagen, Commit-Stil): Überprüfe nur, ob das Git-Log darauf hindeutet, dass sich der beschriebene Prozess geändert hat; ansonsten in Ruhe lassen.
Phase 4 — Gedächtnis
Der Gedächtnispfad wird aus dem Git-Repository-Stammverzeichnis (oder pwd außerhalb eines Repos) abgeleitet:
REPO=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
echo "$HOME/.claude/projects/$(echo "$REPO" | sed 's|/|-|g')/memory/"
Wenn Gedächtnis existiert: Rufe consolidate-memory auf.
Wenn keines existiert: Frage, bevor du etwas erstellst —
"Es existiert noch kein Projektgedächtnis. Auto-Memory ist bereits aktiv, also wird Claude es im Laufe der Zeit aufbauen — aber möchtest du, dass ich es jetzt mit wichtigen Fakten aus dieser Codebasis vorbefülle, damit deine nächste Sitzung sofort orientiert startet?"
Wenn ja: Befülle mit nicht offensichtlichen Fakten, die eine zukünftige Sitzung sonst Zeit mit erneutem Ableiten verschwenden würde:
- Überraschende Einschränkungen (Nebenläufigkeitsmodelle, Version Pins, unerwartete Standardeinstellungen)
- Aktuelle in Bearbeitung befindliche Arbeit und warum
- Nicht offensichtliche Entscheidungen, die im Code verankert sind
Erstelle MEMORY.md als präzises Index mit einem Eintrag pro Zeile. Detaillierte Notizen kommen in separate Themendateien (z.B. architecture.md, constraints.md) — MEMORY.md bleibt unter 200 Zeilen, damit es in das Sitzungskontextfenster passt.
Phase 5 — Einstellungen
Überprüfe .claude/settings.json auf veraltete Hooks, die auf Skripte oder Befehle verweisen, die nicht mehr existieren.
Identifiziere schreibgeschützte Befehle, die ständig vorkommen (Testrunner, Linter, Health Checks, git log, git diff) und sicher ohne Nachfrage erlaubt werden könnten.
Schreibe nicht in settings.json — präsentiere sie als Vorschläge. Verweise auf:
update-config: zum Hinzufügen von Berechtigungen, Umgebungsvariablen oder zum Korrigieren von Hooksfewer-permission-prompts: zum Entdecken von Berechtigungen aus dem tatsächlichen Transkriptverlauf
Phase 6 — Komprimieren
Alle Ergebnisse sind jetzt auf der Festplatte. Bevor du abschließt, erinnere den Benutzer daran, den Kontext zu handhaben, indem du den Befehl /compact ausführst, um von einem frischen Zustand aus zu starten.
Zusammenfassung
Gib eine Zusammenfassung der Änderungen aus:
## Projekt-Synchronisation abgeschlossen
**CLAUDE.md**: <was geändert wurde, oder "keine Änderungen nötig">
**Skills**: <was aktualisiert wurde, oder "aktuell">
**Gedächtnis**: <konsolidiert / vorbefüllt / "keine Änderungen">
**Einstellungsvorschläge**: <vorgeschlagene Erlaubnisse, oder "nichts hinzuzufügen">
**Git-Status**: <nicht committete Dateien + laufende Arbeit, ein Satz>
Führe `git diff` aus, um Dateiänderungen zu überprüfen.