Schluss mit verstreuten KI-Ressourcen: Skills, Rules und MCP mit Bear.CTXPM verwalten

Wenn sich KI-Dateien stapeln

Wer lange genug mit Coding-Agenten arbeitet, dessen Repository füllt sich mit mehr als nur Prompts. Da sind Rules, die den Codestil vorgeben, Skills für Routineaufgaben, Specs mit den Grenzen des Produkts, MCP-Konfigurationen, die externe Dienste anbinden, und Memories zu früheren Entscheidungen. Manches stammt aus Open-Source-Communitys, manches gehört dem Team, und manches ist nur für ein einziges Projekt relevant.

Alles einfach ins Repo zu werfen, funktioniert anfangs. Die Probleme zeigen sich später, wenn das Projekt wächst, Sie den Agenten wechseln oder nach Monaten zurückkehren. Welche Dateien gehören in Git? Hat sich eine externe Ressource weiterentwickelt? Gilt eine bestimmte Regel für das ganze Team oder nur für dieses eine Repo? Ohne klare Grenzen wird das ganze Setup zum Durcheinander.

Genau dieses Durcheinander ist der Ausgangspunkt von Bear.CTXPM. Der Name steht für Context Package Manager. Es ist ein Open-Source-Protokoll für den Umgang mit KI-Ressourcen, kombiniert mit dem Kommandozeilen-Tool ctxpm. Es ordnet den Kontext und die Fähigkeiten, die eine KI nutzt, so, wie Sie bereits Ihren Projektcode ordnen.

Klassische Paketmanager erwarten, dass Sie Befehle zum Installieren, Aktualisieren und Validieren eintippen. CTXPM geht einen AI-first-Weg. Protokollregeln und Arbeitslogik werden über die Einstiegsdokumente der Agenten eingebracht, und zusammen mit integrierten Skills und CLI-Tools können Agenten Ressourcen prüfen, aktualisieren, validieren und aufräumen, während sie ganz normal programmieren, reviewen und debuggen. Subcommand-Flags müssen Sie nicht lernen. Der Agent liest das Protokoll, ruft die Tools auf und fragt Sie, wenn eine Entscheidung nötig ist.

Erst das Protokoll, dann das Tool

CTXPM verlangt nicht, dass Sie Ihre bestehenden Skills, Rules oder Prompts umschreiben, und bindet das Projekt nicht an einen Agenten. Zuerst klärt es Fragen, auf die jedes echte Projekt stößt:

• Welche KI-Ressourcen enthält das Projekt?
• Sind sie extern, oder pflegt das Projekt sie selbst?
• Wo liegen sie, und gehören sie unter Versionskontrolle?
• Über welchen Einstiegspunkt soll jeder Agent sie lesen?
• Wie werden sie installiert, validiert, migriert und aktualisiert?

Diese Vereinbarungen werden im Manifest ctxpm.yaml, in der Ordnerstruktur .ctxpm/ und in den Einstiegsdokumenten für Agenten im Projektstamm festgehalten. Die CLI macht Installieren, Erkennen und Validieren zuverlässiger, aber das Protokoll hängt nicht von ihr ab. Wo das Tool nicht laufen kann, versteht eine KI das Projekt trotzdem anhand von Manifest und Verzeichnissen.

Zwei Arten von Zuständigkeit

Es gibt nur zwei Begriffe für Zuständigkeit: dependency und package.

Eine dependency ist eine externe KI-Ressource, die das Projekt nutzt. Sie kann aus einem Git-Repository, einer OCI-Registry, einem Dateipfad oder anderswoher stammen. Ihr vollständiger Inhalt wird meist nicht committet, aber ctxpm.yaml hält Quelle, Pfad und eine stabile Version fest – ähnlich wie Drittanbieter-Abhängigkeiten im Anwendungscode.

Ein package ist etwas, das das Projekt selbst pflegt. Es hängt mit der Geschäftslogik, der Code-Struktur oder den Arbeitsweisen des Projekts zusammen, wird daher committet, gemeinsam mit dem Quellcode reviewt und angepasst, sobald sich das Projekt ändert.

Zuständigkeit ist vom Typ unabhängig. Beide Arten können ein Skill, eine Rule, eine Spec, ein Prompt, eine Memory oder mcp sein. Ein von GitHub importierter Commit-Skill ist dependency plus Skill. Ein Release-Workflow, der nur für ein Repository gilt, ist package plus Skill. Die projekteigenen Grenzen für das Bearbeiten von Quellcode könnten package plus Rule sein. So bleibt klar getrennt, wer eine Ressource pflegt und wen man fragt, wenn sie kaputtgeht.

