Claude Skills vs Windsurf Rules e Memories

Windsurf ha fatto una cosa che nessun altro editor AI si è preso la briga di fare: ha dato al suo agente un taccuino e gli ha detto di prendersi appunti da solo. Le regole che scrivi tu, ok, ormai ce le hanno tutti gli strumenti. Ma Cascade, l'agente di Windsurf, genera anche memorie in autonomia, a metà conversazione, senza che nessuno glielo chieda. Lavora in una repo per una settimana e lui, silenziosamente, si costruisce un modello privato di come ti piace che vengano fatte le cose.

Gli skill di Claude nascono dalla filosofia opposta. Niente entra in uno skill se non l'ha scritto una persona, e niente si attiva se la description non se lo guadagna. Noi gestiamo SkillProof, dove installiamo gli skill su una macchina pulita e li testiamo prima di elencarli, quindi viviamo dalla parte esplicita di questa divisione. Proveremo comunque a essere equi, perché l'idea delle memorie automatiche merita più di una liquidazione sbrigativa.

In breve: le regole di Windsurf sono un solido sistema di istruzioni always-on e con scope su glob, vicino a quello di Cursor. Le memorie sono la parte davvero nuova: personalizzazione a costo zero che migliora l'editor più lo usi. Gli skill vincono su portabilità, tooling incluso, lavori che non sono codice, e sul fatto che puoi leggere ogni parola di ciò che è stato insegnato alla tua AI. Se vivi interamente dentro Windsurf, usa le regole per le leggi ferree e lascia che le memorie si accumulino, ma controllale una volta al mese. Se Claude fa parte del tuo workflow in un punto qualsiasi, tieni la tua competenza durevole negli skill e tratta la memoria di Windsurf come una cache, non come fonte di verità.

	Regole + memorie di Windsurf	Skill di Claude
Formato	Markdown in .windsurf/rules/, più memorie generate automaticamente per workspace	Cartella SKILL.md in ~/.claude/skills/ o .claude/skills/
Trigger	Always On, glob, Model Decision, o menzione manuale con @; le memorie emergono automaticamente	Corrispondenza della description, decisa dal modello
Chi lo scrive	Le regole le scrivi tu; le memorie le scrive Cascade	Tu, o un autore che puoi verificare
Contenuto	Testo semplice, con un limite (circa 6.000 caratteri per file di regole)	Istruzioni più script, template, file di riferimento
Portabilità	Solo Windsurf	Claude Code, Claude Desktop, claude.ai, l'Agent SDK
Verificabilità	Le regole sì; le memorie solo se apri il pannello e guardi	Tutto su disco, confrontabile con diff, versionabile
Cultura del testing	Nessuna	Quasi nessuna; i nostri li testiamo

Cosa sono davvero le regole e le memorie di Windsurf

Windsurf divide il contesto persistente in due sistemi che la documentazione raggruppa sotto un unico nome, Memories, il che confonde tutti. Vale la pena separarli.

Le regole sono file markdown che scrivi tu. Le regole di progetto vivono in .windsurf/rules/, un file per ogni argomento, e un global_rules.md si applica a tutti i progetti. Ogni file porta con sé una modalità di attivazione: Always On (iniettata in ogni richiesta a Cascade), Glob (si aggancia quando un file corrispondente è nel contesto, così le regole per *.tsx seguono automaticamente il lavoro su React), Model Decision (Cascade legge una description che fornisci tu e decide), e Manual (solo quando la menzioni con @). I file hanno un tetto di circa 6.000 caratteri ciascuno, con un budget complessivo condiviso tra regole globali e di workspace: Windsurf ti sta dicendo direttamente che questo contenuto finisce nel prompt e che la lunghezza ha un prezzo.

Se hai letto il nostro confronto con Cursor, questo ti suonerà familiare. Le quattro modalità corrispondono quasi uno a uno a quelle di Cursor, e l'analisi su always-on e trigger via glob vale praticamente invariata.

