Wie ich ein toolübergreifendes Speicher- und Kompetenzsystem für KI-gestützte Entwicklung aufgebaut habe

Ein praktischer Leitfaden zum Austausch von Kontext, Kompetenzen und Einstellungen zwischen Claude Code, Cursor, Codex und darüber hinaus

10 Min. Lesezeit | Mittelstufe

---

Ich nutze täglich vier KI-Codierungstools: Claude Code, Cursor, Codex CLI und gelegentlich Gemini/Antigravity. Jedes davon ist in unterschiedlichen Bereichen gut. Claude Code bewältigt komplexe Refactorings mit mehreren Dateien. Cursor ist schnell bei Inline-Bearbeitungen. Codex führt Hintergrundaufgaben aus. Gemini bringt eine andere Perspektive ein.

Aber hier liegt das Problem: Jedes Tool beginnt jede Interaktion bei Null. Es kennt weder meine Präferenzen noch meine Projektarchitektur oder die Erkenntnisse, die ich letzte Woche in einem anderen Tool gewonnen habe. Am Ende wiederhole ich mich ständig – „wir haben im letzten Sprint den E-Mail-Anbieter gewechselt“, „erstelle immer einen Branch, bevor du bearbeitest“, „verwende pnpm statt npm“.

Also habe ich ein System entwickelt, das allen vier Tools ein gemeinsames Gehirn gibt. Sie teilen sich den Speicher (was ich gelernt habe), Fähigkeiten (wie man Dinge macht) und Regeln (was man immer/niemals tun sollte) – ohne dass ein Tool direkt von den anderen weiß.

Dieser Beitrag führt durch die genaue Einrichtung. Alles hier läuft derzeit in der Produktion in meinen Projekten.

Die Architektur

                     Knowledge Graph (MCP)
                     localhost:8765
                    ┌─────────────────┐
                    │  Entitäten        │
                    │  Beobachtungen    │
                    │  Beziehungen       │◄──── Alle 4 Tools lesen/schreiben
                    └────────┬────────┘
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
    Claude-Code          Cursor            Codex CLI
    ┌──────────┐     ┌──────────┐      ┌──────────┐
    │ CLAUDE.md│     │.cursorrules│    │ AGENTS.md │
    │ skills/  │     │ .cursor/  │    │ .codex/   │
    │ commands/│     │  rules/   │    │           │
    │ agents/  │     │           │    │           │
    │ memory/  │     │           │    │           │
    └──────────┘     └──────────┘    └──────────┘
          │                  │                  │
          └──────────────────┼──────────────────┘
                             │
                    Fähigkeiten MCP-Server
                    (universelle Vorlage)
                    ┌─────────────────┐
                    │  51 Skills      │
                    │  13 Befehle    │
                    │  17 Agenten      │
                    └─────────────────┘

Drei Ebenen:

1. Wissensgraph — gemeinsamer Speicher für alle Tools (Benutzereinstellungen, Projektkontext, projektübergreifende Erkenntnisse)
2. Universelle Vorlage — wiederverwendbare Fähigkeiten, Befehle und Agenten, die für jedes Projekt verfügbar sind
3. Tool-spezifische Konfiguration — toolspezifische Anweisungen (CLAUDE.md, .cursorrules, AGENTS.md)

Ebene 1: Der Wissensgraph (gemeinsamer Speicher)

Die Grundlage bildet ein Wissensgraph, der als MCP-Server (Model Context Protocol) auf localhost:8765 läuft. Jedes KI-Tool verbindet sich damit. Er speichert drei Arten von Daten:

Entitäten — Dinge, die existieren: Projekte, Personen, Tools, Konzepte.

Beobachtungen — Fakten, die mit Entitäten verknüpft sind: „bevorzugt pnpm gegenüber npm“, „Projekt A verwendet Supabase + Resend“, „Projekt B erforderte die Einhaltung von ISO 13482“.

Beziehungen — Verbindungen zwischen Entitäten: „Projekt A verwendet Supabase“, „Benutzer arbeitet an Projekt C“.

Warum nicht einfach Dateien?

