Prompts Copilot

J'ai une table sur cette feuille. Analysez-la et aidez-moi à agir sur elle.

Les données sont : [DESCRIBE THE COLUMNS, e.g. "Column A date, B region, C revenue, D units"]
Ce que je veux comprendre : [YOUR QUESTION, e.g. "which region is growing fastest and where revenue per unit is dropping"]

Faites quatre choses :
1. Résumez les 3 tendances principales en langage simple, chacune avec le nombre qui le soutient.
2. Ajoutez une nouvelle colonne qui calcule [METRIC, e.g. "revenue per unit"] et expliquez la formule en une ligne.
3. Signalez toute ligne qui ressemble à une erreur ou à une valeur aberrante.
4. Suggérez un graphique qui montrerait la tendance principale et les colonnes à utiliser.

Résumez ce fil d'email et rédigez ma réponse.

Résumé d'abord : ce qui a été décidé, ce qui est toujours ouvert, qui attend qui, et toutes les dates mentionnées — 5 puces max.

Alors rédigez une réponse de ma part (, ) que : [WHAT MY REPLY NEEDS TO DO, e.g. "confirm the Thursday deadline and ask Marcus for the credentials"].

Gardez la réponse sous 120 mots, direct, pas de remplissage. N'inventez pas de faits qui ne sont pas dans le fil.

Rédigez un [DOCUMENT TYPE, e.g. "one-page project brief"] à partir des notes ci-dessous.

Public : 
Ton : [e.g. "plain, confident, no jargon"]
Longueur : environ  mots.

Structurez-le avec des en-têtes clairs. Où mes notes sont minces, laissez un [bracketed placeholder] plutôt que d'inventer des détails. Terminez avec une brève section « Questions ouvertes » listant tout ce que je dois encore décider.

Mes notes :

Créez une présentation à partir de .

Public : 
Longueur :  diapositives, plus une diapositive de titre et une diapositive de fermeture.
Objet de la conversation : .

Pour chaque diapositive, donnez-moi : un titre court, 3 points max, et une note de présentateur d'une ligne. Gardez les puces à des phrases, pas des phrases. Ne mettez pas plus d'une idée sur une diapositive.

J'ai manqué cette réunion. Rattrapez-moi en utilisant la transcription et l'enregistrement.

Donnez-moi :
1. Un résumé de 3 phrases : sujet, décision principale, plus grande question ouverte.
2. Éléments d'action sous forme de tableau — Propriétaire | Tâche | Échéance (utilisez « TBD » si aucune date n'a été dite).
3. Tout ce qui a été dit à propos de [MY NAME or MY TEAM, e.g. "the data team" or "the migration"] spécifiquement.
4. Une chose qui a été débattue mais non résolue.

N'inventer pas les propriétaires ou les dates qui n'ont pas été mentionnés.

Expliquez le code sélectionné à quelqu'un qui connaît la syntaxe basique mais pas ce codebase.

1. Ce qu'il fait, en une phrase.
2. Une guide à travers chaque bloc logique et pourquoi c'est là.
3. La partie qu'un nouveau venu est plus susceptible de mal lire.
4. Les effets secondaires, les cas limites ou les modes d'échec.

N'assumez pas que je connais le framework — sortir les appels non-évidents.

Code :

Écrivez des tests unitaires pour la fonction sélectionnée en utilisant [TEST FRAMEWORK, e.g. "Jest" / "pytest" / "JUnit"].

Couverture :
- Le chemin normal/heureux.
- Cas limites (entrée vide, zéro, valeurs max).
- Entrée invalide et l'erreur qu'elle doit lever.
- Un cas limites réaliste spécifique à ce que fait cette fonction.

Utilisez des noms de tests clairs qui décrivent le comportement, pas « test1 ». Ajoutez un commentaire d'une ligne sur toute affirmation non-évidente.

Fonction :

Refactorisez la fonction sélectionnée pour la lisibilité et la maintenabilité sans modifier son comportement.

Règles :
- Gardez les mêmes entrées, sorties et effets secondaires.
- Préférez les noms clairs et les retours précoces à la nidification profonde.
- N'ajoutez pas de dépendance nouvelle à moins que vous n'expliquiez pourquoi c'est en valeur.

Donnez-moi : le code refactorisé, puis une brève liste à puces de ce que vous avez changé et pourquoi. Si vous apercevez un bug probable tout en refactorant, signalez-le séparément — ne « réparez » pas silencieusement.

Code :

Je reçois cette erreur. Aidez-moi à la corriger correctement.

Erreur :


Code pertinent :


Ce que j'essayais de faire : 

Dites-moi : (1) la cause profonde en langage simple, (2) la correction spécifique avec le code corrigé, (3) pourquoi c'est arrivé pour que j'évite la prochaine fois, et (4) une chose à vérifier au cas où il y aurait un problème plus profond. Ne supprimez pas simplement l'erreur.

Rédigez un message de commit et une brève description PR pour les changements mis en scène.

Message de commit : utilisez Conventional Commits (par ex. feat :, fix :, refactor :). Une ligne de sujet concise sous 72 caractères, puis un corps expliquant le « pourquoi », pas le « quoi ».

Description PR : 2-3 phrases de ce qui a changé et pourquoi, une liste à puces des changements clés, et une ligne « Comment tester ».

Ne réinsérez pas la diff ligne par ligne — résumez l'intention. Contexte : .