Claude Skills vs. Windsurf Rules & Memories

Windsurf hat etwas gemacht, das sich kein anderer KI-Editor die Mühe gemacht hat zu tun: Es gab seinem Agenten ein Notizbuch und sagte ihm, er solle sich selbst Notizen machen. Rules, die du selbst schreibst, klar, jedes Tool hat die inzwischen. Aber Cascade, Windsurfs Agent, generiert auch Memories von selbst, mitten in der Unterhaltung, ohne dass man ihn bittet. Arbeite eine Woche in einem Repo, und er baut still ein privates Modell davon, wie du die Dinge gern gemacht hast.

Claude Skills kommen aus der entgegengesetzten Philosophie. Nichts kommt in einen Skill, außer eine Person hat es geschrieben, und nichts aktiviert, außer die Beschreibung verdient es. Wir betreiben SkillProof, wo wir Skills auf einer sauberen Maschine installieren und testen, bevor wir sie listen, wir leben also auf der expliziten Seite dieser Kluft. Wir versuchen trotzdem fair zu sein, weil die Auto-Memory-Idee mehr als eine Abfertigung verdient.

Kurzfassung: Windsurf Rules sind ein solides Always-on- und Glob-gescoptes Anweisungssystem, nah an dem von Cursor. Memories sind der wirklich neue Teil: mühelose Personalisierung, die den Editor umso besser macht, je länger du ihn nutzt. Skills gewinnen bei Portabilität, zusätzlichem Tooling, Arbeit, die kein Code ist, und der Tatsache, dass du jedes Wort dessen lesen kannst, was deiner KI beigebracht wurde. Lebst du komplett in Windsurf, nutze Rules für harte Gesetze und lass Memories sich anhäufen, aber prüfe sie monatlich. Ist Claude irgendwo Teil deines Workflows, halte dein dauerhaftes Fachwissen in Skills und behandle Windsurfs Memory als Cache, nicht als Wahrheitsquelle.

	Windsurf Rules + Memories	Claude Skills
Format	Markdown in .windsurf/rules/, plus automatisch generierte Memories pro Workspace	SKILL.md-Ordner in ~/.claude/skills/ oder .claude/skills/
Auslöser	Always On, Glob, Model Decision oder manuelles @-Erwähnen; Memories tauchen automatisch auf	Beschreibungsabgleich, vom Modell entschieden
Wer schreibt es	Du schreibst Rules; Cascade schreibt Memories	Du, oder ein Autor, den du prüfen kannst
Inhalt	Reiner Text, begrenzt (etwa 6.000 Zeichen pro Rule-Datei)	Anweisungen plus Skripte, Templates, Referenzdateien
Portabilität	Nur Windsurf	Claude Code, Claude Desktop, claude.ai, das Agent SDK
Überprüfbarkeit	Rules ja; Memories nur, wenn du das Panel öffnest und nachschaust	Alles auf der Platte, diffbar, in Versionskontrolle
Testkultur	Keine	Größtenteils keine; wir testen unsere

Was Windsurf Rules und Memories eigentlich sind

Windsurf teilt persistenten Kontext in zwei Systeme, die die Doku unter einem Namen zusammenfasst, Memories, was alle verwirrt. Eine Trennung lohnt sich.

Rules sind Markdown-Dateien, die du schreibst. Projekt-Rules leben in .windsurf/rules/, eine Datei pro Anliegen, und eine global_rules.md gilt projektübergreifend. Jede Datei trägt einen Aktivierungsmodus: Always On (in jeden Cascade-Request injiziert), Glob (hängt an, wenn eine passende Datei im Kontext ist, sodass *.tsx-Rules bei React-Arbeit mitfahren), Model Decision (Cascade liest eine von dir bereitgestellte Beschreibung und entscheidet) und Manual (nur bei @-Erwähnung). Dateien sind auf etwa 6.000 Zeichen begrenzt, mit einem kombinierten Budget über globale und Workspace-Rules, Windsurf sagt dir also direkt, dass dieser Inhalt im Prompt sitzt und Länge einen Preis hat.

Wenn du unseren Cursor-Vergleich gelesen hast, sollte das vertraut klingen. Die vier Modi bilden sich fast eins zu eins auf die von Cursor ab, und die Analyse zu Always-on- und Glob-Triggern überträgt sich unverändert.

Memories sind der Teil ohne Cursor-Äquivalent. Während du arbeitest, entscheidet Cascade, dass etwas es wert ist, gemerkt zu werden, "dieses Projekt nutzt pnpm, nicht npm", "Nutzer bevorzugt Early Returns gegenüber verschachtelten Bedingungen", und speichert es als eine auf den Workspace gescopte Memory. Du kannst es auch explizit bitten, sich etwas zu merken. Memories bleiben über Sessions hinweg bestehen, tauchen automatisch auf, wenn Cascade sie für relevant hält, und kosten keine Credits zum Generieren. Es gibt ein Panel, wo du sie lesen, bearbeiten und löschen kannst, was später wichtig wird.

