Eine zentrale Bibliothek für deine .claude-Konfiguration

Zehn Repos auf deiner Maschine. Jedes davon hat einen .claude-Ordner voller Agents, Skills, Commands, Hooks und einer CLAUDE.md. Ein paar davon sind aktuell. Die meisten sind schon seit Wochen veraltet. Den Code-Review-Agent, den du letzten Monat gefixt hast, gibt es nur in einem Projekt, nicht in den anderen neun. Dein Kollege hat einen Planning-Command gebaut, den du noch nie gesehen hast, weil er nur in seinem Repo liegt.

Das ist das .claude-Verteilungsproblem. Je mehr Projekte, desto schlimmer.

Quick Win: Richte ein privates Git-Repo ein, das deinen gesamten .claude-Inhalt an einem Ort bündelt, mit einer map.json, die steuert, welches Projekt was bekommt:

{
  "projects": {
    "~/projects/webapp": {
      "claude-md": "web-full",
      "skills": ["git-commits", "react", "frontend-design"],
      "agents": ["visual-explainer"],
      "commands": ["team-plan", "build"]
    }
  }
}

Ein Befehl führt die Synchronisierung durch, und der .claude-Ordner jedes Projekts stimmt dann mit seinem Eintrag in der Map überein. Passe einen Skill oder Agent vor Ort an, schick die Änderung zurück, und jedes andere Projekt, das diesen Eintrag referenziert, übernimmt den Fix beim nächsten Sync.

Warum die Verwaltung des .claude-Ordners wichtig ist

Arbeitest du in einer einzigen Codebase? Dann liegen deine Skills, Agents und Commands direkt neben dem Code. Alles ist griffbereit und alles ist aktuell.

Verteilst du dich auf fünf oder sechs Projekte, läuft alles auseinander:

Duplikate überall. Acht Repos haben jeweils eine eigene Kopie von git-commits, und keine zwei sind identisch.
Versionsdrift. Das Upgrade am Planning-Command letzte Woche ist nur in einem Repo gelandet. Der Rest läuft noch auf dem alten Stand.
Keine Koordination. Dein Kollege hat einen Datenbankmigrationsagent gebaut. Du hast deinen eigenen gebaut, weil seine Version für dich unsichtbar war.
Konfigurationschaos. Skills sind nur der Anfang. Hooks, settings.json, CLAUDE.md-Dateien, Agent-Definitionen und Slash-Commands kommen noch dazu. Jedes Projekt will eine andere Kombination.

Dateien kopieren ist der erste Impuls. Es fühlt sich schnell an und funktioniert kurz, dann bricht es innerhalb eines Monats zusammen. Jeder Entwickler, der Agents in vielen Repos betreibt, kennt diese Geschichte.

IndyDevDan hat das früh erkannt und eine rein agentenbasierte Lösung gebaut, die auf einem YAML-Katalog mit Verweisen auf externe Repos und Pfade setzt. Dieser Ansatz hat bewiesen, dass die Idee funktioniert. Der Einsatz in 10+ Projekten mit 30+ Skills und 19 Agents hat den nächsten Bedarf offenbart: mehr Struktur. Echtes Dateimanagement. Variantenunterstützung. Vollständige Abdeckung des .claude-Ordners. Eine Sync-Engine, die ihren Wert beweist.

Die Bibliotheksarchitektur

Die Bibliothek ist ein privates Git-Repo, das die gesamte .claude-Konfiguration enthält. Keine Zeiger oder Verweise auf andere Repos. Die Dateien selbst. Eine einzige Quelle der Wahrheit für jeden Skill-Ordner, jede Agent-Definition, jeden Slash-Command, jeden Hook, jede CLAUDE.md und jede settings.json.

Eine map.json an der Wurzel definiert, welches Projekt welche Inhalte bekommt. Ein Sync-Skript kopiert die richtigen Dateien an die richtigen Stellen. Ein Manifest im jeweiligen Projekt hält fest, was die Bibliothek besitzt, damit lokale Dateien sicher bleiben.

