agent-config: Skills und Governance-Regeln über mehrere KI-Tools hinweg vereinheitlichen, mit selbst gehostetem, nur lesendem MCP-Endpunkt

agent-config verteilt einen Satz an Skills, Rules, Commands, Guidelines und Personas über npm und projiziert ihn in die native Konfiguration jedes unterstützten KI-Tools — gemäß dem offenen Agent Skills Standard. Derselbe Governance-Inhalt lässt sich zusätzlich über den eigenen Cloudflare Worker als MCP-Endpunkt anbieten. Es ist keine Agent-Runtime: Die Agent-Schleife, der LLM-Dispatch und die Tool-Orchestrierung bleiben beim Host-Tool. Es löst ein sehr konkretes Problem — ein einziger Bestand an Skills und Governance-Regeln, ohne ihn in jedem Tool neu konfigurieren zu müssen.

Für wen es geeignet ist

• Für Entwickler und Teams, die zwischen mehreren KI-Tools wechseln und wollen, dass Skills und Governance-Regeln konsistent bleiben: Die Content-Layer lässt sich in die native Konfiguration von Host-Tools wie Claude Code, Augment, Cursor, Cline, Windsurf, Gemini CLI und Copilot projizieren — einmal pflegen, in allen Tools nutzen.
• Für Einzelpersonen und Teams, die einen selbst gehosteten MCP-Endpunkt brauchen: Der Governance-Inhalt wird von Ihrem eigenen Cloudflare Worker ausgeliefert, und beliebige MCP-Clients — Claude Desktop, Claude Code, Cursor, Zed, Continue, gehostete Agents und mehr — greifen über HTTP zu, ohne dass Sie in jedem Client eine eigene Kopie pflegen müssten.
• Nicht geeignet als Agent-Runtime: Sie führt keine Agent-Schleife aus und übernimmt weder LLM-Dispatch noch Tool-Orchestrierung; wer einen Dienst sucht, der Aufgaben ausführt und Modelle verteilt, findet diese Fähigkeiten im Host-Tool.
• Nicht geeignet für alle, die einen fertigen lokalen Dienst erwarten: Der eingebaute local stdio server erfordert einen lokalen Checkout und ist nicht installieren-und-los.
• Voraussetzung: Node ≥ 18; weitere Systemanforderungen werden in den Belegen nicht genannt und bleiben unbestätigt.

Erster Versuch in 3 Minuten

Es gibt genau einen Hauptweg: den offiziellen kanonischen Installationsbefehl plus eine einmalige Kontrolle der globalen Verzeichnisse.

1. Voraussetzung: Node ≥ 18 ist auf dem Rechner installiert.
2. Führen Sie den offiziellen kanonischen Befehl im Terminal aus: npx @event4u/agent-config init.
3. Machen Sie sich vor der Ausführung die Nebenwirkungen klar: init schreibt ausschließlich in globale Verzeichnisse — ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ und weitere; Projektdateien werden nicht geschrieben, und der project scope ist Maintainern vorbehalten. Das ist ein lokaler Schreibvorgang, keine Übermittlung an einen entfernten Ort; wie man etwas rückgängig macht oder zurückrollt, beschreiben die Belege nicht — im Zweifel diese Verzeichnisse vorher sichern und dann ausführen.
4. Erfolgszeichen: Nach dem Befehl enthalten die genannten globalen Verzeichnisse geschriebene Inhalte, und in der nativen Konfiguration der unterstützten Tools erscheinen die projizierten Skills, Rules, Commands, Guidelines und Personas. Wer den Umfang vorher prüfen will, schaut direkt in die Dateien dieser globalen Verzeichnisse.

Der Server-Weg bleibt eine Nebenbemerkung: Nach dem Deployment Ihres eigenen Cloudflare Workers ist der Governance-Inhalt für Clients als MCP-Endpunkt erreichbar. Die Belege bestätigen diese Fähigkeit, nennen aber weder Deploy-Befehle noch Konfigurationsausschnitte — die konkreten Schritte bleiben unbestätigt. Das ist eine Aktion auf der Remote-Seite und gehört nicht zu den Pflichtschritten des Schnellstarts. Beim ersten Kontakt empfiehlt es sich, zuerst die kleinen Nur-Lese-Tools aufzurufen (etwa memory_lookup und list_*): „Nur lesend“ bedeutet lediglich, dass keine Schreiboperationen ausgeführt werden — nicht, dass es keine anderen Risiken gibt, und schon gar nicht, dass nichts aufs Netz geht oder lokale Daten gelesen werden.

