Cursor Rules einrichten: passende Regeln für das Team

Der Nutzen zeigt sich in weniger Nacharbeit beim Review. Eine Beispielrechnung: Vier Entwickler, die jede Woche jeweils drei Korrekturen à fünf Minuten vornehmen, verbringen 60 Minuten damit, dieselben Konventionen zu wiederholen. Das ist kein versprochenes Einsparpotenzial. Entscheidend ist, welche Korrekturen nach der Einrichtung entfallen; davon ist der Pflegeaufwand für die Regeln abzuziehen. Die Abokosten sind eine eigene Frage. Darum geht es im Artikel zu den Cursor-Preisen.

Wo werden Cursor Rules hinterlegt?

Gemeinsame Entscheidungen zum Code gehören ins Repository. Persönliche Vorlieben für Antworten bleiben persönliche Einstellungen.

Anweisungen in einer untergeordneten AGENTS.md gelten für ihr Verzeichnis und dessen Unterverzeichnisse. Sie ergänzen die übergeordneten Vorgaben; spezifischere Anweisungen haben Vorrang. Für Team, Project und User Rules lautet die dokumentierte Rangfolge bei Konflikten Team → Project → User. Cursor-Dokumentation zu Regeln

Für kleine Teams setze ich standardmäßig auf Projektregeln. Eine Anweisung wie „Unsere vorhandenen Formularkomponenten verwenden“ gehört ins Repository. „Die abschließende Antwort kurz halten“ ist eine persönliche Vorliebe. Diese Trennung verhindert, dass aus einer individuellen Präferenz versehentlich eine Teamvorgabe wird.

Wann soll eine Regel in den Kontext gelangen?

Das Frontmatter, also der kleine Einstellungsblock vor dem Regeltext, bestimmt, wann Cursor die Regel in den Kontext aufnimmt.

Bei der Auswahl durch den Agenten entscheidet dieser anhand der Beschreibung, ob er die Regel benötigt. Ein Glob ist ein Muster für Dateipfade. Zuordnung und Syntax

Die Zuordnung lässt sich mit einem Arbeitsauftrag vergleichen, der an der richtigen Werkbank ankommen muss. Die beste Formulierung hilft wenig, wenn eine Aufgabe die Anweisung gar nicht erhält. Grundlegende Sicherheitsregeln sollten immer gelten, Stilvorgaben an die passenden Dateien gebunden sein. Die Auswahl durch den Agenten eignet sich für Hinweise, deren Relevanz von der konkreten Aufgabe abhängt.

Drei Cursor Rules als Beispiele für eine TypeScript-Web-App

Die folgenden Dateien werden im Repository angelegt. Es handelt sich um Vorschläge für eigene Projektkonventionen, die die Frontmatter-Felder und Mustersyntax aus der Cursor-Dokumentation verwenden. Die enthaltenen Anweisungen sind anpassbare Ausgangspunkte, keine von Cursor vorgeschriebenen Programmierstandards.

Codestil: Regeln an TypeScript-Dateien binden

Als .cursor/rules/style.mdc speichern:

---
globs: src/**/*.ts, src/**/*.tsx
alwaysApply: false
---

- Follow the nearest existing module's naming and import conventions.
- Prefer named exports unless the framework requires a default export.
- Reuse existing UI components and utilities before adding alternatives.
- Keep formatting in the repository's formatter and linter configuration.

Das Beispiel setzt voraus, dass der Anwendungscode unter src/ liegt. Die Pfade müssen zum jeweiligen Repository passen. Bewusst geht es um Entscheidungen, die ein Formatierer nicht treffen kann: etwa darum, ob die Anwendung bereits einen geeigneten Button oder eine Hilfsfunktion für Datumsangaben enthält. Auch die bevorzugte Exportform ist anzupassen, wenn das Team anders entschieden hat. Eine Regel soll das Repository beschreiben und es nicht nebenbei umgestalten.

Tests: Die relevanten Aufgaben beschreiben

Als .cursor/rules/tests.mdc speichern:

---
description: Testing requirements when adding features, fixing bugs, or changing TypeScript behavior
alwaysApply: false
---

- Cover changed behavior with a focused regression test.
- Use the existing test runner, fixtures, and file naming conventions.
- Read package.json for the relevant test script; do not invent a command.
- Report the command and actual result, or explain why tests were not run.

