Skills Cursor : le guide complet (liste, exemples, skills vs rules)

Cursor a des Agent Skills natifs depuis la version 2.4 (janvier 2026) : des capacités réutilisables que vous définissez dans un fichier SKILL.md, que l'agent découvre et applique quand elles sont pertinentes, ou que vous invoquez à la main. Si vous avez cherché « skills Cursor », c'est cette fonctionnalité que vous voulez — un dossier avec un SKILL.md qui apprend à Cursor un workflow précis. Ce guide couvre ce que sont les skills, où ils vivent, une liste d'exemples, et en quoi ils diffèrent des anciennes rules .mdc.

Ce qu'est un skill Cursor

Un skill est un dossier contenant un fichier SKILL.md — du Markdown avec un peu de frontmatter (un name et une description) suivi des instructions. À côté du SKILL.md, un skill peut embarquer un dossier scripts/, des references/ et des assets/ dont le workflow a besoin :

.cursor/skills/
└── deploy-web/
    ├── SKILL.md
    ├── scripts/
    │   └── deploy.sh
    └── references/
        └── REFERENCE.md

Cursor lit d'abord le name et la description, et ne charge les instructions complètes que quand le skill est réellement utilisé : une description nette est donc ce qui déclenche un skill au bon moment.

Où vivent les skills

Cursor charge les skills depuis des emplacements projet et globaux :

• Projet — .cursor/skills/ (ou .agents/skills/) à la racine du dépôt, et dans n'importe quel sous-dossier, où ils sont automatiquement cadrés à ce dossier.
• Global — ~/.cursor/skills/ (ou ~/.agents/skills/), disponibles dans tous les projets.

Par compatibilité, Cursor charge aussi les skills des dossiers Claude et Codex : un SKILL.md écrit pour un autre agent fonctionne ici sans modification.

Comment utiliser un skill

Deux façons, directement liées à la manière dont Cursor les découvre :

• Automatique — l'agent juge un skill pertinent à partir de votre tâche et l'applique de lui-même.
• Manuelle — tapez / dans le chat de l'agent et cherchez le skill par son nom pour l'invoquer directement.

Skills vs rules : la distinction qui compte

C'est la vraie question derrière la plupart des recherches « Cursor skills vs rules », et la réponse a changé en v2.4. Cursor a maintenant deux primitives distinctes :

• Les rules (fichiers .mdc dans .cursor/rules/) sont un contexte permanent et déclaratif. Idéales pour les conventions qui doivent orienter chaque réponse pertinente : TypeScript strict, exports nommés, aucun secret dans le code. On les attache via alwaysApply, un motif globs ou une description.
• Les skills (dossiers SKILL.md) sont dynamiques et procéduraux. Idéaux pour les workflows « comment faire » que l'agent charge seulement quand la tâche l'exige — déployer l'app, écrire une migration, dérouler la checklist de release — et ils peuvent porter scripts et fichiers de référence.

La formulation de Cursor : comparés aux rules déclaratives toujours actives, les skills conviennent mieux à la découverte dynamique de contexte et aux instructions procédurales. En pratique : les rules pour ce qui doit toujours être vrai, les skills pour une tâche nommée avec des étapes. Les deux se complètent, on ne choisit pas l'un contre l'autre.

Une liste de skills Cursor utiles

De bons candidats à empaqueter en skills :

• Déploiement — les étapes et scripts exacts pour livrer votre app, pour que l'agent arrête d'improviser.
• Procédure de migration — comment créer et appliquer une migration de base dans votre stack.
• Checklist de release — bump de version, changelog, tag, publication.
• Auteur de tests — vos conventions de test, avec un helper scripts/ pour lancer la suite.
• Revue de code — un workflow « relire ce diff pour bugs et failles » avec une description de déclenchement claire.
• Scaffold de composant — structure de fichiers, typage des props et style d'un nouveau composant.

Comme un skill n'est qu'un dossier, gardez-les dans .cursor/skills/ et committez-les pour que toute l'équipe ait le même comportement.

Écrire un skill que Cursor utilise vraiment

• Faites de la description un déclencheur, pas un titre. « Déployer l'app web en production » vaut mieux que « Aide au déploiement ». L'agent matche dessus.
• Gardez le corps prescriptif. Des étapes concrètes et le résultat attendu, pas des conseils vagues.
• Poussez le détail dans des fichiers. Longues procédures ou scripts vont dans scripts/ et references/, pour garder le SKILL.md lisible.
• Un skill, une tâche. Un skill qui veut tout faire est dur à déclencher et dur à suivre.

Créer votre premier skill

Prenez une tâche répétitive et empaquetez-la. Créez le dossier et le manifeste :

mkdir -p .cursor/skills/deploy-web

Mettez-y un SKILL.md avec un name, une description qui dit exactement quand il s'applique, et les étapes :

---
name: deploy-web
description: Builder et déployer l'app web en production
---

Pour déployer :
- Lancer la suite de tests ; arrêter si quelque chose échoue.
- Builder avec la config de production.
- Déployer, puis vérifier que le health check renvoie 200.

Demandez ensuite à Cursor de déployer — il devrait découvrir le skill depuis votre requête — ou invoquez-le avec / et le nom du skill. Committez le dossier pour le partager avec l'équipe.

Pour aller plus loin

Pour des idées prêtes à l'emploi plutôt que tout écrire à la main, parcourez notre sélection des meilleurs skills Cursor, ou le catalogue complet pour filtrer par tâche. Pour des workflows à empaqueter en skills — test, sécurité, refactoring — la catégorie développement est un bon point de départ.

Skills et rules ensemble donnent à Cursor une répartition claire : garde-fous permanents dans .cursor/rules/, workflows procéduraux nommés dans .cursor/skills/. Configurez les deux et l'agent arrête de deviner pour suivre votre playbook.