Anwendungsfälle

Fall 1: Dieselben Skills und Regeln in Claude Code und Cursor nutzen. Pflegt man die Konfiguration zweier Tools getrennt, driftet sie auseinander. Auf einem Rechner mit Node ≥ 18 führen Sie npx @event4u/agent-config init aus und lassen die Content-Layer in die globalen Verzeichnisse schreiben. Erwartbares Ergebnis im Rahmen der Belege: In ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ und weiteren Verzeichnissen wird geschrieben, der Inhalt folgt dem offenen Agent Skills Standard, und Dateien innerhalb Ihrer Projekte bleiben unberührt; danach lesen beide Tools aus ihrer nativen Konfiguration denselben Bestand an Skills und Rules. Laut offizieller Angabe zielt die Projektion auf jedes unterstützte Tool, nicht nur auf die beiden hier als Beispiel genannten. Wann dieser Weg passt: Wenn sich Skills und Regeln in beiden Tools auseinanderentwickelt haben und nicht mehr übereinstimmen, und ein einziger Inhaltsbestand maßgeblich sein soll. Grenze: Gelöst wird nur die Inhaltsverteilung — ausgeführt wird keine Skill in Ihren Tools.

Fall 2: Einen nur lesenden MCP-Governance-Endpunkt selbst hosten. Das Team möchte, dass mehrere Clients über HTTP denselben Governance-Inhalt lesen, ohne dass auf jedem Rechner etwas installiert werden muss. Bieten Sie ihn auf Ihrem Cloudflare Worker als MCP-Endpunkt an: Der Governance-Inhalt wird als MCP prompts und resources ausgegeben — Skills, Commands, Rules, Guidelines, Contexts —, dazu kommen die Nur-Lese-Tools memory_lookup, chat_history_read und list_*. MCP-Clients wie Claude Desktop, Claude Code, Cursor, Zed, Continue und gehostete Agents greifen über HTTP zu. Beobachtbares Ergebnis: Nach dem Verbinden erscheint der Governance-Inhalt in den prompts- und resources-Listen des Clients, und die genannten Nur-Lese-Tools lassen sich aufrufen. Ebenfalls einplanen: Der Worker führt die rund 112 Python-Skripte (linters, audits, task ci, work-engine hooks) nicht aus; dafür ist eine lokale Installation gemäß Quickstart nötig. Deploy-Schritte für den Worker fehlen in den Belegen — bestätigen lässt sich nur die offizielle Aussage, dass die Fähigkeit existiert.

Nutzungsgrenzen

• Lese-/Schreib-Charakter: Die Worker-Seite ist nur lesend — der Governance-Inhalt wird als prompts und resources bereitgestellt, die Werkzeuge beschränken sich auf kleine Nur-Lese-Tools wie memory_lookup, chat_history_read und list_*; von offizieller Seite wird kein Schreib-Tool genannt. init schreibt lokal und ausschließlich in globale Verzeichnisse und fasst Projekt-Repositories nicht an. Nur-Lese-Tools beweisen nur, dass keine Schreiboperationen ausgeführt werden; ob Netzwerkzugriffe stattfinden oder lokale Daten gelesen werden, sagen die Belege nicht.
• Nebenwirkungen und Kontrollpunkte: init schreibt in ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ und weitere; der project scope ist Maintainern vorbehalten, eine normale Installation ändert also keines Ihrer Projekt-Repositories. Ob es ein automatisches Zurücknehmen oder ein Rollback gibt und welche Dateien genau geschrieben werden, beschreiben die Belege nicht.
• Offiziell genannte Grenzen: Der Worker führt die rund 112 Python-Skripte (linters, audits, task ci, work-engine hooks) nicht aus — dafür ist eine lokale Installation gemäß Quickstart nötig; der eingebaute local stdio server dient nur der Auffindbarkeit in der Glama MCP Registry und erfordert einen lokalen Checkout (siehe ADR-067).
• Wegkontrolle: Für die Verteilung des Inhalts in die Tools init verwenden; für das Lesen des Governance-Inhalts über MCP den Worker; um die Python-Skripte auszuführen, gemäß Quickstart lokal installieren und dort ausführen.
• Noch unbestätigt: Deploy-Befehle und Konfigurationsausschnitte für den Worker, die konkrete Anbindung der einzelnen Clients sowie die vollständigen Systemanforderungen jenseits von Node ≥ 18. Hierzu fehlen Belege — vor dem Start gilt das offizielle Repository als Maßstab.