Das Ziel ist ein sinnvoller Test mit einem ehrlichen Ergebnisbericht. Bei einer Fehlerbehebung sollte nachvollziehbar sein, dass der ursprüngliche Fehler durch einen Test abgedeckt ist. Bei einem Refactoring muss das relevante Verhalten erhalten bleiben. Dafür braucht es weder ein zweites Testframework noch einen Bericht, der „Test geschrieben“ mit „Test bestanden“ verwechselt.

Soll diese Checkliste bei einer Aufgabe ausdrücklich gelten, lässt sie sich mit @tests in der Anfrage anfordern. Möchte das Team sie bei jeder Aufgabe verwenden, wird die Zuordnung auf Always Apply umgestellt. Das ist eine bewusste Entscheidung über die Arbeitsweise: Mit der Beschreibung allein bleibt die Auswahl dem Agenten überlassen.

Sicherheit: Grundregeln knapp halten

Als .cursor/rules/security.mdc speichern:

---
alwaysApply: true
---

- Never put secrets in source code, test fixtures, or application logs.
- Use existing server-side authentication and authorization helpers.
- Validate untrusted input at server boundaries with the existing schemas.
- Do not remove permission checks to make a feature or test pass.

Sobald die konkreten Modulpfade bekannt sind, sollten sie den allgemeinen Verweis auf vorhandene Hilfsfunktionen ersetzen. Die Grundregeln müssen auch bei einer gewöhnlichen Feature-Aufgabe verständlich bleiben. „Sicher umsetzen“ gibt beim Review kaum etwas Prüffähiges vor; „Die Berechtigungsprüfung erhalten“ benennt eine konkrete Anforderung.

Diese Datei enthält Anweisungen, sie bildet keine Sicherheitsgrenze. Zugriffskontrollen müssen weiterhin im Code durchgesetzt und sensible Änderungen geprüft werden. Cursor selbst warnt davor, KI-Anweisungen als einzige Sicherheitsmaßnahme zu verwenden. Hinweise zu Team Rules

Die Einrichtung an einer echten Änderung prüfen

Geeignet ist eine kleine Aufgabe, bei der bisher wiederholt Korrekturen nötig waren. Eine Änderung an der Formularvalidierung bietet sich an: Sie betrifft eine Komponente, verändert das Verhalten und verarbeitet Benutzereingaben.

1. Das erwartete Ergebnis festhalten. Dazu gehören die vorhandene Komponente, die wiederverwendet werden soll, das zu testende Verhalten und die Stelle, an der die Validierung erhalten bleiben muss.
2. Die drei Dateien speichern und ihren Status prüfen. Cursor zeigt Regeln unter Customize → Rules an; im Agenten steht außerdem /create-rule zur Verfügung. Eine Regel erstellen
3. Die Änderung mit den relevanten Dateien im Kontext anfordern. Die Anfrage sollte einer echten Aufgabe entsprechen. Wiederholt sie sämtliche Regeln, lässt sich daraus nicht erkennen, ob die Einrichtung geholfen hat.
4. Den Diff und die gemeldeten Prüfungen kontrollieren. Entscheidend ist die tatsächlich eingehaltene Konvention, nicht die Versicherung, alle Regeln befolgt zu haben. Ist die Testcheckliste für diesen Versuch wichtig, sollte @tests ausdrücklich angefordert werden.
5. Die nützlichen Regeln zusammen mit der Änderung committen. So erhält das Team einen prüfbaren Ausgangspunkt. Lieber einen unklaren Satz verbessern, bevor eine weitere Datei hinzukommt.

Wird eine Konvention übergangen, kommen zwei unterschiedliche Ursachen infrage: Entweder hat die Regel die Aufgabe nicht erreicht, oder sie war im Kontext vorhanden, aber wirkungslos. Im ersten Fall muss die Zuordnung korrigiert werden. Im zweiten helfen eine klarere Anweisung, ein Beispiel oder eine automatisierte Prüfung.

Welche Konventionen lohnen sich als dauerhafte Regeln?

Der beste Ausgangspunkt sind wiederkehrende Fehler, die das Team besonders viel Zeit kosten. Die folgenden Anwendungsfälle sind danach geordnet, wie viel Review-Aufwand sie abnehmen könnten.