Die ehrliche Rahmung ist also nicht Skills gegen Rules. Es ist ein explizites, portables Anweisungsformat gegen einen Hybrid: explizite Rules plus eine implizite, sich selbst schreibende Memory-Schicht.

Wo Windsurf wirklich gewinnt

Auto-Memories sind eine echte Innovation, und wir sagen das offen. Das schwierigste Problem bei KI-Anweisungsdateien ist, dass sie niemand schreibt. Jedes Team sagt, es werde seine Konventionen für den Agenten dokumentieren; fast keins tut es, und die Datei, die existiert, ist acht Monate alt. Windsurf umgeht menschliche Trägheit vollständig. Das Wissen wird als Nebenprodukt der Arbeit erfasst, in dem Moment, in dem es demonstriert wird. Nach ein paar Wochen kennt Cascade deinen Testrunner, deinen Import-Stil und dieses eine verfluchte Verzeichnis, das niemand anfasst, und du hast kein Wort davon aufgeschrieben. Als Antwort auf "wie wird dieses Wissen überhaupt festgehalten" ist das die beste, die je ein Editor geliefert hat.

Null-Setup-Personalisierung. Ein neuer Windsurf-Nutzer bekommt standardmäßig einen zunehmend smarteren Editor. Ein neuer Claude-Skills-Nutzer bekommt ein leeres Verzeichnis und eine Entscheidung zu treffen. Wir haben einen vollständigen Guide zu Skills geschrieben, teils weil das Format eine Lernkurve hat; Memories haben keine.

IDE-native Reichweite. Rules und Memories sind bei allem dabei, was Windsurf tut, einschließlich Inline-Bearbeitungen und Cascades agentischen Läufen, ohne Installationsschritt. Skills funktionieren dort, wo Claude läuft, was nicht das Innere des Editors einer anderen Firma einschließt.

Glob-Präzision. Derselbe Punkt wie bei Cursor, und er steht weiterhin: "hänge diese SQL-Konventionen an, wann immer eine .sql-Datei im Kontext ist" ist eine mechanische Garantie. Skills nähern sich dem über Beschreibungsformulierungen, die das Modell gut interpretiert, aber nicht garantiert.

Wo Skills gewinnen

Projekt- und oberflächenübergreifende Wiederverwendung. Ein Skill in ~/.claude/skills/ begleitet dich in jedes Repo, und auch in Claude Desktop und claude.ai. Deine Debugging-Disziplin gilt, wenn du eine Pipeline bei der Arbeit reparierst, und wenn du sonntags an einem Nebenprojekt herumbastelst. Windsurf-Memories sind bewusst auf den Workspace beschränkt; die pnpm-Lektion aus Projekt A wird in Projekt B neu gelernt. Globale Rules existieren, teilen sich aber das enge Zeichenbudget.

Arbeit, die kein Code ist. Windsurf ist eine IDE, und ihr ganzes Kontextsystem geht davon aus, dass die bearbeitete Sache ein Repository ist. Skills ist das egal. Dasselbe Format, das Claude deine Commit-Konventionen beibringt, bringt ihm auch bei, wie man einen Verkaufsvorschlag strukturiert oder einen Tabellen-Export bereinigt. Die halbe Katalog hat nichts mit Software zu tun.

Zusätzliches Tooling. Eine Rule-Datei, begrenzt auf 6.000 Zeichen, beschreibt Verhalten. Ein Skill-Ordner liefert es. Anthropics docx-Skill enthält Python-Skripte, die Word-Dokumente bauen, statt Prosa darüber, wie man es machen könnte. Der skill-creator-Skill trägt Templates und ein Eval-Framework. Ein Systematic-Debugging-Skill kann seine Eskalations-Checkliste in einer Referenzdatei halten, die nur mitten in der Untersuchung lädt. Progressive Disclosure macht das erschwinglich: Fünfzig installierte Skills liegen bei ein paar tausend Tokens Metadaten im Leerlauf, und das schwere Material bleibt auf der Platte, bis es tatsächlich gebraucht wird.

Ein auditierbares Ökosystem. Ein Skill ist Dateien. Du kannst jede Zeile vor der Installation lesen, sie nach einem Update diffen und in Versionskontrolle neben dem Code legen, den sie steuern. Wenn eine Kollegin fragt, warum der Agent Migrationen auf eine bestimmte Weise formatiert, ist die Antwort eine Datei mit Git-Historie. Das macht Drittanbieter-Skills auch überhaupt erst testbar, und warum unsere Coding-Sammlung Bestanden/Durchgefallen-Urteile statt Sternezahlen tragen kann.

