Bonnes pratiques de prompting avec GitHub Copilot

GitHub Copilot apporte une aide au code plus utile lorsque la description de la tâche explique le problème, le périmètre, les contraintes et la preuve de réussite. Un prompt court peut suffire pour une complétion de code locale. Une modification du dépôt requiert la même clarté qu’une issue bien rédigée.

La surface du produit compte : la documentation actuelle de GitHub décrit des instructions à l’échelle du dépôt, des instructions propres à un chemin, des instructions d’agent et des fichiers de prompts réutilisables, avec une prise en charge qui varie selon la fonctionnalité et l’IDE. Utilisez les outils disponibles dans votre environnement, mais gardez la demande sous-jacente explicite.

Donnez un contrat local à la complétion de code

Pour une petite fonction, le nom, les types et les tests environnants suffisent souvent. Ajoutez le comportement qui risque d’être subtilement erroné :

Implémente un analyseur pour l’en-tête retry-after.

Renvoie des millisecondes pour des secondes ou une date HTTP valide. Renvoie null
pour une valeur manquante, négative ou non valide. Ne lève pas d’exception depuis
un chemin d’erreur de réponse. Ajoute des tests tabulaires pour des secondes, une
date future, une date passée et une entrée mal formée.

Le contrat oriente la complétion sans exiger un long briefing d’architecture.

Décrivez le travail de test comme un comportement

Évitez :

Écris des tests pour le hook de préférences.

Utilisez :

Ajoute des tests pour le hook de préférences en suivant les conventions de test
existantes.

Vérifie que l’état de chargement initial ne redirige pas, qu’une lecture réussie
expose les préférences enregistrées, qu’une mise à jour écrit l’objet de
préférences complet de manière atomique et qu’une mise à jour échouée conserve la
valeur visible précédente.

Utilise le comportement public plutôt que le nombre d’appels de fonctions
internes. Inclus la régression qui échouerait avec le bug signalé.

L’assistant dispose maintenant d’un contrat visible par l’utilisateur, y compris un cas négatif important.

Donnez aux prompts de refactorisation des règles de préservation du comportement

Les suggestions de code peuvent créer une abstraction locale soignée tout en supprimant un détail public. Indiquez ce qu’il faut préserver dans la demande :

Extrais la présentation d’état répétée de ces deux cartes.

Préserve les props actuelles, les libellés visibles, les noms d’événements
d’analytique, le focus clavier et la mise en page mobile. Limite les modifications
à cette fonctionnalité et à ses tests directs.

Avant de modifier, liste le comportement répété et les différences qui doivent
rester séparées. N’en fais pas un composant partagé de design system, sauf si le
composant existant ne peut pas représenter le résultat.

Si vous ne pouvez pas nommer le comportement à préserver, demandez d’abord à Copilot d’expliquer le contrat actuel et les sites d’appel.

Déboguez avec des symptômes et des preuves

Symptôme : la page de recherche affiche des résultats obsolètes après qu’un
utilisateur a modifié les filtres.

Attendu : la sélection de filtre la plus récente contrôle les résultats affichés.
Observé : une requête précédente plus lente peut écraser une réponse plus récente.

Code pertinent : l’interface de filtre, le hook de requête et le moteur de rendu
des résultats. Modification récente : des nouvelles tentatives de requête ont été
ajoutées.

Commence par décrire le cycle de vie de la requête et les hypothèses concurrentes.
Indique quels journaux ou quel minutage de test prouveraient chacune d’elles.
Propose ensuite le plus petit correctif et la couverture de régression. Ne
remplace pas la couche de données sans preuves.

Cela empêche une réponse générique « corrige la condition de concurrence » de se transformer en migration inutile de la gestion d’état.

Utilisez les instructions du dépôt pour le contexte stable

Les règles stables doivent vivre avec le projet, lorsque cela est pris en charge :

la façon d’exécuter les tests et le formatage ;
les contraintes de déploiement ;
les locales ou plateformes prises en charge ;
les API publiques qui doivent rester compatibles ;
les chemins où les revues de sécurité ou d’accessibilité sont importantes.

La documentation de GitHub décrit des instructions personnalisées au niveau du dépôt ainsi que des fichiers d’instructions plus ciblés. Gardez ces instructions courtes, exactes et limitées aux conventions pérennes. Placez les détails de l’issue en cours — symptômes, résultat et critères d’acceptation — dans le prompt lui-même.

Demandez une documentation ancrée dans le code

Mets à jour le guide de dépannage du déploiement après la nouvelle vérification
d’environnement.

Vérifie chaque commande et chaque variable d’environnement par rapport au dépôt.
Explique le signal de réussite, le signal d’échec courant et la prochaine action
sûre. N’inclus pas de secrets dans les exemples. Ajoute des liens vers le runbook
opérationnel existant au lieu de le dupliquer.

La formule « vérifie par rapport au dépôt » compte. Elle indique à Copilot que rédiger une documentation exacte est une tâche de lecture du code, pas de génération de prose.

Terminez chaque prompt important par des critères d’acceptation

Utilisez une ligne d’arrivée qu’une autre personne peut examiner :

Terminé signifie :
- le comportement utilisateur signalé change comme décrit ;
- le comportement protégé reste inchangé ;
- des tests ciblés prouvent les nouveaux et les anciens chemins ;
- la vérification de types et la commande de lint pertinente passent ;
- le diff ne contient aucun nettoyage sans rapport.

Pour la structure générale d’un prompt, lisez comment écrire de meilleurs prompts d’IA. Pour des modèles propres à chaque tâche, poursuivez avec l’ingénierie des prompts pour les développeurs, puis évitez les modes d’échec présentés dans les erreurs des assistants de programmation IA et comment les éviter.

Lorsqu’une tâche de programmation comprend des scripts, une sortie de commande ou une reproduction dans le terminal, validez-la plutôt que de la décrire de mémoire. Exercez-vous au flux de travail en ligne de commande dans votre navigateur avant de le transformer en prompt ou en test.