Claude Skills vs. Cursor Rules: Was ist besser?

Wenn du 2026 mit KI-Unterstützung programmierst, hast du wahrscheinlich Anweisungen an zwei Orten liegen: einen .cursor/rules-Ordner, den Cursor liest, und ein Skills-Verzeichnis, das Claude liest. Beide lösen dasselbe Problem, nämlich deiner KI beizubringen, wie dein Projekt funktioniert, damit du dich nicht ständig wiederholst, und sie lösen es unterschiedlich genug, dass eine falsche Wahl dich Tokens, Sync-Kopfschmerzen oder beides kostet.

Wir betreiben SkillProof, wo wir Claude Skills auf einer sauberen Maschine installieren und testen, bevor wir sie listen. Das gibt uns einen bestimmten Blickwinkel auf diesen Vergleich: Wir haben während des Testens Dutzende Rule-Dateien in Skills umgewandelt und beobachtet, wie beide Formate auf Weisen scheitern, die ihre Dokumentation nicht erwähnt.

Kurzfassung: Cursor Rules sind einfacher und näher an deinem Editor. Claude Skills sind leistungsfähiger und reisen mit dir über Tools hinweg. Rules gewinnen, wenn die Anweisung auf jede Datei zutreffen soll, die einem Muster entspricht, immer. Skills gewinnen, wenn die Anweisung bedingt ist, zusätzliche Dateien mitbringt oder außerhalb einer IDE funktionieren muss. Die meisten Entwickler, die beide Tools nutzen, sollten Projektkonventionen in einer gemeinsamen Datei halten und alles Bedingte in Skills packen.

	Cursor Rules	Claude Skills
Geltungsbereich	Pro Projekt (.cursor/rules/) oder pro Nutzer (Einstellungen)	Global (~/.claude/skills/) oder pro Projekt (.claude/skills/)
Auslöser	Glob-Muster, immer aktiv oder Beschreibungsabgleich	Beschreibungsabgleich, vom Modell entschieden
Inhalt	Reine Anweisungen	Anweisungen plus Skripte, Templates, Referenzdateien
Portabilität	Nur Cursor	Claude Code, Claude Desktop, claude.ai, das Agent SDK
Kontextkosten	Voller Rule-Text, wenn angehängt; Always-on-Rules fahren bei jedem Request mit	~100 Tokens Metadaten bis zum Trigger, dann der Body
Ökosystem	Groß; Tausende geteilte .cursorrules auf GitHub	Kleiner, aber wachsend; enthält Anthropics offizielles Set
Testkultur	Praktisch keine	Größtenteils keine; wir testen unsere

Jetzt die Details, denn die Tabelle verbirgt die interessanten Teile.

Was Cursor Rules eigentlich sind

Cursor hat zwei Generationen derselben Idee. Die ursprüngliche .cursorrules-Datei liegt im Projektstamm: eine einzige Klartextdatei mit Anweisungen, die in jeden KI-Request in diesem Repo eingefügt wird. Sie ist veraltet, wird aber noch respektiert, und ein Großteil der öffentlichen Beispiele nutzt sie weiterhin.

Das aktuelle System ist ein .cursor/rules/-Verzeichnis mit .mdc-Dateien, jede mit Frontmatter, das steuert, wann sie gilt. Vier Modi: Always (jeder Request), Auto Attached (feuert, wenn eine Datei, die einem Glob entspricht, im Kontext ist, sodass globs: *.tsx nur bei React-Arbeit anhängt), Agent Requested (das Modell liest die Beschreibung und entscheidet) und Manual (nur bei explizitem @-Erwähnen). Cursor liest außerdem AGENTS.md, was später in diesem Artikel wichtig wird. Es gibt auch nutzerweite Rules, die in Cursors Einstellungen gesetzt werden und projektübergreifend gelten.

Falls sich das stark nach dem Trigger-System eines Skills anhört, stimmt das teilweise. Agent-Requested-Rules werden genau so per Beschreibung abgeglichen wie Skills. Der Unterschied liegt darin, was nach dem Trigger passiert, und dazu kommen wir noch.

Wo Rules wirklich gewinnen

Wir testen Claude Skills beruflich, du würdest also erwarten, dass wir überall für Skills argumentieren. Tun wir nicht, denn Rules haben echte Stärken.

Always-on-Rules sind einfacher zu durchschauen. Eine Rule mit alwaysApply: true steckt in jedem Request, Punkt. Es gibt keinen Trigger, der fehlzünden kann, keine Beschreibung, die falsch formuliert sein könnte, keine "warum hat das nicht aktiviert"-Debugging-Session. Wenn wir Skills testen, ist Trigger-Versagen einer der beiden häufigsten Fehler, die wir finden. Rules im Always- oder Glob-Modus können diesen Fehler strukturell nicht haben. Für eine kleine Menge harter Projektgesetze ("fass niemals die generierten Dateien in src/gen/ an") schlägt eine simple Always-on-Rule eine clevere bedingte.

Glob-Scoping ist präzise. globs: **/*.sql bedeutet, dass deine SQL-Konventionen bei SQL-Arbeit anhängen und sonst nie. Die Zuordnung von Dateityp zu Anweisung ist mechanisch und vorhersehbar. Skills nähern sich dem über Beschreibungsformulierungen ("nutzen beim Schreiben von SQL"), was in der Praxis gut funktioniert, aber eine Ermessensentscheidung des Modells ist statt eines Musterabgleichs.

Sie leben dort, wo du tippst. Rules integrieren sich in Cursors Tab-Vervollständigung, Inline-Bearbeitungen und Agent-Modus ohne jegliches Setup. Nichts zu installieren, keine Verzeichniskonventionen zu lernen, außer Dateien in einen Ordner zu legen.

Das Ökosystem ist riesig. Durchsuche GitHub nach .cursorrules und du findest Tausende Dateien für so gut wie jedes Framework. Die Qualität schwankt stark, die Abdeckung nicht.

Was Skills können, was Rules nicht können

Falls du neu im Format bist, deckt unser vollständiger Guide zu Claude Skills die Anatomie ab. Hier der für den Vergleich relevante Teil.

Bedingtes Triggern mit echter Ökonomie dahinter. Ein Skill lädt in Stufen. Beim Start liest Claude nur Name und Beschreibung jedes Skills, etwa 100 Tokens. Der Body lädt, wenn die Beschreibung zu deiner Anfrage passt. Referenzdateien laden noch später, und nur bei Bedarf. Fünfzig installierte Skills liegen bei ein paar tausend Tokens insgesamt im Leerlauf. Fünfzig Always-on-Rules wären eine Kontextkatastrophe, weshalb Cursor Rule-Länge begrenzt und davor warnt. Progressive Disclosure bedeutet, dass ein Skill riesig sein kann, ohne teuer zu sein, und das verändert, was du dir leisten kannst aufzuschreiben.

Zusätzliche Dateien. Ein Skill ist ein Ordner, keine Datei. Anthropics docx-Skill bringt Python-Skripte mit, die Word-Dokumente bauen. Der skill-creator-Skill bringt Templates und ein Eval-Framework mit. Ein Code-Review-Skill kann eine Schwere-Rubrik als separate Referenzdatei mitführen, die nur bei Reviews lädt. Rules sind Text, der beschreibt, was das Modell tun soll. Skills können das Werkzeug mitliefern, das es tatsächlich tut, und das Modell führt das Skript aus, statt das Ergebnis zu improvisieren.

Portabilität. Ein Skill, den du für Claude Code schreibst, funktioniert auch in Claude Desktop, auf claude.ai und in allem, was auf dem Agent SDK basiert. Deine Git-Konventionen begleiten dich vom Terminal zum Chat bis zu einem eigenen Agenten. Eine Cursor-Rule funktioniert in Cursor. Wenn du je den Editor wechselst oder Claude für Nicht-Editor-Arbeit wie Schreiben oder Datenanalyse nutzt, ist das Skill-Format dasjenige, das den Umzug übersteht. Das ist das stärkste Argument für Skills als Cursor-Rules-Alternative: Du schreibst die Anweisungen einmal, und sie sind nicht an ein Produkt gebunden.

Skills können handeln, nicht nur raten. Weil Claude Code Befehle ausführt, kann ein Skill sagen "führ dieses Skript aus und füg die Ausgabe ein" statt "so könnte man die Ausgabe formatieren." Die Lücke zwischen Verhalten beschreiben und Verhalten liefern ist dieselbe Lücke wie zwischen einem Styleguide und einem Linter.

Was Rules können, was Skills nicht können

Zwei Dinge, und sie sind nicht klein.

IDE-native Kontexte. Rules sind bei allem dabei, was Cursor tut: Vervollständigungen beim Tippen, Cmd+K-Inline-Bearbeitungen, das Agent-Panel. Skills funktionieren dort, wo Claude läuft, was heute die CLI, die Desktop-App und Web bedeutet, nicht innerhalb des Editors einer anderen Firma. Wenn deine gesamte KI-Nutzung in Cursors Tab-Taste stattfindet, erreichen dich Skills dort nicht.

Anwendung pro Glob. Es gibt kein Skill-Äquivalent zu "hänge diese Anweisungen an, wann immer eine .proto-Datei im Kontext ist." Das Modell entscheidet anhand von Beschreibungen, und obwohl es darin gut ist, ist das keine Garantie. Für Anweisungen, die mit dem Dateityp statt mit der Aufgabenart korrelieren müssen, sind glob-gescopte Rules schlicht der bessere Mechanismus.

Der Migrationspfad, in beide Richtungen

Eine .cursorrules-Datei in einen Skill umwandeln

Nimm eine typische Rules-Datei:

You are an expert React and TypeScript developer.

- Functional components with hooks only, no classes
- Named exports, never default exports
- Tailwind for styling, no inline style objects
- All API calls go through src/lib/api.ts
- Tests in Vitest, colocated as *.test.tsx

Die Umwandlung besteht größtenteils darin, einen Trigger und Struktur hinzuzufügen:

---
name: react-conventions
description: React/TypeScript conventions for this repo. Use when
  writing or reviewing components, hooks, styles, API calls, or
  frontend tests.
---

## Components
- Functional components with hooks. No class components.
- Named exports only. No default exports.

## Styling
- Tailwind utility classes. Never inline style objects.

## Data access
- Every API call goes through `src/lib/api.ts`. Do not call
  fetch directly from a component.

## Tests
- Vitest, colocated next to the component as `*.test.tsx`.

Leg das in .claude/skills/react-conventions/SKILL.md ab, und es triggert bei Frontend-Arbeit in diesem Repo. Drei Dinge haben sich geändert, und jedes zählt. Die Persona-Zeile ("You are an expert...") ist weg, weil sie nichts bewirkt; das Modell wird nicht besser in React, weil man ihm sagt, es sei Experte. Die Beschreibung listet jetzt konkrete Tätigkeiten auf, weil dieses Feld der Trigger ist und vage Beschreibungen der Hauptgrund sind, warum Skills untätig herumliegen. Und die Punkte haben Überschriften bekommen, da ein Skill-Body beim Laden vom Modell überflogen werden können sollte. Unser Guide zum Schreiben von Skills behandelt den Beschreibungsteil ausführlich; das ist der Schritt, den die meisten vermasseln.

Während du dabei bist, frag dich, ob ein Punkt zu einer Datei werden sollte. Wenn deine Rules-Datei ein API-Antwortformat beschreibt, leg ein echtes Beispiel als reference.json neben die SKILL.md und verweise darauf. Diese Option gibt es im Rules-Format schlicht nicht.

Die andere Richtung

Einen Skill in eine Cursor-Rule umzuwandeln bedeutet, ihn flach zu klopfen. Nimm den Body deiner SKILL.md, entferne das Frontmatter und speichere sie als .cursor/rules/react-conventions.mdc mit neuem Frontmatter:

---
description: React/TypeScript conventions for this repo
globs: src/**/*.tsx,src/**/*.ts
alwaysApply: false
---