Was im Verzeichnis liegt

Ein Projekt, das CTXPM einsetzt, hat typischerweise ctxpm.yaml als Ressourcenmanifest. Installierte externe Ressourcen landen in .ctxpm/dependencies/, das normalerweise in .gitignore steht. Ressourcen, die das Projekt pflegt, liegen in .ctxpm/packages/ und werden meist versioniert.

.ctxpm/AGENTS.md ist die gemeinsame Quelle für die Einstiegsdateien der Agenten. Je nachdem, welche Agentenprofile aktiviert sind, erhält der Projektstamm generierte Kopien namens AGENTS.md, CLAUDE.md, GEMINI.md oder was auch immer ein Agent erwartet, und alle verweisen auf denselben Text. Regeln werden einmal gepflegt, während sich die Einstiegsdateien an die Konventionen jedes Agenten anpassen.

Das Einstiegsdokument sagt der KI auch, wie sie Dinge findet. Beim Manifest beginnen, zu den eigenen packages des Projekts übergehen, dann zu externen dependencies, und memory nur dann heranziehen, wenn eine Aufgabe die Vorgeschichte braucht. Der Kontext füllt sich nicht von Anfang an mit jeder Datei. Genau das macht das Design KI-gesteuert: Das Protokoll ist eine Arbeitsanleitung und keine statische Konfiguration. Der Agent liest Ressourcen nach Priorität, entscheidet, welche Regeln für die aktuelle Aufgabe gelten, und führt zu passenden Zeitpunkten Prüfungen und Wartung durch, sodass Entwickler nicht aufhören müssen zu programmieren, um es von Hand zu erledigen.

Das Repository als eigenes Beispiel

Das Repo des Projekts selbst folgt diesen Regeln. ctxpm selbst und ein externer git-commit-Skill gelten als externe Abhängigkeiten. Der Release-Workflow, der nur diesem Repo dient, ist package plus Skill. Eine Erinnerung, Produkt-Quellcode nicht mit den eigenen verwalteten Ressourcen des Repositorys zu vermischen, ist package plus Rule. Ein vereinfachtes Manifest sieht so aus:

version: 1.0

project:
  name: Bear.CTXPM

agents:
  - generic
  - claude-code

dependencies:
  - name: ctxpm
    type: skill
    path: .ctxpm/dependencies/skills/ctxpm
    source:
      type: git
      url: https://github.com/gBearBest/Bear.CTXPM

packages:
  - name: ctxpm-release
    type: skill
    path: .ctxpm/packages/skills/ctxpm-release

  - name: ctxpm-source-boundary
    type: rule
    path: .ctxpm/packages/rules/ctxpm-source-boundary.md

Der Zweck des Manifests ist, Zuständigkeiten schriftlich festzuhalten. Eine KI, die später ins Repo kommt, erkennt, welche Inhalte dem Upstream folgen, für welche das Projekt einsteht und welche Regeln sie lesen sollte, bevor sie Quellcode anfasst.

Von der einmaligen Installation zur Pflege durch die KI

Gewöhnliche Paketmanager zwingen Sie, sich Befehle zu merken, Dokumentation nachzuschlagen und Prüfungen selbst anzustoßen. CTXPM macht aus diesen Schritten ein Protokoll, dem eine KI folgen kann. Sie können die Befehle manuell ausführen oder dem Agenten überlassen. Sobald ein Projekt das Protokoll übernommen hat, werden Agenten bei der Routinearbeit:

• KI-Ressourcen finden, die noch nicht verwaltet werden, und fragen, ob sie migriert werden sollen
• zu sinnvollen Zeitpunkten nach Updates externer Abhängigkeiten suchen
• prüfen, ob das Manifest zu den tatsächlichen Verzeichnissen passt, und Symlinks der Einstiegsdateien automatisch reparieren
• Sie fragen, wenn Ressourcen kollidieren oder die Zuständigkeit unklar ist

Die KI arbeitet keine festen Skripte ab. Sie versteht die semantischen Grenzen des Protokolls und beurteilt, was wann zu tun ist und ob sie vorher nachfragen sollte. detect und migrate kümmern sich um Altbestände: zuerst ein reiner Lese-Scan, danach Ihre Bestätigung, was verschoben wird. Auch check-updates und update sind bewusst getrennt: erst Änderungen finden und melden, nach Bestätigung aktualisieren.

