Guide de prompting pour Cursor AI

Lorsqu’une IA peut inspecter un dépôt, un meilleur prompt est généralement plus restreint, et non plus large. Donnez à Cursor les fichiers, les limites, les contraintes et la validation qui comptent, puis demandez-lui d’analyser la zone pertinente avant de la modifier.

Les outils conscients du dépôt peuvent révéler un contexte utile, mais ils peuvent aussi donner à une modification une apparence de certitude plus grande qu’elle ne l’est. L’objectif est de transformer l’accès au dépôt en preuves, et non en autorisation de modifier tous les fichiers liés.

La documentation actuelle de Cursor décrit des références de contexte pour le contenu du dépôt, par exemple les fichiers, les dossiers, les modifications git et les erreurs du linter. Utilisez les contrôles de contexte disponibles dans votre version afin d’orienter l’assistant vers le plus petit ensemble de preuves utile.

Par exemple, au lieu de ceci :

Corrige le dashboard lent.

écrivez :

Examine le délai de chargement du dashboard pour les utilisateurs connectés.

Périmètre : commence par la route du dashboard, son hook de chargement des
données et la carte qui affiche trop longtemps un squelette de chargement.
Utilise le provider de profil actuel et l’instrumentation de performance
existante comme contexte.

Résultat : détermine si le délai vient du temps de récupération, d’un rendu
inutile ou d’une transition d’état. Propose la plus petite amélioration mesurable.

Contraintes : préserve le comportement d’autorisation, l’interface localisée et
le retour de chargement existant. N’ajoute pas de cache ni de nouvelle
bibliothèque d’état sans preuves.

Avant de modifier, résume le chemin d’exécution et indique ce que tu mesurerais.

Le prompt donne à l’assistant une voie d’entrée dans le dépôt sans considérer que chaque fichier du dashboard peut être modifié.

Le contexte du dépôt a le plus de valeur au début d’une tâche. Demandez à Cursor de :

1. suivre le flux de données ou de contrôle pertinent ;
2. identifier le code responsable du comportement ;
3. distinguer les faits confirmés des hypothèses ;
4. lister les plus petits fichiers susceptibles de changer ;
5. expliquer quel test ou quelle observation prouvera le correctif.

C’est particulièrement important lorsque la demande concerne un provider partagé, un composant global, l’authentification, les paiements ou la navigation. Ces zones ont souvent des sites d’appel qu’une modification locale ne peut pas ignorer en toute sécurité.

« Mets à jour la fonctionnalité de notifications » reste trop large si elle couvre l’interface, la persistance, les workers et les paramètres. Ajoutez une contrainte de fichier ou de limite :

Modifie uniquement le formulaire de préférences de notifications. Le rédacteur
client est la source de vérité des mises à jour de préférences ; n’ajoute pas
un autre rédacteur et ne modifie pas le planificateur dans cette tâche.

Inspecte le formulaire, le rédacteur client typé et leurs tests directs. Si le
bug signalé nécessite une modification du backend, arrête-toi et explique les
preuves au lieu d’élargir le périmètre.

Cela n’empêche pas l’assistant de trouver un véritable problème entre plusieurs limites. Cela rend l’élargissement explicite et vérifiable.

Le contexte récurrent du projet doit figurer dans les instructions ou règles du dépôt, pas dans chaque prompt de discussion. Utilisez des consignes de projet pérennes pour les invariants tels que :

• les limites d’exportation statique ou de déploiement ;
• les exigences de locale ;
• les commandes de test et le style de code ;
• les règles de propriété de l’état partagé ;
• les chemins nécessitant une revue particulière.

Gardez le prompt de tâche centré sur le problème précis et les critères d’acceptation. Si les instructions du projet et le prompt divergent, résolvez le conflit dans la demande au lieu d’espérer que l’assistant devine lequel est prioritaire.

Les demandes importantes sont difficiles à valider, car un diff étendu masque les liens de cause à effet. Découpez le travail en points de contrôle :

Inspecte et explique d’abord le chemin actuel de soumission du formulaire. Ne
modifie aucun fichier.

Après l’analyse, implémente uniquement le correctif de l’état de validation et
ajoute son test ciblé. Ne refactorise pas encore les composants de formulaire
voisins.

Exécute le test pertinent et résume le diff. S’il passe, propose un suivi séparé
pour le nettoyage partagé.

Ce schéma facilite l’examen du travail de l’assistant et rend un retour arrière pratique si l’hypothèse était erronée.

Un assistant de programmation IA ne doit pas choisir « cela semble correct » comme règle d’achèvement :

Critères d’acceptation :
- le comportement existant fonctionne toujours lors d’une soumission réussie ;
- l’état non valide signalé devient atteignable et visible ;
- le retour au clavier et au lecteur d’écran reste intact ;
- le test ciblé passe et un échec aurait détecté l’ancien bug.

Validation : exécute la suite de tests ciblée, la vérification de types et
décris toute étape manuelle dans le navigateur qui couvre un comportement que
le test ne peut pas observer.

Demandez-lui d’identifier un test manquant plutôt que d’inventer de la confiance à partir d’un résultat de compilation vert.

Tâche : [Objectif d’ingénierie en une phrase.]

Contexte du dépôt : [Fichiers, dossier, diff, erreur ou règle existante pertinents.]
Problème : [Comportement observé et personnes concernées.]
Périmètre : [Fichiers ou limite à inspecter en premier.]
Résultat souhaité : [Résultat observable pour l’utilisateur ou le système.]
Contraintes : [Comportement, compatibilité, architecture et éléments hors objectif.]
Critères d’acceptation : [Résultats requis.]
Validation : [Tests ciblés, vérification de types, contrôle manuel, mesure.]

Analyse d’abord. Indique le propriétaire actuel du comportement, remets en
question toute hypothèse fragile et propose la plus petite modification sûre
avant de modifier.

Utilisez le cadre de raisonnement plus général dans comment écrire de meilleurs prompts d’IA et consultez l’ingénierie des prompts pour les développeurs pour des modèles par type de tâche. Pour une modification surtout structurelle, utilisez ces modèles de prompts pour refactoriser du code.

Si une tâche de dépôt implique des scripts ou une sortie de terminal, confirmez le comportement réel de la commande avant de le modifier. Exercez-vous aux flux de travail en ligne de commande dans le navigateur pour transformer une sortie supposée en cas de test observable.