- Functional components with hooks. No class components.
- Named exports only. No default exports.
...

Du verlierst die zusätzlichen Dateien, also wird alles, was ein Skript war, zu einer Beschreibung dessen, was das Skript getan hat. Du verlierst Progressive Disclosure, also kürze hart: Ein 3.000-Token-Skill-Body sollte zu einer 500-Token-Rule werden, wobei nur bleibt, was Cursors Modelle pro Request wirklich brauchen. Halte den Glob eng, damit die Rule nicht unbeteiligte Arbeit belastet.

Beide nutzen, ohne dich zu duplizieren

Viele Entwickler nutzen Cursor zum Editieren und Claude Code für Agent-Arbeit im selben Repo. Die Falle ist, zwei Kopien derselben Konventionen zu pflegen, die innerhalb eines Monats auseinanderdriften.

Der Fix, der bei uns funktioniert hat: Wähle pro Anweisung ein kanonisches Zuhause, basierend auf ihrer Form.

Gemeinsame Projektfakten gehören in AGENTS.md. Beide Tools lesen sie. Architekturnotizen, Build-Befehle, Verzeichnisstruktur, die "fass diese Dateien niemals an"-Liste. Eine Datei, keine Duplikation, und sie dient auch menschlichen Neulingen.

Glob-förmige Anweisungen bleiben in .cursor/rules. Dateityp-Konventionen, die mechanisch im Editor anhängen sollen.