Daraus folgt keine Pflicht, fünf weitere Dateien anzulegen. Was bisher kein Problem war, muss nicht in die Regeln. Lässt sich eine Anforderung präzise automatisiert prüfen, ist diese Prüfung vorzuziehen. Eine nützliche Regel schließt eine Lücke zwischen der konkreten Aufgabenstellung und den vorhandenen Werkzeugen im Repository.

Was ist mit der alten .cursorrules-Datei?

Für die aktuell dokumentierte Einrichtung von Projektregeln ist .cursor/rules/*.mdc vorgesehen. Stand 11. Oktober 2026 erwähnt die Regeldokumentation .cursorrules nicht. Sie bestätigt damit auch nicht, ob die alte Datei weiterhin funktioniert. Aktuelle Dokumentation

Für Repositorys, die noch die alte Datei enthalten, empfehle ich, die weiterhin nützlichen Anweisungen in gezielte Projektregeln zu überführen. Die drei Dateien oben dienen als Ausgangspunkt. Zunächst die Auslöser festlegen und eine echte Aufgabe prüfen, bevor die alte Fassung entfernt wird. Überholte Konventionen sollten nicht allein deshalb bestehen bleiben, weil sie schon einmal aufgeschrieben wurden.

Wie passen CLAUDE.md und AGENTS.md dazu?

Die gemeinsame Idee sind dauerhafte Projektanweisungen: Claude Code verwendet CLAUDE.md, Codex liest Arbeitsvereinbarungen in AGENTS.md. Cursors einfache Markdown-Variante deckt denselben grundlegenden Anwendungsfall ab; die .mdc-Dateien bieten zusätzlich verschiedene Möglichkeiten der Zuordnung. Die Konventionen sollten übereinstimmen, das Ladeverhalten muss jedoch für jedes Tool bewusst eingerichtet werden. Text zu kopieren ist nicht dasselbe wie Einstellungen zu übernehmen. In Teams mit mehreren Agenten sollte eine Person für die gemeinsamen Konventionen verantwortlich sein, damit die Dateien nicht zu widersprüchlichen Referenzen werden.

Zwei kleine Tools, die sich nach der Einrichtung anbieten

Ein Prüfwerkzeug für Repository-Regeln ist die vielversprechendere Idee für eine technische Teamleitung: Es kontrolliert Dateiendungen, bekannte Frontmatter-Felder und Muster, auf die keine versionierte Datei passt. Als kleinste sinnvolle Umsetzung reicht ein lokaler Bericht, der während des Reviews erzeugt wird. Das Nachfragesignal ist überschaubar: DataForSEO lieferte bei der Recherche für diesen Artikel 140 geschätzte monatliche Suchanfragen für „cursor rules examples“. Das zeigt Interesse an einem verwandten Thema, belegt aber keine Zahlungsbereitschaft. Die Grenze des Ansatzes ist klar: Eine strukturell gültige Regel kann trotzdem schlechte Anweisungen enthalten. Definition der Kennzahl

Ein Review-Paket für Teamkonventionen könnte einer Teamleitung helfen, die mehrere Repositorys betreut. Wiederkehrende Review-Kommentare und freigegebene Beispiele werden zu einem vorgeschlagenen Regel-Diff zusammengeführt; für jede Änderung wird eine prüfende Person benannt. DataForSEO lieferte 70 geschätzte monatliche Suchanfragen für „cursor team rules“. Der Einstieg sollte als internes Hilfsmittel erfolgen. Die integrierten Team Rules übernehmen bereits die Verteilung, daher ist ein weiteres Dashboard zur Ablage wenig überzeugend als Produkt. Die eigentliche Arbeit liegt in der Entscheidung, was eine dauerhafte Anweisung werden sollte. Definition der Kennzahl

Häufige Fragen zur Einrichtung

Für die nächste Woche genügt eine wiederkehrende Korrektur: Die zugehörige Regel präzisieren und am nächsten gewöhnlichen Pull Request erproben. Bei der grundsätzlichen Produktentscheidung helfen der Cursor-Testbericht oder die besten Cursor-Alternativen.

Wenn diese Einrichtung Teil des Entwicklungsablaufs eines Teams werden soll, passt das zum Angebot KI-Systeme für den Produktivbetrieb.