your-library/
├── map.json                    # Which projects get what
├── sync.mjs                    # Node.js sync engine
│
├── skills/                     # All skill folders
│   ├── git-commits/
│   ├── agentic-builder/
│   ├── react/
│   ├── growth-kit/
│   ├── session-management/
│   └── ... (31 skills in my library)
│
├── agents/                     # All agent .md files
│   ├── frontend-specialist.md
│   ├── backend-engineer.md
│   ├── security-auditor.md
│   ├── master-orchestrator.md
│   └── ... (19 agents in my library)
│
├── commands/                   # All slash commands
│   ├── team-plan.md
│   ├── build.md
│   ├── team-build.md
│   └── ... (16 commands in my library)
│
├── hooks/                      # All hook folders
│   ├── SkillActivationHook/
│   ├── ContextRecoveryHook/
│   └── Validators/
│
├── claude-mds/                 # CLAUDE.md variants (full replacement per project)
│   ├── CLAUDE--web-full.md
│   └── CLAUDE--product.md
│
├── settings/                   # settings.json variants
│   ├── settings--web.json
│   └── settings--product.json
│
└── rules/                      # .claude/rules/ files
    ├── repo-primer--webapp.md
    └── repo-primer--product.md

Acht Inhaltskategorien (Skills, Agents, Commands, Hooks, Rules, claude-mds, Settings und beliebige Dateien), alles aus einem einzigen Repo heraus verwaltet. Bei einem Sync öffnet die Engine map.json, sucht den Eintrag des Projekts und kopiert genau das, was dort steht. Nichts mehr, nichts weniger.

Die Map: Steuern, was wohin geht

map.json ist das Gehirn. Jeder Projekteintrag legt genau fest, welche Inhalte das Projekt bekommt:

{
  "$schema": "library-map-v1",
  "projects": {
    "C:/Github/my-webapp": {
      "claude-md": "CLAUDE--web-full",
      "settings": "settings--web",
      "skills": [
        "git-commits",
        "react",
        "frontend-design",
        "session-management"
      ],
      "agents": ["frontend-specialist", "quality-engineer"],
      "commands": ["team-plan", "build", "team-build"],
      "hooks": ["SkillActivationHook", "Validators"],
      "rules": [],
      "files": {}
    }
  }
}

Ein anderes Projekt kann eine völlig andere Kombination wählen. Ein SaaS-Repo holt sich die Agents backend-engineer, supabase-specialist und security-auditor zusammen mit den Skills postgres-best-practices und auth. Ein marketinglastiges Repo tauscht das gegen growth-kit, seo-specialist und content-writer. Ein Produktrepo bekommt ein schlankeres Set mit einer anderen CLAUDE.md und anderen Hooks. Die Bibliothek hält den gesamten Katalog, und jedes Projekt wählt seinen eigenen Ausschnitt.

Profile bündeln gemeinsame Konfigurationen, die mehrere Projekte teilen wollen:

{
  "profiles": {
    "web-default": {
      "claude-md": "CLAUDE--web-full",
      "settings": "settings--web",
      "skills": [
        "git-commits",
        "react",
        "frontend-design",
        "session-management"
      ],
      "agents": ["frontend-specialist", "quality-engineer"],
      "commands": ["team-plan", "build"],
      "hooks": ["SkillActivationHook", "Validators"]
    }
  }
}

Führe --profile web-default aus, wenn du ein neues Projekt startest, und der gesamte Web-Stack landet mit einem einzigen Befehl.

Varianten: Wenn eine Version nicht reicht

Profile lassen eine Lücke. Dein git-commits-Skill läuft in den meisten Repos gut, aber das Blog-Repo braucht eine angepasste Version, die extra Muster für MDX-Writing erkennt. Einen brandneuen Skill daraus zu machen ist zu aufwendig. Was du eigentlich willst, ist derselbe Skill mit einem projektspezifischen Hut.

Das Namensmuster ist name--variante, mit einem doppelten Bindestrich zwischen Basisname und Variantenbezeichner:

skills/
├── git-commits/                    # Base version
│   └── SKILL.md
├── git-commits--blog/              # Variant for blog projects
│   ├── SKILL.md                    # Modified version
│   └── references/
│       └── mdx-patterns.md         # Extra file this variant needs

In map.json wird der vollständige Name referenziert:

{
  "skills": ["git-commits--blog", "react", "frontend-design"]
}

Beim Sync landet git-commits--blog unter .claude/skills/git-commits/. Das --blog-Suffix existiert nur innerhalb der Bibliothek. Im Projekt ist davon nichts zu sehen. Die Variante ist ein eigenständiger Ordner. Andere Dateien, andere Struktur, anderer Inhalt. Das Einzige, was sie mit der Basis teilt, ist der Deploy-Name.

Der Push ist der Moment, wo sich das Ganze auszahlt. Bearbeitest du .claude/skills/git-commits/ in deinem Blog-Projekt, öffnet die Engine beim Push das Manifest, stellt fest, dass das lokale git-commits auf git-commits--blog zeigt, und leitet die Änderungen dorthin weiter. Andere Projekte ziehen weiterhin aus der einfachen Basis.

Operationen

Die Sync-Engine ist ein Node.js-Skript ohne externe Abhängigkeiten. Acht Operationen decken den gesamten Lebenszyklus ab:

Operation	Was sie tut
sync	Kopiert Inhalte aus der Bibliothek ins Projekt basierend auf map.json
push	Kopiert lokale Änderungen zurück in die Bibliothek (respektiert Variantenzuordnung)
diff	Hash-Vergleich jedes verwalteten Elements, zeigt was sich geändert hat
list	Zeigt alle Bibliotheksinhalte und welche Projekte was nutzen
add	Fügt ein Element zur Projekt-Map hinzu und synct es
remove	Entfernt ein Element aus der Map und löscht es aus dem Projekt
init	Registriert ein neues Projekt in map.json
seed	Importiert den .claude/-Ordner eines bestehenden Projekts in die Bibliothek

Das Bootstrapping läuft über seed. Zeig es auf ein Repo, dessen .claude-Ordner schon in gutem Zustand ist, und der gesamte Ordner landet in der Bibliothek. Ein Eintrag wird in map.json angelegt. Ein Manifest wird geschrieben. Ab da liegt die kanonische Eigentümerschaft in der Bibliothek.

Content-Hashing treibt die diff-Operation an. Sie vergleicht Bibliotheks- und Projektversionen und kennzeichnet jedes Element als in-sync, local-changes oder library-ahead, sodass Drift sichtbar wird, bevor ein Sync oder Push startet.

Das Manifest: Verfolgen, was der Bibliothek gehört

Jedes synchronisierte Projekt bekommt eine .claude/.library-manifest.json:

{
  "library_path": "/path/to/your-library",
  "synced_at": "2026-03-24T10:30:00Z",
  "library_commit": "abc123",
  "managed": {
    "skills": {
      "git-commits": "git-commits--blog",
      "react": "react",
      "frontend-design": "frontend-design"
    },
    "agents": {
      "frontend-specialist": "frontend-specialist"
    },
    "claude-md": "CLAUDE--web-full",
    "settings": "settings--web"
  }
}

Im Manifest steht neben jedem Deploy-Namen der zugehörige Bibliotheksname. Push arbeitet gegen diese Zuordnung. Ein lokaler git-commits/-Ordner fließt zurück zu git-commits--blog/, anstatt die einfache Basis zu überschreiben.

Dateien, die das Manifest nicht aufführt, liegen außerhalb des Bibliotheksblickfelds. Persönliche Notizen, Backups, Einzel-Experimente in .claude/ überstehen einen Sync ohne Kratzer. Nur die Elemente, die die Bibliothek gesetzt hat, gehören der Bibliothek.

Natural Language Interface

Das System liefert mehr als nur ein CLI. Ein /library-Slash-Command wird in jedes synchronisierte Projekt eingespielt. Lass die Flags weg und frag auf Klartext:

/library sync
/library I modified the blog command, push it back
/library add the payment-processing skill to this project
/library what's out of sync?
/library create a variant of react for this project
/library show me everything available

Auf der anderen Seite des Commands öffnet Claude das Manifest, geht zur Bibliothek, extrahiert die Absicht aus dem Satz und startet die Sync-Engine. Alles Zerstörerische (Löschungen, Überschreibungen) bekommt vorher eine Bestätigungsabfrage.

Das ist das Interaktionsmodell, das das Ganze im Alltag nutzbar macht. Die Claude Code-Session muss nie für Bibliotheksarbeiten geschlossen werden. Sprich den Bedarf aus, und die Bibliothek reagiert.

Erste Schritte

Eine eigene Bibliothek aufzubauen dauert etwa 30 Minuten:

Erstelle ein privates Repo mit diesen Ordnern: skills/, agents/, commands/, hooks/, claude-mds/, settings/
Seed aus deinem besten Projekt. Wähle das Repo mit dem reichhaltigsten .claude-Ordner heute und zieh dessen Inhalt in die Bibliothek. Dieses Bundle wird zum Startkatalog.
Schreib deine map.json. Beginne mit einem einzigen Projekteintrag. Führe für diesen Eintrag jeden Skill, jeden Agent, jeden Command, jeden Hook und jede Konfigurationsdatei auf.
Baue das Sync-Skript. Der Kern bleibt einfach. Lade map.json. Parse die Elementnamen und trenne bei -- die Varianten. Kopiere die Dateien an ihre Ziele. Schreibe ein Manifest. Pull aus Git vor einem Sync. Commit und Push nach einem Push.
Füge den /library-Command innerhalb der Bibliothek selbst hinzu. Jedes synchronisierte Projekt übernimmt ihn automatisch, sodass Klartext-Steuerung von Anfang an verfügbar ist.
Füge ein zweites Projekt mit einer anderen Kombination hinzu. Zwei Repos, die eine Bibliothek teilen, zeigen die Auszahlung. Gleiche Quelle, unterschiedliche Konfigurationen, kein Drift auf beiden Seiten.

Eine Designentscheidung ist die wichtigste: Halte die echten Dateien im Repo, keine Zeiger. Indirektion fügt eine Ebene hinzu, die Varianten zu Mehrarbeit macht und Pushes zu einem Knoten. Wenn die Dateien direkt in der Bibliothek liegen, ist Syncing Kopieren, Pushing ist Kopieren in die andere Richtung, und Diffing ist ein Hash-Check.

Warum das im Großen wichtig ist

Sobald die Bibliothek läuft, ändern sich die Gewohnheiten. Als Referenz deckt das in diesem Post beschriebene Setup 31 Skills, 19 Agents, 16 Commands, 4 Hook-Systeme sowie projektspezifische CLAUDE.md- und settings.json-Dateien über 3 aktive Projekte ab. So sieht es in der Praxis aus:

Verbesserungen breiten sich aus. Ein Bug-Fix in deinem Code-Review-Agent geht einmal rein. Ab dem nächsten Sync übernimmt jedes Projekt, das diesen Agent listet, den Patch. Kein Suchen mehr nach dem Repo, in dem ein Fix liegen könnte.

Neue Projekte starten schnell. Initialisiere ein frisches Repo mit einem Profil, und das gesamte Agent-Team, das Hook-Bundle, die Settings und die CLAUDE.md landen in Sekunden. Vorbei ist das erste-Stunde-Ritual des manuellen Kopierens von Konfigurationsdateien.

Varianten verhindern Forks. Ein Projekt, das eine angepasste Version braucht, bekommt jetzt eine Variante statt still zu driften. Basis und Variante sind durch einen expliziten Link in der Bibliothek miteinander verbunden. Zwölf Monate später bleibt es eine Ein-Abfrage-Sache, herauszufinden, welche Projekte welche Versionen nutzen.

Die Bibliothek verteilt sich selbst. Der /library-Command lebt in der Bibliothek selbst. Verbessere ihn, und das Upgrade reitet beim nächsten Sync in jedes Projekt. Das Verteilungssystem wird von sich selbst verteilt.

Das .claude-Verteilungsproblem ist ein Zeichen eines tieferen Wandels. Mit dem Wachstum des agentischen Engineerings wird deine gesamte .claude-Konfiguration zu echter Infrastruktur: Skills, Agents, Commands, Hooks, Rules, CLAUDE.md und Settings. Sie verdienen dieselbe Sorgfalt, die du Anwendungscode gibst. Ein Weg dorthin: eine gemeinsame Bibliothek, variantenbewusst, mit Sync der in beide Richtungen fließt.

Für einen Vorsprung bei dem, was eine Bibliothek verteilen kann: das ClaudeFast Code Kit liefert 20+ Produktions-Skills, 18 spezialisierte Agents (frontend-specialist, backend-engineer, security-auditor, quality-engineer und mehr), ein Team-Orchestrierungssystem und 5 Produktionshooks, fertig zum Katalogisieren und Synchronisieren über deine Projekte.

Häufig gestellte Fragen

Was ist ein Claude Code Bibliothekssystem?

Ein privates Git-Repo, das jeden Teil deines .claude-Inhalts an einem Ort besitzt: Skills, Agents, Commands, Hooks, CLAUDE.md-Dateien und Settings. map.json entscheidet, welche Inhalte in welches Projekt landen. Eine Sync-Engine transportiert die richtigen Dateien in die richtigen Verzeichnisse.

Wie unterscheidet sich das von IndyDevDans the-library?

IndyDevDans Setup hält Referenzen in einem YAML-Katalog, mit Zeigern auf GitHub-Repos oder lokale Pfade. Der hier beschriebene Ansatz steckt die echten Dateien direkt in ein einziges Repo. Ein Varianten-Namensmuster unterstützt projektspezifische Versionen. Ein Manifest ermöglicht bidirektionalen Sync. Jede .claude-Inhaltskategorie ist abgedeckt: Skills, Agents, Commands, Hooks, Rules, CLAUDE.md, Settings und beliebige Dateien.

Muss die Bibliothek Open Source sein?

Nein. Ein privates Repo ist der richtige Ort. Die Bibliothek enthält spezialisierte Skills, projektspezifische CLAUDE.md-Dateien und Agent-Anweisungen, die möglicherweise sensibel sind. Halte Dinge standardmäßig privat. Ein einzelner Skill, den du später veröffentlichen möchtest, kann immer in ein eigenes Repo extrahiert werden.

Wie funktionieren Varianten?

Das Kernprinzip ist ein name--variante-Namensmuster. Ein Ordner namens react--strict/ in der Bibliothek landet als .claude/skills/react/ im Projekt. Jede Variante ist eine eigenständige Kopie mit eigenen Dateien und Struktur. Das Manifest hält die Beziehung fest, damit Push-Operationen Änderungen zurück zur passenden Variante führen.

Können mehrere Personen eine Bibliothek teilen?

Ja. Da es ein Git-Repo ist, klont ein Team es und zieht davon. Skill-Verbesserungen gehen per Push zurück. Jeder Mitarbeiter übernimmt diese Fixes beim nächsten Sync. map.json kann Einträge für die Projekte aller Teammitglieder enthalten.

Eine zentrale Bibliothek für deine .claude-Konfiguration

On this page