Migration in beide Richtungen

Die Formate sind nah genug beieinander, dass Umwandlung größtenteils Umbenennung ist. Hier eine typische Windsurf-Projekt-Rule:

---
trigger: model_decision
description: API endpoint conventions for this service
---

- All endpoints live in src/api/, one file per resource
- Validate request bodies with zod schemas from src/schemas/
- Return errors as { error: { code, message } }, never bare strings
- Every new endpoint needs a happy-path test and a 401 test

Als Skill wandern die Trigger-Metadaten in Frontmatter, das Claude abgleicht, und du gewinnst Raum zum Wachsen:

---
name: api-endpoint-conventions
description: Conventions for building or modifying API endpoints in this
  service. Use when creating routes, changing request/response shapes, or
  reviewing API code.
---

## Structure
All endpoints live in src/api/, one file per resource.
Validate request bodies with zod schemas from src/schemas/.

## Errors
Return errors as { error: { code, message } }, never bare strings.

## Tests
Every new endpoint needs a happy-path test and a 401 test.
See reference/error-codes.md for the full error catalog.

Speicher es unter .claude/skills/api-endpoint-conventions/SKILL.md. Die Beschreibung übernimmt die Arbeit, die ein Trigger-Modus getan hat, formuliere sie also so, wie wir es in unserem Trigger-Guide beschreiben: nenn die Aufgabe, nenn den Moment. Und jetzt kann der Fehlerkatalog eine zusätzliche Referenzdatei sein statt ein Opfer der Zeichenbegrenzung.

Andersherum: Nimm den Body eines Skills, kürze ihn auf unter 6.000 Zeichen und wähle den ehrlichen Aktivierungsmodus:

---
trigger: glob
globs: "**/*.test.ts"
---

- Use vitest, never jest
- One describe block per exported function
- No snapshot tests for logic; snapshots are for markup only

Was du beim Export verlierst: zusätzliche Skripte (Rules können keine Executables mitliefern), Referenzdateien und alles über der Grenze hinaus. Was du gewinnst: Glob-Anhängen, das mechanisch feuert, ohne Modell-Urteil. Alles, was du bei der Umwandlung von Copilots Format gelernt hast, überträgt sich auch hier; dieser Vergleich deckt das applyTo-Äquivalent ab.

Memories sind der unbequeme Rest. Es gibt keinen Export-Button; sie leben in Windsurfs eigenem Speicher. Der praktische Weg ist, das Memories-Panel zu öffnen, zu lesen, was Cascade geschrieben hat, und die guten manuell zu Rules oder Skills zu befördern. Was uns zum unbequemen Teil bringt.

Das Auto-Memory-Problem: niemand überprüft, was es gelernt hat

Hier ist die Warnung, die in jeden Artikel gehört, der Auto-Memories lobt, und in fast keinem steht.

Cascade lernt aus dem, was du tust, und was du tust, schließt deine Fehler ein. Akzeptierst du freitags um 18 Uhr ein faules any, hat das Memory-System keine Möglichkeit zu wissen, dass das Kapitulation statt Vorliebe war. Lässt du es zusehen, wie du in einer Hotfix-Woche Tests überspringst, ist "dieser Nutzer schreibt keine Tests zuerst" eine korrekte Beobachtung, die es still verallgemeinern kann. Das System zeichnet demonstriertes Verhalten auf. Es kann deine Standards nicht von deinem Ausrutschen unterscheiden, weil es immer nur den Ausrutscher sieht.

Das tiefere Problem ist Review, oder dessen Abwesenheit. Jedes andere Artefakt, das deine Codebasis formt, durchläuft Augen: Code wird reviewt, Abhängigkeiten werden gescannt, Configs leben in Pull Requests. Memories werden vom Modell geschrieben, von niemandem genehmigt und unsichtbar konsultiert. Windsurf gibt dir ein Panel, um sie zu inspizieren, was wirklich zu seinen Gunsten spricht, und in unserer Erfahrung öffnet es ungefähr niemand. Wenn Verhalten driftet, ist die Ursache ein Satz in einem Speicher, den du vergessen hast, dass es ihn gibt.

Skills sitzen am anderen Ende, und das ist der philosophische Unterschied, der mehr wert ist als jede Feature-Checkliste. Ein Skill ist bewusst. Jemand hat entschieden, dass dieses Wissen es wert ist, kodiert zu werden, hat es aufgeschrieben, und kann gefragt werden, warum. Es ist vor der Installation überprüfbar, nach Updates diffbar, in Git für immer nachvollziehbar. Die Kosten sind auch ehrlich: explizit bedeutet aufwendig, und aufwendig bedeutet, dass weniger erfasst wird. Windsurf hat darauf gewettet, dass alles implizit zu erfassen besser ist, als weniger explizit zu erfassen. Für Editor-Komfort zahlt sich diese Wette oft aus. Für alles, was du Engineering-Standards nennen würdest, wollen wir die Version mit einem Autor.

Nutzt du Windsurf, nutze seine Stärke und managt sein Risiko: Lass Memories sich anhäufen, dann kalendarisiere ein monatliches zehnminütiges Audit. Lösch die, die deine schlechte Woche gemerkt haben. Beförder die Behaltenswerten zu Rules, wo sie explizit und sichtbar werden. Diese eine Gewohnheit verwandelt das Memory-System von langsamem Drift in einen Erfassungstrichter, wobei so etwas wie ein Memory-Management-Skill dieselbe Disziplin auf der Claude-Seite übernimmt.

Zwei ungetestete Ökosysteme, eine Testgewohnheit

Geteilte Rules und geteilte Skills haben dieselbe Krankheit: Veröffentlichung ohne Verifikation. GitHub hostet Tausende Rule-Dateien und Skills, die einmal geschrieben, mit Sternen versehen und nie von jemand anderem als dem Autor ausgeführt wurden, wenn der Autor sie überhaupt ausgeführt hat. Als wir anfingen, Community-Skills auf sauberen Maschinen zu installieren, scheiterte etwa die Hälfte beim ersten Versuch, und es gibt keinen Grund zu glauben, eingefügte Rule-Dateien schnitten besser ab. Sie scheitern nur leiser, weil eine Rule, die nie hilft, genau gleich aussieht wie eine Rule, die nie gelesen wurde.

Auto-Memories umgehen dieses spezielle Problem, da sie aus deinem Verhalten generiert werden statt von einem Fremden heruntergeladen. Ein echter Pluspunkt für sie, und derselbe Tausch wieder: Memories liegen nie falsch darüber, was du getan hast, nur darüber, ob du es so gemeint hast.

FAQ

Kann ich Claude Skills innerhalb von Windsurf nutzen? Nicht nativ. Cascade liest seine eigenen Rules und Memories, und Skills sind eine Claude-Konvention. Teams, die beides nutzen, halten typischerweise eine gemeinsame Rules-Datei für universelle Projektgesetze und pflegen Skills für Claude-Code-Sessions im selben Repo. Milde Duplikation, erträglich, solange beide kurz bleiben.

Kosten Windsurf-Memories Credits oder Tokens? Das Generieren von Memories verbraucht keine Credits. Ihr Inhalt belegt aber Prompt-Platz, wenn Cascade sie auftauchen lässt, genau wie Rules, ein weiterer Grund, den Speicher gelegentlich zu bereinigen.

Wo leben Windsurf Rules im Vergleich zu Skills? Windsurf: .windsurf/rules/ im Projekt, plus eine global_rules.md für alles. Claude: .claude/skills/<name>/SKILL.md pro Projekt, ~/.claude/skills/ global. Beide sind reines Markdown; nur Skills können zusätzliche Dateien mitführen.

Kann ich Windsurf-Memories in einen Skill exportieren? Es gibt keinen Exporter. Öffne das Memories-Panel, kopier die Einträge, die es wert sind, und schreib sie in eine SKILL.md mit einer Beschreibung, die nennt, wann sie gelten. Zehn Minuten Arbeit, und das Ergebnis ist versioniert und portabel, was der Memory-Speicher nicht ist.

Ist eine Windsurf-Rule mit model_decision dasselbe wie ein Skill-Trigger? Mechanisch ähnlich: Beide lassen das Modell eine Beschreibung lesen und entscheiden. Die Unterschiede liegen darin, was danach lädt (eine begrenzte Textdatei gegen einen Ordner mit Ressourcen) und wo die Entscheidung passieren kann (innerhalb von Windsurf gegen überall, wo Claude läuft).

Beide Systeme versuchen, dasselbe Problem von entgegengesetzten Enden zu lösen: Windsurf, indem es dich beobachtet, Skills, indem sie dich fragen. Beobachten skaliert besser. Fragen altert besser. Wir würden lieber zehn Dateien pflegen, die wir lesen können, als hundert Beobachtungen zu vertrauen, die wir nie gesehen haben, und wenn das nach der Berufskrankheit eines Testlabors klingt, ist es das auch. Es ist auch, wie wir gemerkt haben, dass ein halbes Ökosystem nicht funktioniert.