Commandes, références et contexte

3.5 Slash commands

Définition

Les slash commands sont des commandes rapides dans Copilot Chat.

Tu tapes / puis une commande. Elles évitent d’écrire de longs prompts pour des actions fréquentes. GitHub précise que les slash commands permettent d’éviter des prompts complexes pour des scénarios courants, et que les commandes disponibles peuvent varier selon l’environnement et le contexte.

Exemples fréquents

Selon ton IDE et les extensions disponibles, tu peux avoir des commandes comme :

/explain

/fix

/tests

/doc

/help

/clear

Exemple /explain

Tu sélectionnes :

^[^\s@]+@[^\s@]+\.[^\s@]+$

Tu demandes :

/explain

Copilot peut expliquer :

This regular expression checks whether a string has a basic email-like format:
- characters before @
- characters after @
- a dot followed by a domain part

Exemple /tests

Tu sélectionnes une fonction :

export function calculateTax(price: number, rate: number): number {
  return price * rate;
}

Tu demandes :

/tests

Copilot peut générer :

describe("calculateTax", () => {
  it("calculates tax for a valid price and rate", () => {
    expect(calculateTax(100, 0.2)).toBe(20);
  });

  it("returns 0 when price is 0", () => {
    expect(calculateTax(0, 0.2)).toBe(0);
  });
});

Mais tu peux améliorer avec un prompt plus précis :

/tests using Jest. Include negative values, zero rate, decimal precision, and invalid business cases.

Exemple /fix

Tu as ce code :

def average(numbers):
    return sum(numbers) / len(numbers)

Problème : si numbers est vide, il y a une division par zéro.

Tu demandes :

/fix

Copilot peut proposer :

def average(numbers):
    if not numbers:
        return 0
    return sum(numbers) / len(numbers)

Mais attention : retourner 0 est un choix métier. Peut-être qu’il faudrait lever une exception :

def average(numbers):
    if not numbers:
        raise ValueError("numbers must not be empty")
    return sum(numbers) / len(numbers)

3.6 Référencer des fichiers et du contexte

Définition

Référencer le contexte signifie donner à Copilot les éléments nécessaires pour répondre correctement.

Le contexte peut être :

• le fichier courant ;
• une sélection de code ;
• un autre fichier ;
• une erreur ;
• une stack trace ;
• un test existant ;
• un README ;
• un fichier de configuration ;
• une convention du projet ;
• une règle métier ;
• un ticket ou une issue selon l’environnement.

Pourquoi le contexte est important ?

Copilot n’est pas omniscient.

Si tu demandes :

Fix the bug.

C’est trop vague.

Si tu demandes :

Fix the bug in the selected function.
The expected behavior is to return an empty list when the input is None.
Keep the public API unchanged.

Là, c’est beaucoup mieux.

Exemple sans contexte

Generate a repository class.

Copilot peut partir dans n’importe quelle direction :

• SQLAlchemy ;
• TypeORM ;
• Spring Data ;
• MongoDB ;
• DynamoDB ;
• pattern maison ;
• repository générique inutile.

Exemple avec contexte

Generate a TypeScript repository class for the User entity.
Use Prisma.
Follow the same structure as OrderRepository.ts.
Include methods: findById, findByEmail, create, and deactivate.
Do not expose passwordHash in returned objects.

Là, tu guides Copilot.

Exemple avec fichier de référence

Prompt :

Use the style of PaymentService.ts to create a similar service for RefundService.
Follow the same error handling and logging conventions.

Pourquoi c’est puissant ?

Parce que Copilot peut s’aligner sur :

• naming ;
• structure ;
• gestion d’erreur ;
• logs ;
• dépendances ;
• conventions de ton projet.

Exemple avec stack trace

Erreur :

TypeError: Cannot read properties of undefined (reading 'items')

Prompt :

Analyze this stack trace and the selected function.
Explain why this error happens and propose a defensive fix without hiding real data quality issues.

Bonne demande, parce qu’elle précise :

• analyse ;
• cause ;
• correction ;
• contrainte métier.

Bonnes pratiques de contexte

Donne à Copilot :

• le langage ;
• le framework ;
• le fichier concerné ;
• l’objectif ;
• les contraintes ;
• les exemples ;
• les erreurs ;
• les tests existants ;
• ce qu’il ne faut pas changer.

Mauvais prompt

Refactor this.

Bon prompt

Refactor the selected function to improve readability.
Do not change the public function signature.
Preserve the current behavior.
Add early returns where useful.
Do not introduce new dependencies.