Aufgabenförmige und toolübergreifende Anweisungen werden Skills. Debugging-Methodik, Review-Checklisten, Release-Prozeduren, alles mit einem Skript oder Template, alles, was du auch in Claude Desktop oder im Chat verfügbar haben willst.

Wenn eine Anweisung wirklich in beiden Formaten existieren muss, mach die Rule zu einem Verweis, nicht zu einer Kopie: Eine zweizeilige .mdc, die sagt "Konventionen für X leben in .claude/skills/x/SKILL.md; befolge sie" hält eine einzige Quelle der Wahrheit. Manche Teams skripten die Umwandlung stattdessen in CI und regenerieren .mdc-Dateien aus SKILL.md-Bodies bei jedem Commit. Das ist mehr Maschinerie, als die meisten Projekte brauchen, aber es schlägt stillen Drift in einem großen Team.

Eine Sache, von der wir dir abraten würden: dasselbe 2.000-Wörter-Dokument wortgleich in beide Systeme zu kopieren. In Cursor bläht es jeden Request auf. In Claude ist es meist ein Zeichen dafür, dass der Inhalt in einen kleinen, immer relevanten Kern und eine Reihe bedingter Skills aufgeteilt werden sollte. Das ist dieselbe Überlegung wie bei Skills vs. MCP: Passe den Mechanismus an die Form des Problems an, statt ein Tool zu zwingen, alles zu übernehmen.

Niemand testet auch Rules

Hier ist der Teil dieses Vergleichs, den dir sonst niemand gibt, weil er unser ganzer Existenzgrund ist.

Als wir anfingen, Community-Claude-Skills zu testen, scheiterte etwa die Hälfte beim ersten Versuch: kaputte Trigger, Anweisungen, die das Modell nicht befolgen kann, Output, der nicht besser als die Baseline ist. Wir haben die Fehlertaxonomie in warum die Hälfte der Claude Skills nicht funktioniert dokumentiert. Die unangenehme Anschlussfrage ist, ob die Tausenden geteilten .cursorrules-Dateien auf GitHub irgendwie besser sind.