Dateibasierte Speicher (wie Claude Codes ~/.claude/projects//<project>memory</project>/<project>) sind projekt- und toolbezogen. Sie eignen sich gut für „Merke dir das für das nächste Mal in diesem Projekt mit diesem Tool“. Aber sie können keinen Kontext über Projekte oder Tools hinweg teilen.

Der Wissensgraphen löst beide Probleme:

• Projektübergreifend: Arbeitest du an der Authentifizierung in Projekt B? Suche im Graphen nach „Authentifizierung“ und finde Muster, die du in Projekt A festgelegt hast.
• Toolübergreifend: Behebe einen Fehler in Cursor, und der Graphen merkt sich die Ursache. Wenn Claude Code das nächste Mal auf etwas Ähnliches stößt, findet es die Erkenntnis.

Die Lesestrategie: Bereichsbezogen, kein vollständiger Dump

Die wichtigste Lektion, die ich gelernt habe: Lade niemals den gesamten Graphen. Wenn er wächst, verschwendet das Einlesen aller Daten in den Kontext Tokens für irrelevante Informationen.

Stattdessen nutze ich bereichsbezogene Suchen an zwei Stellen:

Zu Beginn der Sitzung – zwei gezielte Suchen:

search_nodes("user preferences workflow")  → persönliches Profil laden
search_nodes(&quot;<current project="" name="">&quot;)     → aktuellen Projektkontext laden

Während der Konversation – bei Bedarf, wenn ich projektübergreifenden Kontext benötige:

search_nodes("auth authentication")  → Muster aus anderen Projekten finden
search_nodes("ROS2 robotics")        → relevantes Wissen zur Robotik abrufen

Die Schreibstrategie: Kontinuierliches Mining

Ich habe alle Tools so konfiguriert, dass sie Gespräche kontinuierlich nach dauerhaftem Wissen durchsuchen und die Ergebnisse sofort in den Graphen schreiben – statt sie für später zu bündeln.

Zwei Kategorien von Auslösern:

Artefakt-Auslöser – wenn etwas erstellt wird:

• Neue Fähigkeit erstellt → create_entities mit Name, Zweck, Schlüsselregeln
• Architekturentscheidung getroffen → add_observations zur Projektentität
• Neues Tool/neue Bibliothek eingeführt → create_entities + create_relations

Konversations-Trigger – wenn etwas gesagt wird:

• Benutzer korrigiert Vorgehensweise → add_observations zur Benutzer-Entität mit Präferenz
• Debugging-Erkenntnis offenbart Muster → add_observations
• Projektübergreifendes Lernen → add_observations zu beiden Projekt-Entitäten

Was NICHT gespeichert werden soll: kurzlebige Aufgabendetails, laufendes Debugging, Dinge, die aus dem Code oder der Git-Historie abgeleitet werden können.

Ebene 2: Die universelle Vorlage (gemeinsame Fähigkeiten)

Ich pflege eine universelle Vorlage unter ~/universal-claude-template/ mit 51 Fähigkeiten, 13 Befehlen und 17 Agenten. Jedes Projekt kann über den Skills-MCP-Server darauf zugreifen.

Was ist ein Skill im Vergleich zu einem Befehl oder einem Agenten?

Skills sind tiefgreifendes prozedurales Wissen – mehrstufige Arbeitsabläufe mit detaillierten Anweisungen. Beispiele:

• write-blog – vollständige Pipeline zur Blog-Erstellung (Recherche → Gliederung → Schreiben → Übersetzen → Veröffentlichen)
• create-prd – Erstellung eines Produktanforderungsdokuments
• debugging – systematische Debugging-Methodik
• financial-analysis – Finanzmodellierung und -analyse
• competitive-research – Zusammenfassung von Marktforschungsergebnissen

Befehle sind vom Benutzer aufrufbare Shortcuts (/command):

• /commit – herkömmlicher Commit-Workflow
• /explore – detaillierte Erkundung der Codebasis (schreibgeschützt)
• /fix-issue – End-to-End-Lösung von GitHub-Issues
• /deploy-check — Validierung vor der Bereitstellung

Agenten sind spezialisierte Unteragenten für parallele Arbeit:

• researcher — Erkundung der Codebasis/Domäne (schreibt niemals Code)
• code-reviewer — erkennt Fehler und Sicherheitsprobleme
• architect — Designentscheidungen und Kompromissanalysen
• test-runner — führt Tests durch und behebt Fehler

Wie Skills in verschiedenen Tools geladen werden

Der Skills-MCP-Server stellt alle Skills jedem verbundenen Tool zur Verfügung. Wenn Claude Code einen Workflow benötigt:

search_skills("blog")       → findet den Skill „write-blog“
read_skill("write-blog")    → lädt die vollständige SKILL.md-Datei

Anschließend folgt es den Anweisungen des Skills, als wäre es eine lokale Datei.

Skill-Synchronisierung: Die Vorlage auf dem neuesten Stand halten

Wenn in einem beliebigen Projekt ein neuer verallgemeinerbarer Skill erstellt wird:

diff_skills("/path/to/project")                          → sieht, was neu ist
sync_skill("skill-name", "to_template", "/path/to/project") → kopiert in die Vorlage

Dadurch wächst die universelle Vorlage aus der tatsächlichen Projektarbeit heraus und nicht aus hypothetischer Planung.

Ebene 3: Konfiguration pro Tool

Jedes Tool erhält sein eigenes Konfigurationsformat, aber alle beziehen sich auf denselben Wissensgraphen und dieselben Skills.

Claude-Code: CLAUDE.md + Regeln + Speicher

~/.claude/
├── CLAUDE.md              ← Globale Anweisungen (Wissensgraph + Skills-MCP-Einrichtung)
├── settings.json          ← MCP-Serverkonfigurationen, Berechtigungen
└── projects/
    └── <project>/
        ├── CLAUDE.md      ← Projektspezifische Anweisungen
        └── memory/        ← Dateibasiertes Gedächtnis (projektbezogen)
            ├── MEMORY.md  ← Index der Speicherdateien
            ├── user_profile.md
            └── feedback_*.md

Die globale Datei CLAUDE.md teilt Claude Code mit, wie der Wissensgraph und das Skills-MCP zu verwenden sind. CLAUDE.md-Dateien auf Projektebene fügen projektspezifischen Kontext hinzu (Stack, Befehle, Fallstricke).

Claude Code verfügt außerdem über .claude/rules/ – stets geladene Constraint-Dateien:

• quality.md – Definition von „Done“, Namenskonventionen
• architecture.md – Trennung von Anliegen, Fehlerbehandlung
• git-workflow.md – Verzweigungsstrategie, Commit-Format
• security.md – Umgang mit Geheimnissen, Eingabevalidierung
• testing.md – TDD-Workflow, Mocking-Regeln

Cursor: .cursorrules + .cursor/rules/

Cursor verwendet .cursorrules (Projektstammverzeichnis) und .cursor/rules/ (MDC-Format). Ich übernehme dieselben Regeln aus der universellen Vorlage, angepasst an die Syntax von Cursor.

Codex CLI: AGENTS.md

Die Codex CLI von OpenAI liest AGENTS.md für die Anweisungen an den Hauptagenten. Gleicher Inhalt, anderes Format.

Das Dual-Memory-Muster</project>

Claude Code hat einen einzigartigen Vorteil: Es unterstützt sowohl den dateibasierten Speicher als auch den Wissensgraphen. Ich nutze beide bewusst:

Dateibasierter Speicher (~/.claude/projects//<project>memory</project><project>/) für:

• Claude-Code-spezifischen Kontext, den andere Tools nicht benötigen
• Projektbezogene Rückmeldungen und Einstellungen
• Schnellen Zugriff innerhalb desselben Tools

Wissensgraph (localhost:8765) für:

• Projektübergreifende Muster und Erkenntnisse
• Benutzereinstellungen, die alle Tools kennen sollten
• Architekturentscheidungen und deren Begründung
• Tool-/Bibliotheksbewertungen

Die Regel: Wenn nur Claude Code es benötigt, verwende den Dateispeicher. Wenn andere Tools davon wissen sollten, verwende den Graph.

Domain-Packs: Spezialisierung pro Projekt

Die universelle Vorlage enthält Domain-Packs, die domänenspezifische Fähigkeiten hinzufügen:

 Copy
bash ~/universal-claude-template/setup.sh web       # Webentwicklungsfähigkeiten
bash ~/universal-claude-template/setup.sh robotics  # ROS2, Hardware, Sim2Real
bash ~/universal-claude-template/setup.sh creative  # Design, Marke, Inhalte
bash ~/universal-claude-template/setup.sh finance   # Finanzmodellierung
bash ~/universal-claude-template/setup.sh research  # Wissenschaftliche Methodik

Jedes Paket fügt relevante Regeln, Fähigkeiten und Kontext hinzu, ohne Projekte zu überfrachten, die diese nicht benötigen.

Wie das in der Praxis aussieht

Hier ist ein echter Arbeitsablauf:

1. Starte eine Sitzung in Claude Code für ein Portfolio-Projekt. Es lädt automatisch den Projektspeicher und durchsucht den Graphen nach aktuellem Kontext.

2. Ich sage „Ersetze den E-Mail-Anbieter durch Resend“. Claude Code liest den bestehenden Code, entwirft die Migration und implementiert sie über Backend + Frontend + Docker + CI hinweg. Es nutzt die deployment-Fähigkeit für Docker-Muster und database-patterns für das Supabase-Schema.

3. Während der Implementierung entdeckt es ein Kompatibilitätsproblem mit Node 18 bei crypto.randomUUID(). Es schreibt dies als projektübergreifende Erkenntnis in den Wissensgraphen: „crypto.randomUUID() ist in Node 18 keine globale Variable – verwende require('crypto').randomUUID()“.

4. Später arbeite ich in Cursor an einem anderen Projekt, das ebenfalls Node 18 verwendet. Cursor durchsucht den Graphen, findet die Beobachtung zu crypto.randomUUID und vermeidet denselben Fehler.

5. Ich wechsle zur Codex-CLI für eine Hintergrundaufgabe. Sie liest aus demselben Graphen, kennt meine Präferenzen und folgt denselben Commit-Konventionen.

Es ging kein Kontext verloren. Keine Einstellungen mussten wiederholt werden. Jedes Tool trug zum gemeinsamen Wissenspool bei und profitierte davon.

So richten Sie das selbst ein

Voraussetzungen

• Claude Code installiert
• Ein MCP-kompatibler Speicherserver (ich verwende @anthropic/memory-mcp)
• Optional: Cursor, Codex CLI

Schritt 1: Richten Sie den Wissensgraphen ein

 Copy
# Den Memory-MCP-Server installieren
npm install -g @anthropic/memory-mcp

# Zu Claude Code hinzufügen
claude mcp add memory -- npx @anthropic/memory-mcp --port 8765

Schritt 2: Klonen Sie die Universal-Vorlage

 Copy
git clone https://github.com/your-username/universal-claude-template ~/universal-claude-template

Oder erstellen Sie Ihre eigene. Beginnen Sie mit 5–10 Skills, die Ihrem tatsächlichen Arbeitsablauf entsprechen, und erweitern Sie diese dann schrittweise.

Schritt 3: Konfigurieren Sie die globale CLAUDE.md

Erstellen Sie ~/.claude/CLAUDE.md mit Anweisungen für den Wissensgraphen (wie man liest, wann man schreibt) und die Skills-MCP (wie man sucht und lädt).

Schritt 4: Projektbezogene Konfiguration einrichten

 Copy
cd your-project
bash ~/universal-claude-template/setup.sh web  # oder robotics, creative usw.

Dadurch werden Regeln kopiert, die CLAUDE.md-Vorlage erstellt und Skills verknüpft.

Schritt 5: Andere Tools verbinden

Füge den Memory-MCP-Server zu Cursor und Codex CLI hinzu, indem du deren jeweilige Konfigurationsformate verwendest. Sie nutzen denselben Wissensgraphen.

Gewonnene Erkenntnisse

Fang klein an. Erstelle nicht gleich am ersten Tag 50 Skills. Erstelle sie nach Bedarf, basierend auf deiner tatsächlichen Arbeit. Meine Vorlage wuchs innerhalb von drei Monaten von 5 auf 51 Skills an.

Grenze deine Lesevorgänge ein. Das Laden des gesamten Graphen in den Kontext ist schlimmer, als gar keinen Graphen zu haben. Suche immer nach bestimmten Themen.

Lassen Sie die Tools voneinander lernen. Die wertvollsten Graphen-Einträge stammen aus Debugging-Sitzungen – Erkenntnisse, die verhindern, dass derselbe Fehler in einem anderen Kontext wiederholt wird.

Kämpfen Sie nicht gegen das Tool. Jedes KI-Tool hat andere Stärken. Claude Code eignet sich am besten für komplexe Refactorings. Cursor für schnelle Bearbeitungen. Codex für Hintergrundaufgaben. Das gemeinsame Gehirn ermöglicht es Ihnen, das richtige Tool zu nutzen, ohne den Kontext zu verlieren.

Skills sind besser als Prompts. Eine gut geschriebene SKILL.md-Datei mit klaren Schritten, Einschränkungen und Beispielen übertrifft selbst den besten Prompt. Prompts sind vergänglich. Skills sind beständig.

---</project>

Ich verwende genau diese Konfiguration bei all meinen Projekten. Wenn Sie Hilfe bei der Einrichtung eines toolübergreifenden KI-Workflows für Ihr Team benötigen, lassen Sie uns darüber sprechen.