Rulesync: KI-Tool-Konfigurationen aus einer einzigen Regelquelle

Rulesync: eine Regelquelle für Dutzende KI-Tools

Rulesync ist ein in TypeScript geschriebenes Node.js-Kommandozeilenprogramm, das aus einheitlichen KI-Regeldateien die Konfigurationsdateien verschiedener KI-Entwicklungstools generiert. Statt für jedes Werkzeug eine eigene Regelbarkeit zu warten, bildet Rulesync ein zentrales Regelset auf das jeweils erwartete Layout ab und erzeugt daraus Regeln, Befehle, MCP-Einstellungen, Ignore-Dateien, Subagenten und Skills.

Das Projekt steht unter der MIT-Lizenz, weist über 1300 Sterne auf und wird aktiv entwickelt, die Metadaten zeigen zuletzt Updates im August 2026 und Releases in der Reihe v16.17.0. Die offizielle Dokumentation liegt unter dyoshikawa.github.io/rulesync, das Paket selbst auf npm. Die generierte Ausgabe lässt sich selektiv steuern: Wer nur für zwei Tools schreiben will, wählt die Ziele aus, wer alles will, generiert mit einem Wildcard-Aufruf.

Installation über npm, Homebrew-Tap und Einzelbinärdatei

Das README dokumentiert drei Wege. Der erste ist die globale npm-Installation mit npm install -g rulesync. Der zweite ist ein Homebrew-Tap für macOS und Linux, der in zwei Schritten eingerichtet wird: brew tap dyoshikawa/rulesync https://github.com/dyoshikawa/rulesync, danach brew install rulesync.

Der README widmet diesem Tap eine eigene Warnung: Es liegt innerhalb des Projektrepositorys und trägt deshalb kein homebrew- Präfix, sodass die zweistellige brew tap Form mit Name und URL nötig ist. Die Kurzform brew install dyoshikawa/rulesync/rulesync ohne vorheriges Tappen funktioniert nicht. Der dritte Weg ist eine Einzelbinärdatei per curl -fsSL https://github.com/dyoshikawa/rulesync/releases/latest/download/install.sh | bash, für manuelle und plattformspezifische Installation verweist die Seite auf die Installationsdokumentation.

Erste Schritte mit init, fetch und generate

Der Schnellstart besteht aus drei Befehlen. rulesync init legt die nötigen Verzeichnisse, Beispiel-Regeldateien und eine Konfigurationsdatei an. rulesync fetch dyoshikawa/rulesync lädt die offiziellen Skills, was das README ausdrücklich empfiehlt. rulesync generate --targets "*" --features "*" erzeugt danach die Konfigurationen für alle unterstützten Tools und alle Features.

Damit steht in wenigen Minuten ein vollständiger Satz Ausgabedateien im Projekt, der anschließend gezielt eingedampft werden kann. Der Dreiklang aus init, fetch und generate trennt bewusst die drei Anliegen: Projektstruktur, offizielle Erweiterungen und eigentliche Generierung. Wer die Befehle in dieser Reihenfolge ausführt, sieht zuerst die Musterdateien und erst dann die tatsächlichen Zielformate.

Import bestehender Konfigurationen und Direktkonvertierung

Wer bereits Regeldateien pflegt, muss nicht bei null anfangen. Der Importbefehl liest bestehende Dateien nach .rulesync/**/* ein, etwa rulesync import --targets claudecode aus CLAUDE.md, --targets cursor aus .cursorrules und --targets copilot aus .github/copilot-instructions.md. Damit wird der vorhandene Zustand zur zentralen Quelle, von der aus künftig generiert wird.

Für den Fall, dass nur ein einmaliger Umzug gewünscht ist, gibt es einen zweiten Pfad ohne die .rulesync-Quelle: rulesync convert --from cursor --to copilot,claudecode wandelt Cursor-Regeln direkt in die Formate der anderen beiden Tools um, ohne intermediate Dateien zu schreiben. Die Trennung zwischen dem dauerhaften Quellenworkflow mit .rulesync/ und dem Einmalkonvertieren ist im README klar gezogen und deckt beide Einsatzmuster ab.

