Cursor Rules: come impostare regole utili al tuo team

Il vantaggio è ridurre le correzioni in fase di revisione. Facciamo un conto puramente illustrativo: quattro sviluppatori che ogni settimana dedicano cinque minuti a ciascuna di tre correzioni spendono 60 minuti a ripetere le stesse convenzioni. Non è una promessa di risparmio. Misura quali correzioni scompaiono dopo la configurazione e sottrai il tempo necessario a mantenere le regole. Il costo dell'abbonamento è un tema a parte, trattato nella guida ai prezzi di Cursor.

Dove salvare le Cursor Rules

Le scelte di sviluppo condivise vanno accanto al codice. Le preferenze personali sulle risposte devono restare personali.

Le istruzioni di un file AGENTS.md in una sottodirectory si applicano a quella directory e alle sue discendenti, insieme alle indicazioni dei livelli superiori; in caso di conflitto prevalgono quelle più specifiche. Per Team Rules, Project Rules e User Rules, l'ordine di precedenza documentato è Team → Project → User. Documentazione delle regole di Cursor

Per un team piccolo, di norma parto dalle regole di progetto. Un'indicazione come «usa i componenti per i moduli già presenti» appartiene al repository. «Mantieni breve la risposta finale» è una preferenza personale. Tenere separate queste scelte evita che un gusto individuale diventi per caso una regola per tutto il team.

Quando deve attivarsi ogni regola?

Il frontmatter, il piccolo blocco di impostazioni sopra il testo di una regola, stabilisce quando viene aggiunta al contesto.

«Su scelta dell'agente» significa che l'agente seleziona la regola in base alla descrizione. Un glob è un pattern che identifica percorsi di file. Criteri di attivazione e sintassi

Pensa all'attivazione come alla consegna di un ordine di lavoro alla postazione giusta. Anche un'istruzione scritta benissimo non serve se non arriva all'attività che ne ha bisogno. Applica sempre i requisiti minimi di sicurezza, indirizza le convenzioni di stile ai file pertinenti e lascia all'agente la scelta solo quando l'utilità di un'indicazione dipende dall'attività.

Tre regole pronte da copiare per un'app web TypeScript

Crea nel repository i file seguenti. Sono convenzioni di lavoro proposte come esempio, basate sui campi del frontmatter e sulla sintassi dei pattern descritti nella documentazione di Cursor. Le istruzioni al loro interno sono punti di partenza da adattare, non standard di sviluppo imposti da Cursor.

Stile: applica la regola ai file TypeScript

Salva il file come .cursor/rules/style.mdc:

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

L'esempio presuppone che il codice dell'applicazione si trovi in src/; adatta i percorsi al tuo repository. La regola riguarda volutamente scelte che un formatter non può risolvere, come verificare se l'app ha già un pulsante adatto o una funzione di utilità per le date. Modifica la preferenza sugli export se il team ha scelto diversamente. Una regola deve descrivere il repository, non riprogettarlo di nascosto.

Test: descrivi le attività che li richiedono

Salva il file come .cursor/rules/tests.mdc:

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

L'obiettivo è ottenere un test utile e un resoconto fedele del risultato. La correzione di un bug dovrebbe lasciare una prova che il difetto originario è coperto da un test. Un refactoring dovrebbe preservare il comportamento interessato. Per nessuno dei due serve introdurre un secondo framework di test o un resoconto che confonda «test scritto» con «test superato».

Quando vuoi richiamare esplicitamente questa checklist, includi @tests nella richiesta. Se il team la vuole per ogni attività, cambia la modalità di attivazione in Always Apply. È una scelta di metodo da fare consapevolmente: con la sola descrizione, la selezione resta affidata all'agente.

Sicurezza: pochi requisiti di base, chiari

Salva il file come .cursor/rules/security.mdc:

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

Quando li conosci, sostituisci il riferimento alle funzioni esistenti con i percorsi effettivi dei moduli nel repository. I requisiti di base devono essere comprensibili anche durante lo sviluppo di una normale funzionalità. «Rendilo sicuro» offre poco da verificare in revisione; «mantieni il controllo delle autorizzazioni» indica un requisito concreto.

Questo file contiene istruzioni, non costituisce una barriera di sicurezza. Continua a imporre i controlli di accesso nel codice e a revisionare le modifiche sensibili. La stessa Cursor sconsiglia di affidarsi alle indicazioni per l'AI come unico controllo di sicurezza. Indicazioni sulle Team Rules

Verifica la configurazione con una modifica reale

Scegli un'attività piccola che in passato ha richiesto correzioni ripetute. Modificare la validazione di un modulo è un buon candidato: coinvolge un componente, cambia un comportamento e gestisce dati inseriti dall'utente.

1. Annota il risultato atteso. Indica il componente esistente da riutilizzare, il comportamento da testare e il punto in cui deve continuare a essere eseguita la validazione.
2. Salva i tre file e controllane lo stato. Cursor mostra le regole in Customize → Rules; in Agent è disponibile anche /create-rule. Come creare una regola
3. Richiedi la modifica includendo nel contesto i file pertinenti. Formula una richiesta realistica. Se ripeti già ogni regola nella richiesta, non puoi capire se la configurazione è stata utile.
4. Esamina il diff e le verifiche riportate. Cerca la convenzione applicata nel codice, non una semplice dichiarazione che le regole sono state rispettate. Se la checklist dei test è importante per questa prova, richiedi esplicitamente @tests.
5. Includi nel commit della modifica le regole utili. Offri al team una base da revisionare. Prima di aggiungere un altro file, migliora le frasi poco chiare.

Quando una convenzione non viene rispettata, distingui due casi: la regola non è arrivata nel contesto dell'attività, oppure è arrivata ma non ha funzionato. Nel primo caso occorre correggere il criterio di attivazione. Nel secondo serve un'istruzione più chiara, un esempio o un controllo automatico.

Quali convenzioni vale la pena conservare?

Parti dagli errori ricorrenti che costano di più al team. Ecco alcuni impieghi pratici da valutare, ordinati in base al lavoro di revisione che potrebbero evitare.

Questo elenco non è un invito a creare altri cinque file. Se un problema non si è mai presentato, lascialo fuori. Se un requisito si può verificare con precisione in modo automatico, preferisci quel controllo. Una regola utile colma uno spazio tra la richiesta dell'attività e gli strumenti già presenti nel repository.

Che cosa fare con il vecchio file .cursorrules?

Per la configurazione di progetto attualmente documentata, usa .cursor/rules/*.mdc. All'11 ottobre 2026, la pagina dedicata alle regole non menziona .cursorrules e quindi non conferma se il vecchio file funzioni ancora. Documentazione attuale

Se un repository contiene ancora il vecchio file, consiglio di trasferire le istruzioni utili in regole di progetto mirate, partendo dai tre file proposti sopra. Scegli come attivarle e verifica il risultato su un'attività reale prima di eliminare la vecchia copia. Non conservare convenzioni obsolete solo perché erano già state messe per iscritto.

Il rapporto con CLAUDE.md e AGENTS.md

L'idea comune è avere istruzioni permanenti per il progetto: Claude Code usa CLAUDE.md, mentre Codex legge gli accordi di lavoro in AGENTS.md. L'opzione in semplice Markdown di Cursor risponde alla stessa esigenza di base; i file .mdc permettono invece di scegliere quando attivare le regole. Mantieni coerenti le convenzioni, ma configura consapevolmente il caricamento delle istruzioni per ogni strumento: copiare il testo non equivale a copiare le impostazioni. Se il team usa più agenti, assegna a una persona la responsabilità delle convenzioni condivise, così che i file non diventino fonti in contrasto tra loro.

Due piccoli strumenti da sviluppare dopo la configurazione

Un verificatore delle regole del repository è l'opportunità più promettente per un responsabile tecnico: può controllare le estensioni dei file, i campi riconosciuti del frontmatter e i pattern che non corrispondono ad alcun file sotto controllo di versione. La versione minima utile è un report locale da generare durante la revisione. Il segnale di domanda è modesto: nella ricerca per questo articolo, DataForSEO ha restituito 140 ricerche mensili stimate per “cursor rules examples”. È un interesse per un tema vicino, non una prova che qualcuno sia disposto a pagare. Il limite è evidente: una regola formalmente valida può comunque dare indicazioni poco utili. Definizione della metrica

Un pacchetto per la revisione delle convenzioni del team potrebbe aiutare chi gestisce più repository. L'idea è trasformare i commenti ricorrenti nelle revisioni e gli esempi approvati in una proposta di modifica delle regole, indicando un revisore per ogni cambiamento. DataForSEO ha restituito 70 ricerche mensili stimate per “cursor team rules”. Parti da un'utilità interna: le Team Rules native gestiscono già la distribuzione, quindi un'altra dashboard in cui archiviare regole è un prodotto poco convincente. Il lavoro utile consiste nel decidere quali indicazioni meritino di diventare permanenti. Definizione della metrica

Domande frequenti sulla configurazione

La prossima settimana, scegli una correzione ricorrente, rendi precisa la regola corrispondente e provala sulla successiva pull request ordinaria. Se devi valutare il prodotto nel suo complesso, leggi la recensione di Cursor o le migliori alternative a Cursor.

Se vuoi integrare queste pratiche nel flusso di sviluppo del team, il servizio sistemi di AI in produzione è pensato per questo lavoro.