Claude Skills vs Windsurf Rules & Memories Compared

Windsurf did something no other AI editor bothered to do: it gave its agent a notebook and told it to take its own notes. Rules you write yourself, fine, every tool has those now. But Cascade, Windsurf’s agent, also generates memories on its own, mid-conversation, without being asked. Work in a repo for a week and it quietly builds a private model of how you like things done.

Claude skills come from the opposite philosophy. Nothing gets into a skill unless a person wrote it, and nothing activates unless the description earns it. We run SkillProof, where we install skills on a clean machine and test them before listing, so we live on the explicit side of this divide. We’ll try to be fair anyway, because the auto-memory idea deserves more than a dismissal.

TL;DR: Windsurf rules are a solid always-on and glob-scoped instruction system, close to Cursor’s. Memories are the genuinely new part: zero-effort personalization that improves the editor the longer you use it. Skills win on portability, bundled tooling, work that isn’t code, and the fact that you can read every word of what your AI has been taught. If you live entirely inside Windsurf, use rules for hard laws and let memories accumulate, but audit them monthly. If Claude is part of your workflow anywhere, keep your durable expertise in skills and treat Windsurf’s memory as a cache, not a source of truth.

	Windsurf rules + memories	Claude skills
Format	Markdown in .windsurf/rules/, plus auto-generated memories per workspace	SKILL.md folder in ~/.claude/skills/ or .claude/skills/
Trigger	Always On, glob, Model Decision, or manual @-mention; memories surface automatically	Description match, decided by the model
Who writes it	You write rules; Cascade writes memories	You, or an author you can vet
Payload	Plain text, capped (about 6,000 characters per rule file)	Instructions plus scripts, templates, reference files
Portability	Windsurf only	Claude Code, Claude Desktop, claude.ai, the Agent SDK
Reviewability	Rules yes; memories only if you open the panel and look	Everything on disk, diffable, in version control
Testing culture	None	Mostly none; we test ours

What Windsurf rules and memories actually are

Windsurf splits persistent context into two systems that its docs group under one name, Memories, which confuses everyone. Worth separating.

Rules are markdown files you write. Project rules live in .windsurf/rules/, one file per concern, and a global_rules.md applies across all projects. Each file carries an activation mode: Always On (injected into every Cascade request), Glob (attaches when a matching file is in context, so *.tsx rules ride along during React work), Model Decision (Cascade reads a description you provide and decides), and Manual (only when you @-mention it). Files are capped at roughly 6,000 characters each with a combined budget across global and workspace rules, so Windsurf is telling you directly that this content sits in the prompt and length has a price.

If you read our Cursor comparison, this should sound familiar. The four modes map almost one-to-one onto Cursor’s, and the analysis of always-on and glob triggering carries over unchanged.

Memories are the part with no Cursor equivalent. As you work, Cascade decides that something is worth remembering, “this project uses pnpm, not npm,” “user prefers early returns over nested conditionals,” and saves it as a memory scoped to the workspace. You can also ask it to remember something explicitly. Memories persist across sessions, surface automatically when Cascade judges them relevant, and cost no credits to generate. There’s a panel where you can read, edit, and delete them, which will matter later.

So the honest framing isn’t skills versus rules. It’s an explicit, portable instruction format versus a hybrid: explicit rules plus an implicit, self-writing memory layer.

Where Windsurf genuinely wins

Auto-memories are a real innovation, and we’ll say so plainly. The hardest problem in AI instruction files is that nobody writes them. Every team says they’ll document their conventions for the agent; almost none do, and the file that exists is eight months stale. Windsurf routes around human laziness entirely. The knowledge gets captured as a byproduct of working, at the moment it’s demonstrated. After a few weeks, Cascade knows your test runner, your import style, and that one cursed directory nobody touches, and you never wrote a word of it down. As an answer to “how does this knowledge get recorded at all,” it’s the best one any editor has shipped.

Zero-setup personalization. A new Windsurf user gets a progressively smarter editor by default. A new Claude skills user gets an empty directory and a decision to make. We wrote a full guide to skills partly because the format has a learning curve; memories have none.

IDE-native reach. Rules and memories participate in everything Windsurf does, including inline edits and Cascade’s agentic runs, with no installation step. Skills operate wherever Claude operates, which does not include the inside of another company’s editor.

Glob precision. Same point as with Cursor, and it still stands: “attach these SQL conventions whenever a .sql file is in context” is a mechanical guarantee. Skills approximate it with description wording, which the model interprets well but does not promise.

Where skills win

Cross-project, cross-surface reuse. A skill in ~/.claude/skills/ follows you into every repo, and also into Claude Desktop and claude.ai. Your debugging discipline applies when you’re fixing a pipeline at work and when you’re poking at a side project on Sunday. Windsurf memories are workspace-scoped by design; the pnpm lesson learned in project A gets relearned in project B. Global rules exist but share that tight character budget.

Work that isn’t code. Windsurf is an IDE, and its whole context system assumes the thing being worked on is a repository. Skills don’t care. The same format that teaches Claude your commit conventions also teaches it how to structure a sales proposal or clean a spreadsheet export. Half our catalog has nothing to do with software.

Bundled tooling. A rule file, capped at 6,000 characters, describes behavior. A skill folder ships it. Anthropic’s docx skill includes Python scripts that build Word documents rather than prose about how one might. The skill-creator skill carries templates and an eval harness. A systematic debugging skill can keep its escalation checklist in a reference file that loads only mid-investigation. Progressive disclosure is what makes this affordable: fifty installed skills idle at a few thousand tokens of metadata, and the heavy material stays on disk until the moment it’s needed.

An ecosystem you can audit. A skill is files. You can read every line before installing, diff it after an update, and put it in version control next to the code it governs. When a teammate asks why the agent formats migrations a certain way, the answer is a file with a git history. This is also what makes third-party skills testable at all, and why our coding collection can carry pass/fail verdicts instead of star counts.

Migrating in both directions

The formats are close enough that conversion is mostly relabeling. Here’s a typical Windsurf project 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

As a skill, the trigger metadata moves into frontmatter Claude matches against, and you gain room to grow:

---
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.

Save it under .claude/skills/api-endpoint-conventions/SKILL.md. The description does the work a trigger mode did, so write it the way we describe in our triggering guide: name the task, name the moment. And now the error catalog can be a bundled reference file instead of a casualty of the character cap.

Going the other way, take a skill’s body, trim it under 6,000 characters, and pick the honest activation mode:

---
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

What you lose in the export: bundled scripts (rules can’t ship executables), reference files, and everything past the cap. What you gain: glob attachment that fires mechanically, no model judgment involved. Anything you learned from converting Copilot’s format transfers here too; that comparison covers the applyTo equivalent.

Memories are the awkward remainder. There’s no export button; they live in Windsurf’s own storage. The practical move is to open the Memories panel, read what Cascade wrote, and hand-promote the good ones into rules or skills. Which brings us to the uncomfortable part.

The auto-memory problem: nobody reviews what it learned

Here’s the caution that belongs in every article praising auto-memories, and appears in almost none.

Cascade learns from what you do, and what you do includes your mistakes. Accept a lazy any type at 6pm on a Friday and the memory system has no way to know that was surrender rather than preference. Let it watch you skip tests during a hotfix week and “this user doesn’t write tests first” is an accurate observation it may quietly generalize. The system records demonstrated behavior. It cannot tell your standards from your slippage, because it only ever sees the slippage.

The deeper issue is review, or the absence of it. Every other artifact that shapes your codebase passes through eyes: code gets reviewed, dependencies get scanned, configs live in pull requests. Memories are written by the model, approved by nobody, and consulted invisibly. Windsurf gives you a panel to inspect them, which is genuinely to its credit, and in our experience approximately nobody opens it. When behavior drifts, the cause is a sentence in a store you forgot exists.

Skills sit at the other end, and this is the philosophical difference worth choosing on, more than any feature checklist. A skill is deliberate. Someone decided this knowledge was worth encoding, wrote it down, and can be asked why. It’s reviewable before install, diffable after updates, blamable in git forever. The cost is honest too: explicit means effortful, and effortful means less gets captured. Windsurf bet that capturing everything implicitly beats capturing less explicitly. For editor comfort, that bet often pays. For anything you’d call engineering standards, we want the version with an author.

If you use Windsurf, use its strength and manage its risk: let memories accumulate, then calendar a monthly ten-minute audit. Delete the ones that memorized your bad week. Promote the keepers to rules, where they become explicit and visible. That single habit converts the memory system from a slow drift into a capture funnel, with something like a memory management skill handling the same discipline on the Claude side.

Two untested ecosystems, one testing habit

Shared rules and shared skills have the same disease: publication without verification. GitHub hosts thousands of rule files and skills that were written once, starred, and never run by anyone but the author, if the author ran them at all. When we started installing community skills on clean machines, roughly half failed on first try, and there’s no reason to believe pasted rule files fare better. They just fail more quietly, because a rule that never helps looks identical to a rule that was never read.

Auto-memories dodge this particular problem, being generated from your behavior rather than downloaded from a stranger’s. A real point in their favor, and the same trade again: memories are never wrong about what you did, only about whether you meant it.

FAQ

Can I use Claude skills inside Windsurf? Not natively. Cascade reads its own rules and memories, and skills are a Claude convention. Teams using both typically keep a shared rules file for universal project laws and maintain skills for Claude Code sessions in the same repo. Mild duplication, bearable if both stay short.

Do Windsurf memories cost credits or tokens? Generating memories consumes no credits. Their content does occupy prompt space when Cascade surfaces them, same as rules, which is another reason to prune the store occasionally.

Where do Windsurf rules live versus skills? Windsurf: .windsurf/rules/ in the project, plus a global_rules.md for everything. Claude: .claude/skills/<name>/SKILL.md per project, ~/.claude/skills/ globally. Both are plain markdown; only skills can carry additional files alongside.

Can I export Windsurf memories into a skill? There’s no exporter. Open the Memories panel, copy the entries worth keeping, and write them into a SKILL.md with a description that names when they apply. Ten minutes of work, and the result is versioned and portable, which the memory store is not.

Is a Windsurf rule with model_decision the same as a skill trigger? Mechanically similar: both let the model read a description and decide. The differences are what loads afterward (a capped text file versus a folder with resources) and where the decision can happen (inside Windsurf versus anywhere Claude runs).

Both systems are trying to solve the same problem from opposite ends: Windsurf by watching you, skills by asking you. Watching scales better. Asking ages better. We’d rather maintain ten files we can read than trust a hundred observations we’ve never seen, and if that sounds like a testing lab’s occupational bias, it is. It’s also how we caught half an ecosystem not working.