Le memorie sono la parte senza equivalente in Cursor. Mentre lavori, Cascade decide che qualcosa vale la pena ricordarlo, "questo progetto usa pnpm, non npm", "l'utente preferisce gli early return ai condizionali annidati", e lo salva come memoria con scope sul workspace. Puoi anche chiedergli esplicitamente di ricordare qualcosa. Le memorie persistono tra le sessioni, emergono automaticamente quando Cascade le giudica rilevanti, e non costano credit da generare. C'è un pannello dove puoi leggerle, modificarle ed eliminarle, cosa che tornerà utile più avanti.

Quindi l'inquadramento onesto non è skill contro regole. È un formato di istruzioni esplicito e portabile contro un ibrido: regole esplicite più uno strato di memoria implicito che si scrive da solo.

Dove Windsurf vince davvero

Le memorie automatiche sono un'innovazione vera, e lo diciamo senza giri di parole. Il problema più difficile nei file di istruzioni per l'AI è che nessuno li scrive. Ogni team dice che documenterà le proprie convenzioni per l'agente; quasi nessuno lo fa, e il file che esiste è vecchio di otto mesi. Windsurf aggira completamente la pigrizia umana. La conoscenza viene catturata come sottoprodotto del lavoro, nel momento in cui viene dimostrata. Dopo qualche settimana, Cascade conosce il tuo test runner, il tuo stile di import, e quella maledetta cartella che nessuno tocca mai, e tu non ne hai scritta una parola. Come risposta a "come faccio a registrare questa conoscenza", è la migliore che qualsiasi editor abbia mai proposto.

Personalizzazione a configurazione zero. Un nuovo utente Windsurf ottiene di default un editor progressivamente più intelligente. Un nuovo utente degli skill di Claude ottiene una cartella vuota e una decisione da prendere. Abbiamo scritto una guida completa agli skill anche perché il formato ha una curva di apprendimento; le memorie non ne hanno.

Portata nativa dell'IDE. Regole e memorie partecipano a tutto ciò che fa Windsurf, comprese le modifiche inline e le esecuzioni agentiche di Cascade, senza alcun passaggio di installazione. Gli skill operano ovunque operi Claude, il che non include l'interno dell'editor di un'altra azienda.

Precisione dei glob. Stesso discorso fatto per Cursor, e resta valido: "aggancia queste convenzioni SQL ogni volta che un file .sql è nel contesto" è una garanzia meccanica. Gli skill la approssimano con il testo della description, che il modello interpreta bene ma non promette.

Dove vincono gli skill

Riutilizzo cross-project e cross-superficie. Uno skill in ~/.claude/skills/ ti segue in ogni repo, e anche in Claude Desktop e claude.ai. La tua disciplina di debug si applica sia quando sistemi una pipeline al lavoro sia quando smanetti su un progetto personale la domenica. Le memorie di Windsurf hanno scope sul workspace per design; la lezione su pnpm imparata nel progetto A va reimparata nel progetto B. Le regole globali esistono, ma condividono quello stesso budget di caratteri ristretto.

Lavoro che non è codice. Windsurf è un IDE, e tutto il suo sistema di contesto presuppone che l'oggetto del lavoro sia una repository. Agli skill non importa. Lo stesso formato che insegna a Claude le tue convenzioni di commit gli insegna anche come strutturare una proposta commerciale o ripulire l'esportazione di un foglio di calcolo. Metà del nostro catalogo non ha nulla a che fare col software.

Tooling incluso. Un file di regole, limitato a 6.000 caratteri, descrive un comportamento. Una cartella skill lo spedisce già pronto. Lo skill docx di Anthropic include script Python che costruiscono documenti Word invece di prosa su come si potrebbe farlo. Lo skill skill-creator porta con sé template e un harness di valutazione. Uno skill di debugging sistematico può tenere la sua checklist di escalation in un file di riferimento che si carica solo a metà indagine. La progressive disclosure è ciò che rende tutto questo sostenibile: cinquanta skill installati restano inattivi a poche migliaia di token di metadati, e il materiale pesante resta su disco fino al momento in cui serve.