Sind sie nicht, und strukturell können sie es auch nicht sein. Dieselben Anreize gelten: Rules werden aus dem Workflow eines einzelnen Autors veröffentlicht, nie auf einem sauberen Setup verifiziert, nie gegen eine No-Rule-Baseline gemessen, und nach README-Qualität statt nach Ergebnissen mit Sternen bewertet. Wenn wir populäre Rule-Dateien auseinandergenommen haben, finden wir dieselben Mängel, für die wir Skills abwerten. Persona-Füllwörter, die Kontext verbrauchen und nichts ändern. Anweisungen, geschrieben für eine Modellversion, die zwei Generationen zurückliegt. Widersprüchliche Punkte ("sei knapp" vierzig Zeilen nach "erkläre deine Überlegungen immer ausführlich"). Rules, die so lang sind, dass sie den Code verdrängen, den sie eigentlich verbessern sollen.

Rules umgehen einen Fehlermodus, da eine Always-on-Rule nicht daran scheitern kann zu triggern. Jeder andere Fehlermodus überträgt sich direkt. Ein Konventionsdokument, das den Output schlechter macht, ist in beiden Formaten gleich schädlich; das Format ändert nur, wie es ausgeliefert wird.

Egal, auf welcher Seite dieses Vergleichs du landest, der operative Rat ist identisch: Installiere geteilte Anweisungsdateien nicht blind. Vergleiche den Output mit und ohne die Anweisungen an einer echten Aufgabe aus deinem eigenen Projekt. Zehn Minuten Vergleich schlagen jede Sternezahl. Für Skills haben wir diese Arbeit bereits über unsere getestete Coding-Sammlung erledigt, wo Einträge wie systematic-debugging Vorher-Nachher-Belege statt Versprechen tragen. Für Cursor Rules, soweit wir wissen, macht das niemand. Zieh deinen eigenen Schluss darüber, was die Hälfte davon wert ist.

FAQ

Kann Claude Code meine .cursorrules-Datei direkt lesen? Nicht automatisch. Claude Code liest CLAUDE.md, AGENTS.md und seine Skills-Verzeichnisse und ignoriert .cursorrules und .cursor/rules. Du kannst es innerhalb einer Session anweisen, die Datei zu lesen, aber für alles Dauerhafte wandle den Inhalt in einen Skill um oder verschiebe die gemeinsamen Teile nach AGENTS.md.

Kosten Cursor Rules genauso Tokens wie Skills? In den meisten Setups mehr. Eine Always-on-Rule fährt bei jedem einzelnen Request in voller Länge mit. Ein Skill liegt bei etwa 100 Tokens im Leerlauf und bezahlt seinen Body nur bei Trigger. Glob-gescopte Rules verringern die Lücke, da sie nur bei passender Arbeit anhängen, aber es gibt kein Rules-Äquivalent zum bedarfsweisen Laden von Referenzmaterial.

Sollte ich alle meine Cursor Rules zu Skills umwandeln? Nein. Behalte glob-gescopte, dateitypbezogene Konventionen als Rules, wenn du in Cursor arbeitest; dieser Mechanismus ist für sie wirklich besser. Wandle das aufgabenförmige Material um: Workflows, Checklisten, alles mit Templates oder Skripten, alles, was du außerhalb des Editors haben willst.

Gibt es einen gemeinsamen Standard, den beide Tools lesen? AGENTS.md kommt dem am nächsten. Cursor und Claude Code lesen beide diese Datei, zusammen mit einer wachsenden Liste weiterer Agenten. Es sind reine Always-on-Anweisungen ohne bedingtes Laden, also behandle sie als Zuhause für einen kleinen Kern an Projektfakten statt als Ablageort für alles.

Sind Claude Skills oder Cursor Rules besser für ein Team? Skills werden unter .claude/skills/ eingecheckt und versioniert wie Code, und Rules werden unter .cursor/rules/ genauso eingecheckt, also verteilen sich beide gut. Die Teamfrage dreht sich eigentlich um Reichweite: Wenn alle in Cursor arbeiten, erreichen Rules sie ohne jedes Setup. Wenn das Team auch Claude Code, Desktop oder auf dem SDK basierende Agenten nutzt, sind Skills das einzige Format, das jede Oberfläche abdeckt, und das Sync-Muster oben verhindert, dass die beiden auseinanderdriften.