Für gewöhnliche externe Git-Ressourcen zeichnet CTXPM den Commit auf, in dem sich der Pfad der Ressource zuletzt geändert hat – nicht unbedingt den neuesten HEAD des Repositorys. Wenn sich in einem großen Repository nur andere Verzeichnisse ändern, zeigt ein abhängiger Skill kein falsches Upgrade an, da die Version dem tatsächlich installierten Ressourcenstamm entspricht.

Arbeitsteilung

Das Protokoll steht an erster Stelle, weil sich ein Projekt nicht darauf verlassen kann, dass ein Binary vorhanden ist, damit eine KI ihre Umgebung versteht. Die Einstiegsdokumente sagen der KI, wo Ressourcen gespeichert sind, welche verwaltet und welche verstreut sind, wo die Grenzen externer Abhängigkeiten liegen und wann sie zu prüfen sind, welche Regeln vor einer Änderung zu lesen und welche Manifeste danach zu synchronisieren sind, und ob sie bei unklarer Zuständigkeit fragen oder ignorieren soll.

Feste Schritte passen zur CLI: Verzeichnisse anlegen, Symlinks reparieren, Abhängigkeiten installieren, Versionen berechnen, nicht verwaltete Ressourcen finden, Manifeste validieren. Ermessensfragen gehören der KI: entscheiden, wem eine Ressource gehört, Risiken erklären, abwägen, ob eine Bestätigung nötig ist, und Migrationskonflikte lösen. Das Protokoll setzt also die Regeln, die CLI hält wiederholbare Schritte stabil, und die KI übernimmt alles, was Interpretation braucht. Sie bleiben auf der Entscheidungsebene.

In der Praxis durchsucht die KI das Projekt nach nicht verwalteten Ressourcen, liest ctxpm.yaml für Zuständigkeiten und Abhängigkeiten, prüft Upstream-Updates, repariert Symlinks der Einstiegsdateien und lädt Ressourcen nach Priorität, um Kontext zu sparen. Sie entscheiden, ob verstreute Ressourcen zu Paketen werden oder als Abhängigkeiten markiert werden, ob bei einer neuen Version aktualisiert wird und welche Regel gewinnt, wenn zwei kollidieren. Das unterscheidet sich von npm install, wo Sie sich den Befehl merken und ihn auslösen. Hier beobachtet der Agent den Projektzustand im Hintergrund, während Sie programmieren, reviewen und debuggen, und meldet sich nur, wenn er eine Entscheidung braucht.

Wer davon profitiert

Eine einmalige KI-Demo braucht das wahrscheinlich nicht. Langlebige Projekte geraten dagegen häufig in diese Situationen:

• mehrere Agenten müssen denselben Satz an Projektregeln lesen
• Teams wollen gemeinsame Skills, ohne sie in jedes Repository zu kopieren
• die eigenen Prompts, Specs und Memories des Projekts müssen zusammen mit dem Quellcode reviewt werden
• externe Ressourcen brauchen bekannte Quellen, Versionen und Update-Grenzen
• alte, verstreute KI-Dateien müssen vor einer Migration inventarisiert werden

CTXPM schreibt Ihnen keine Prompts und hat keine Meinung dazu, welcher Agent klüger ist. Es klärt, wo Ressourcen hingehören, wem sie gehören und wie lange sie leben, damit sich KI-Workflows zusammen mit dem Projekt pflegen lassen.

Der Einstieg

Geben Sie Ihrem Agenten diese Anweisung:

Folge der Anleitung unter https://raw.githubusercontent.com/gBearBest/Bear.CTXPM/latest/INSTALL.md, um dieses Projekt zu analysieren, einzurichten und so umzubauen, dass KI-Ressourcen und Abhängigkeiten über Bear.CTXPM verwaltet werden.

Der Agent ermittelt, welche Agenten und vorhandenen Ressourcen das Projekt nutzt, bereitet eine projektlokale CLI vor und legt die Verzeichnisse und das Manifest an. Tauchen Fragen zu Zuständigkeit oder Migration auf, hält er an und fragt. Von da an löst die normale Arbeit Wartung im Hintergrund aus: verstreute Ressourcen finden und fragen, ob sie verwaltet werden sollen, Abhängigkeits-Updates melden und auf Freigabe warten, Symlinks reparieren und das Protokoll lesen, um zu entscheiden, was geladen wird.

Wenn Ihr Projekt bereits Rules, Skills, Prompts oder Memories hat, sparen früh gesetzte Grenzen später Aufräumarbeit. Genau auf diesen Schritt konzentriert sich CTXPM: vorhandenem Kontext ein Zuhause und einen bekannten Verantwortlichen zu geben. Das Repository liegt unter https://github.com/gBearBest/Bear.CTXPM