Un ecosistema che puoi verificare. Uno skill è fatto di file. Puoi leggere ogni riga prima di installarlo, confrontarlo con un diff dopo un aggiornamento, e metterlo nel version control accanto al codice che governa. Quando un collega chiede perché l'agente formatta le migration in un certo modo, la risposta è un file con una cronologia git. È anche ciò che rende gli skill di terze parti testabili in assoluto, e perché la nostra raccolta coding può portare verdetti pass/fail invece che conteggi di stelline.

Migrare in entrambe le direzioni

I formati sono abbastanza vicini che la conversione è per lo più una rietichettatura. Ecco una tipica regola di progetto Windsurf:

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

Come skill, i metadati del trigger si spostano nel frontmatter con cui Claude fa il match, e guadagni spazio per crescere:

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

Salvalo sotto .claude/skills/api-endpoint-conventions/SKILL.md. La description fa il lavoro che prima faceva una modalità di trigger, quindi scrivila come descriviamo nella nostra guida al triggering: nomina il compito, nomina il momento. E ora il catalogo degli errori può diventare un file di riferimento incluso invece di restare vittima del limite di caratteri.

Andando nella direzione opposta, prendi il corpo di uno skill, taglialo sotto i 6.000 caratteri, e scegli la modalità di attivazione onesta:

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

Cosa perdi nell'esportazione: script inclusi (le regole non possono spedire eseguibili), file di riferimento, e tutto ciò che eccede il limite. Cosa guadagni: un aggancio via glob che scatta meccanicamente, senza alcun giudizio del modello coinvolto. Anche quello che hai imparato convertendo il formato di Copilot torna utile qui; quel confronto copre l'equivalente di applyTo.

Le memorie sono il resto scomodo. Non c'è un pulsante di esportazione; vivono nello storage proprio di Windsurf. La mossa pratica è aprire il pannello Memories, leggere cosa ha scritto Cascade, e promuovere a mano quelle buone in regole o skill. Il che ci porta alla parte scomoda.

Il problema delle memorie automatiche: nessuno rivede cosa ha imparato

Ecco l'avvertimento che dovrebbe stare in ogni articolo che elogia le memorie automatiche, e che non compare in quasi nessuno.

Cascade impara da quello che fai, e quello che fai include i tuoi errori. Accetti un any sciatto alle 18 di venerdì e il sistema di memoria non ha modo di sapere che quella era resa, non preferenza. Lo lasci guardare mentre salti i test durante una settimana di hotfix e "questo utente non scrive prima i test" è un'osservazione accurata che potrebbe silenziosamente generalizzare. Il sistema registra il comportamento dimostrato. Non può distinguere i tuoi standard dai tuoi cedimenti, perché vede solo i cedimenti.

Il problema più profondo è la revisione, o la sua assenza. Ogni altro artefatto che plasma la tua codebase passa sotto degli occhi: il codice viene revisionato, le dipendenze vengono scansionate, le config vivono nelle pull request. Le memorie sono scritte dal modello, approvate da nessuno, e consultate in modo invisibile. Windsurf ti dà un pannello per ispezionarle, il che è genuinamente a suo merito, e nella nostra esperienza praticamente nessuno lo apre. Quando il comportamento devia, la causa è una frase in un archivio che avevi dimenticato esistesse.

Gli skill stanno all'estremo opposto, ed è questa la differenza filosofica su cui vale la pena scegliere, più di qualsiasi elenco di funzionalità. Uno skill è deliberato. Qualcuno ha deciso che questa conoscenza valeva la pena codificarla, l'ha scritta, e gli si può chiedere il perché. È verificabile prima dell'installazione, confrontabile con diff dopo gli aggiornamenti, attribuibile per sempre in git. Anche il costo è onesto: esplicito significa faticoso, e faticoso significa che si cattura di meno. Windsurf ha scommesso che catturare tutto implicitamente batte catturare meno esplicitamente. Per il comfort dell'editor, quella scommessa spesso paga. Per qualsiasi cosa tu chiamassi standard di ingegneria, noi vogliamo la versione con un autore.

Se usi Windsurf, sfrutta il suo punto di forza e gestisci il suo rischio: lascia che le memorie si accumulino, poi metti a calendario un audit di dieci minuti al mese. Elimina quelle che hanno memorizzato la tua settimana no. Promuovi quelle buone a regole, dove diventano esplicite e visibili. Questa singola abitudine trasforma il sistema di memoria da una lenta deriva in un imbuto di cattura, con qualcosa come uno skill di gestione della memoria che gestisce la stessa disciplina sul lato Claude.

Due ecosistemi non testati, un'unica abitudine di testing

Le regole condivise e gli skill condivisi hanno la stessa malattia: pubblicazione senza verifica. GitHub ospita migliaia di file di regole e skill scritti una volta, messi tra le stelline, e mai eseguiti da nessuno se non dall'autore, sempre che l'autore stesso li abbia eseguiti. Quando abbiamo iniziato a installare skill della community su macchine pulite, circa la metà falliva al primo tentativo, e non c'è motivo di credere che i file di regole incollati se la cavino meglio. Falliscono solo più silenziosamente, perché una regola che non aiuta mai è identica a una regola mai letta.

Le memorie automatiche schivano questo problema specifico, essendo generate dal tuo comportamento invece che scaricate da un estraneo. Un punto vero a loro favore, e lo stesso compromesso torna a presentarsi: le memorie non sbagliano mai su cosa hai fatto, solo su se lo intendevi davvero.

FAQ

Posso usare gli skill di Claude dentro Windsurf? Non nativamente. Cascade legge le proprie regole e memorie, e gli skill sono una convenzione di Claude. I team che usano entrambi in genere mantengono un file di regole condiviso per le leggi universali del progetto, e mantengono gli skill per le sessioni di Claude Code nella stessa repo. Una lieve duplicazione, sopportabile finché entrambi restano brevi.

Le memorie di Windsurf consumano credit o token? Generare le memorie non consuma credit. Il loro contenuto occupa però spazio nel prompt quando Cascade le fa emergere, esattamente come le regole, il che è un altro motivo per potare l'archivio ogni tanto.

Dove vivono le regole di Windsurf rispetto agli skill? Windsurf: .windsurf/rules/ nel progetto, più un global_rules.md per tutto il resto. Claude: .claude/skills/<name>/SKILL.md per progetto, ~/.claude/skills/ a livello globale. Entrambi sono semplice markdown; solo gli skill possono portare file aggiuntivi al fianco.

Posso esportare le memorie di Windsurf in uno skill? Non esiste un esportatore. Apri il pannello Memories, copia le voci che vale la pena conservare, e scrivile in un SKILL.md con una description che nomina quando si applicano. Dieci minuti di lavoro, e il risultato è versionato e portabile, cosa che l'archivio delle memorie non è.

Una regola Windsurf con model_decision è la stessa cosa di un trigger di skill? Meccanicamente simile: entrambi lasciano che il modello legga una description e decida. Le differenze stanno in cosa viene caricato dopo (un file di testo limitato contro una cartella con risorse) e dove può avvenire la decisione (dentro Windsurf contro ovunque giri Claude).

Entrambi i sistemi stanno cercando di risolvere lo stesso problema da estremi opposti: Windsurf osservandoti, gli skill chiedendoti. Osservare scala meglio. Chiedere invecchia meglio. Noi preferiamo mantenere dieci file che possiamo leggere piuttosto che fidarci di cento osservazioni che non abbiamo mai visto, e se questo suona come il bias professionale di un laboratorio di test, lo è. Ed è anche così che abbiamo scoperto che metà di un ecosistema non funzionava.