Die Feature-Matrix: Regeln, Befehle, MCP, Subagenten

Der Kern der Dokumentation ist eine Tabelle über AI-Coding-Tools und deren Feature-Unterstützung: rules, ignore, mcp, commands, subagents, skills, hooks, permissions und checks. Claude Code unterstützt demnach alle neun Spalten, während etwa JetBrains AI Assistant nur rules, ignore, mcp und skills abdeckt. Neben den proprietären Tools führt die Tabelle auch die offenen Standards AGENTS.md und AgentsSkills.

Ein Häkchen bedeutet laut README, dass das Feature mindestens in einem Modus unterstützt wird, also im Projekt-, Global- oder simulierten Modus. Als Beispiel nennt die Dokumentation Codex CLI, dessen commands ausschließlich global funktionieren. Die vollständige Aufschlüsselung je Modus und die --targets-Werte jedes Tools stehen in der Supported-Tools-Referenz der Dokumentationsseite, nicht in der README selbst.

Deprecations: ignore weicht permissions, Ziele werden geteilt

Das README dokumentiert mehrere Übergänge. Die Ignore-Funktion ist zugunsten der ausdrucksstärkeren Permissions-Funktion veraltet, bestehende Ignore-Konfigurationen bleiben während Rulesync 14.x unterstützt, eine Entfernung ist frühestens für ein künftiges Major-Release vorgesehen. Neue mit init angelegte Projekte erzeugen Permissions ohne Ignore-Dateien.

Zudem werden Zielangaben aufgeteilt: Google Antigravity zerfällt in antigravity-ide und antigravity-cli, weil Antigravity 2.0 getrennte globale Konfigurationsbäume führt, beide geben die Root-Regel als einfache AGENTS.md im Projektstamm aus. Das Kiro-Ziel teilt sich in kiro-cli und kiro-ide, da IDE und CLI unterschiedliche Formate nutzen, der alte kiro-Alias bleibt mit unverändertem Verhalten bestehen. Schließlich schreiben die Plugin-Ziele claudecode-plugin und antigravity-plugin Komponenten in ein bestehendes Plugin-Verzeichnis und sind deshalb von --targets "*" ausgeschlossen.

Fazit: für wen Rulesync die Abstraktion zahlt

Rulesync richtet sich an Entwickler, die mehrere KI-Agenten parallel nutzen und dieselben Regeln sonst doppelt oder dreifach pflegen. Genau dort liegt der Nutzen: Ein Import bestehender Dateien, danach ein einziger Generierungslauf, und jede Konfiguration ist wieder synchron. Die breite Matrix, die offenen Standards und die laufende Release-Tätigkeit zeigen, dass das Projekt seine Ansprüche ernst nimmt.

Weniger gewinnbringend ist das Werkzeug bei genau einem eingesetzten Agenten, weil dann die Abstraktionsebene ohne Gegenwert bleibt. Vor der Einführung empfiehlt sich ein Testprojekt: rulesync init ausführen, die generierten Dateien gegen die tatsächlichen Erwartungen des eigenen Tools prüfen und dabei auf die Modusangaben in der Supported-Tools-Referenz achten, damit Projekt- und Globalkonfiguration nicht vermischt werden.

Redaktionelles Fazit

Rulesync lohnt sich für Teams und Einzelpersonen, die dieselben Regeln, Befehle und MCP-Einstellungen in mehr als einem KI-Coding-Tool pflegen und Duplikate über CLAUDE.md, .cursorrules und Co. loswerden wollen. Wer nur ein einziges Tool einsetzt, braucht die Abstraktionsschicht kaum. Vor dem Rollout zahlt es sich aus, mit rulesync init ein Beispielprojekt anzulegen, mit rulesync generate --targets "*" --features "*" die Ausgaben zu erzeugen und zu prüfen, welche der in der Matrix gelisteten Modi Projekt- oder Globalkonfiguration nutzen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes