Prompt files, limites et feedback de Chat

4.13 Prompt files réutilisables ♻️

Définition

Les prompt files sont des prompts sauvegardés et réutilisables. Ils sont distincts des custom instructions : ils s’appliquent quand on choisit explicitement le workflow, plutôt que automatiquement à chaque interaction.

Ils permettent de standardiser des demandes fréquentes.

GitHub liste les prompt files parmi les fonctionnalités de personnalisation de Copilot.

Dans les IDE documentés, ils sont généralement stockés sous .github/prompts/*.prompt.md. La fonctionnalité est indiquée comme public preview et sa disponibilité dépend de l’IDE.

Différence entre instructions files et prompt files

Exemple d’instructions file

Always use Jest for unit tests.
Use strict TypeScript.
Avoid hardcoded secrets.

C’est général.

Exemple de prompt file

# Generate service tests

Generate unit tests for the selected service.

Requirements:
- Use Jest.
- Mock external dependencies.
- Cover success path.
- Cover invalid input.
- Cover dependency failure.
- Explain missing edge cases.

C’est une tâche réutilisable.

Exemples de prompt files utiles

Prompt file : security review

Review the selected code for security issues.

Focus on:
- authentication
- authorization
- input validation
- injection risks
- secrets
- error messages
- logging sensitive data

Return:
- risks found
- severity
- recommended fix

Prompt file : refactoring

Refactor the selected code.

Constraints:
- preserve behavior
- do not change public API
- improve readability
- reduce duplication
- avoid new dependencies
- suggest tests if behavior is unclear

Prompt file : test generation

Generate tests for the selected code.

Include:
- normal cases
- edge cases
- invalid inputs
- boundary values
- dependency failures
- expected exceptions

Pourquoi c’est utile ?

Les prompt files permettent :

• d’éviter de réécrire les mêmes prompts ;
• de standardiser les pratiques d’équipe ;
• de réduire les prompts vagues ;
• d’améliorer la qualité ;
• d’aider les nouveaux développeurs.

A team frequently asks Copilot to perform the same type of security review with the same checklist.
What should they use?

A reusable prompt file

4.14 Limites, feedback et commandes Copilot Chat ⚠️💬

Limites de Copilot Chat

Copilot Chat est puissant, mais il a des limites.

Il peut :

• mal comprendre le contexte ;
• halluciner ;
• ignorer une contrainte ;
• proposer une API inexistante ;
• générer du code vulnérable ;
• oublier des edge cases ;
• donner une réponse trop générale ;
• être influencé par un mauvais prompt.

Exemple d’hallucination

Prompt :

Use the latest AWS command to enable automatic quantum firewall protection.

Copilot pourrait inventer une commande.

Bonne réaction :

Vérifier dans la documentation officielle avant utilisation.

Exemple de mauvaise contrainte

Prompt :

Make this secure.

Trop vague.

Meilleur prompt :

Review this Express route for authentication, authorization, input validation, SQL injection, error handling, and sensitive logging.
Suggest specific fixes.

Feedback dans Copilot

Le feedback sert à améliorer l’expérience et signaler :

• réponse utile ;
• réponse incorrecte ;
• suggestion problématique ;
• résultat non pertinent.

Mais attention :

Donner du feedback ne valide pas le code.

Tu dois quand même relire et tester.

Commandes Copilot Chat

Copilot Chat peut proposer des commandes ou raccourcis selon l’environnement.

Exemples fréquents :

/explain
/tests
/fix
/doc
/help
/clear

GitHub indique que les slash commands permettent de gagner du temps pour les scénarios courants et que leur disponibilité peut varier selon l’environnement et le contexte.

Exemple /explain

/explain

Utile pour comprendre :

• regex ;
• fonction ;
• erreur ;
• bloc complexe ;
• requête SQL.

Exemple /tests

/tests

Utile pour générer des tests.

Mais tu peux améliorer :

/tests using pytest.
Include edge cases, invalid inputs, and exception cases.

Exemple /fix

/fix

Utile pour corriger rapidement une erreur locale.

Mais attention : la correction peut être superficielle.

Demande plutôt :

/fix this bug.
Preserve public behavior.
Explain the root cause and add a test.

Bonnes pratiques

Toujours :

• Donner un contexte clair
• Limiter le scope
• Demander une explication
• Demander les tests
• Vérifier les diffs
• Vérifier la sécurité
• Ne pas accepter aveuglément