Prompts

Traduisez le texte ci-dessous en français clair. Conservez les termes, le code et les noms propres. Donnez d’abord la traduction, puis listez trois changements et dites pourquoi. Marquez ce qui est incertain. N’inventez rien. {texte}

Vous êtes l’intervieweur, pour le poste {poste}. Une seule question à la fois. Après ma réponse, indiquez les points que j’ai omis, puis posez la question suivante. Au bout de 8 questions, donnez un avis court pour ce poste : admis, en attente, ou refusé, avec les raisons.

Relisez le changement ci-dessous. Ne listez que les problèmes qui le rendent faux, lent ou difficile à maintenir. Pour chacun, donnez le fichier, la gravité (haute, moyenne, basse) et la correction. Ne réécrivez pas le fichier entier. S’il n’y a pas de problème, écrivez qu’il n’y en a pas.

Transformez les notes en vrac ci-dessous en rapport de la semaine. Trois parties : fait cette semaine, non fait et pourquoi, trois choses pour la semaine prochaine. Une phrase par point. Gardez les chiffres. N’en faites pas une autoévaluation.

À partir des noms de colonnes ci-dessous, écrivez une formule Excel pour accomplir : {tâche}. Donnez d’abord la formule, puis calculez le résultat sur deux lignes d’exemple. Si une autre colonne doit être touchée, dites-le d’abord. N’utilisez pas une colonne que je n’ai pas donnée.

Répondez en SQL standard : {question}. La structure des tables est ci-dessous. Écrivez d’abord la requête, puis dites de quelles tables elle dépend. N’inventez pas de colonnes qui n’existent pas. Si la question est floue, posez-moi une question avant d’écrire le SQL.

Écrivez une expression régulière JavaScript. À faire correspondre : {aCorrespondre}. À ne pas faire correspondre : {aNePasCorrespondre}. Donnez l’expression, puis deux exemples qui passent et deux qui échouent.

Expliquez le code ci-dessous à quelqu’un qui vient de prendre le dépôt. D’abord trois phrases sur ce qu’il fait, puis l’ordre d’exécution. Indiquez les entrées, les sorties et les cas d’échec. Ne modifiez pas le code.

Écrivez un message de commit à partir du diff ci-dessous. La première ligne ne dépasse pas 72 caractères et dit ce qui a changé. Après une ligne vide, dites pourquoi. N’écrivez pas des formules vides comme « update » ou « fix bug ».

Faites cette modification : {tâche}. Ne touchez que les lignes indispensables pour la mener. Ne reformatez pas au passage, ne renommez pas et ne réécrivez pas le code voisin. À la fin, indiquez les fichiers touchés et comment vérifier que le comportement n’a pas changé.

Le défaut est : {symptôme}. Écrivez d’abord les étapes ou le test qui le reproduisent. Avant la reproduction, ne modifiez pas le code du produit. Ensuite, faites la plus petite modification, et dites pourquoi c’est bien la cause.

Pour {comportement}, écrivez d’abord un test qui échoue. Montrez la sortie d’échec, puis écrivez l’implémentation qui le fait passer. Ne commencez pas par l’implémentation. Une fois le test passé, n’ajoutez pas une fonction qui n’était pas demandée.

Lisez d’abord les fichiers liés à {tâche}. Listez les faits que vous voyez et ce qui reste incertain. Ne modifiez aucun fichier à cette étape. Ne modifiez qu’après ma confirmation.

N’écrivez pas de code pour l’instant. Pour {objectif}, donnez un plan court : les fichiers à modifier, ce que vous ne ferez pas, et comment savoir que c’est fini. Si deux approches sont également raisonnables, arrêtez-vous et demandez laquelle je choisis.

Lisez le diff ci-dessous et ne cherchez que les problèmes de sécurité : injection, dépassement de droits, secret entré dans le dépôt, désérialisation non sûre. Pour chacun, donnez le fichier et la façon de le déclencher. S’il n’y en a pas, écrivez qu’il n’y en a pas. Pas de commentaire de style hors sujet.

Écrivez 5 title et 5 meta description pour cette page. Le sujet est : {sujet}. Chaque title ne dépasse pas 60 caractères, chaque description ne dépasse pas 160 caractères. Chacun doit contenir des mots qu’une personne chercherait. Ne bourrez pas de mots-clés.

Écrivez le premier écran pour {produit} : un résultat, un texte d’au plus 40 caractères, et un bouton. Le bouton doit dire ce que le clic ouvre. Pas de slogan, pas trois arguments côte à côte.

Réécrivez le texte ci-dessous pour qu’il parle à une personne précise. Retirez les phrases vides et les parallélismes. Conservez tous les faits, les chiffres et les chemins de fichiers. À la fin, listez les formules toutes faites que vous avez retirées.

Écrivez 10 titres pour l’article ci-dessous. Cinq disent directement le résultat, cinq portent un détail concret. N’employez pas « choc », « ultime » ni « autonomiser ». Chaque titre ne dépasse pas 22 caractères.

Écrivez 3 courtes publicités pour {produit}. Chacune vise un acheteur et une seule chose. Dites qui est l’acheteur, quel est son problème actuel, et ce que le clic lui apporte. N’empilez pas les adjectifs.

Écrivez une note Xiaohongshu sur {sujet}. La première ligne est le titre. Le corps ne dépasse pas 300 caractères. Incluez un détail concret que vous avez réellement utilisé. Terminez par une question. N’utilisez pas « 家人们 » ni « 绝绝子 ». Indiquez 3 images qui iraient avec.

Répondez à l’e-mail ci-dessous. La première phrase répond à la demande. Ensuite, dites ce que vous attendez de l’autre. Puis donnez un moment. Ton direct. N’ouvrez pas par « J’espère que cet e-mail vous trouve bien ».

Transformez le relevé de réunion ci-dessous en compte rendu. Ne gardez que les décisions, les responsables, les dates limites et les questions ouvertes. Retirez la discussion. Signalez à part les points sans responsable.

Le poste visé est {poste}. Transformez l’expérience ci-dessous en 5 points de CV. Chaque point commence par un verbe et contient un chiffre ou un livrable. Retirez ce qui n’a pas de lien avec le poste. N’inventez pas une expérience que je n’ai pas écrite.

Les exigences du poste sont au-dessus, le dossier du candidat est en dessous. Listez les exigences remplies, celles qui ne le sont pas, et celles que le dossier ne mentionne pas. Ne supposez rien du caractère. Terminez par un avis, entretien ou non, avec les raisons.

Établissez 3 jours à {ville}. Chaque jour, une chose le matin, une l’après-midi et une le soir, et comment aller de l’une à l’autre. Marquez les lieux qui exigent une réservation. N’ajoutez pas de lieu de shopping que je n’ai pas demandé. Le budget est {budget}.

Écrivez une nouvelle d’au plus 800 caractères à partir de ce cadre : {cadre}. Un personnage principal, une chose à accomplir, et un changement à la fin. Pas de chapitres. Pas de morale.

Transformez l’intrigue ci-dessous en une scène : {intrigue}. N’écrivez que le titre de scène, l’action et les répliques. Les répliques doivent pouvoir se dire. Pas de termes de caméra. Pas de pensées intérieures.

Le sujet du débat est : {thèse}. Donnez d’abord les trois points les plus forts pour, puis les trois points les plus forts contre. Chaque point tient en une phrase, plus le fait dont il dépend. À la fin, ne déclarez pas de gagnant.

Apprenez-moi {sujet}. Expliquez d’abord l’essentiel avec un exemple concret, puis posez-moi deux questions. Ne passez pas à la section suivante avant que j’aie répondu. Si je me trompe, n’indiquez que l’étape qui est fausse.

Je veux comprendre {question}. Ne donnez pas la réponse directement. Posez une seule question à la fois, une question qui réduit le champ. Attendez ma réponse avant la suivante. N’expliquez que lorsque je dis clairement « donnez la réponse ».

Lisez l’article ci-dessous. Résumez-le en 8 phrases : problème, méthode, données, résultat, et limites que les auteurs ont écrites eux-mêmes. Après chaque phrase, indiquez entre parenthèses la section d’où elle vient. N’ajoutez pas ce que l’article ne dit pas.

Comparez {optionA} et {optionB} pour réaliser {objectif}. Faites un tableau : coût, ce qu’il faut modifier, ce qui se passe en cas d’échec. Chaque case a une raison. Si la raison ne suffit pas, écrivez « inconnu ». Ne devinez pas.

Regardez l’interface ci-dessous. Ne commentez que la hiérarchie, l’espacement, la zone cliquable et l’état de focus. Listez trois changements. Pour chacun, dites le problème actuel et l’aspect une fois corrigé. Ne changez pas l’ensemble du style visuel.

Écrivez un prompt d’image pour {sujet}. Précisez ce qu’il y a dans le cadre, la lumière, la composition, et ce qui ne doit pas apparaître. Un seul paragraphe, pas un tas de mots-clés. Deux versions : une image carrée et une image en largeur.

Proposez 12 noms pour {produit}. Chaque nom doit pouvoir servir de domaine : court, prononçable, sans trait d’union. Évitez les mots génériques déjà usés. Après chaque nom, une phrase sur ce qu’il désigne.

Je veux dire : {phrase}. Donnez d’abord une formulation plus naturelle, puis indiquez mon problème d’origine (mot, ordre ou ton). Ensuite, donnez une version plus courte que je puisse répéter.

Je dois accomplir ceci sur {système} : {tâche}. Listez les commandes à exécuter, une par ligne, et dites ce que chacune change. Ne faites pas semblant d’être le terminal. Pour une commande destructrice, arrêtez-vous et demandez-moi d’abord.

Lisez le JavaScript ci-dessous. Dans l’ordre d’exécution, listez ce que chaque console affiche. S’il y a une exception, donnez le type d’erreur et la ligne. Ne modifiez pas le code, sauf si je vous demande ensuite de le corriger.

Découpez {système} en modules. Pour chaque module, écrivez ce qu’il prend en charge, ce qu’il ne prend pas en charge, et une interface qu’il expose. Pas plus de 6 modules. N’écrivez pas le code d’implémentation.

Lisez le document ci-dessous. Faites un résumé d’au plus 40 caractères. Puis listez les idées que le texte énonce vraiment, 8 au plus. Ne citez une phrase que si elle figure dans le texte, 5 citations au plus. Terminez par un apport. Si une rubrique n’a rien, écrivez « aucun ». N’inventez pas de citations. {document}

Lisez le git diff ci-dessous et écrivez en Markdown une description de demande de fusion, avec ces sections : Résumé, Fichiers modifiés, Raison, Impact, Plan de test. Pour chaque fichier, dites ce qui a changé. Si le diff ne montre pas de test, écrivez que le plan de test manque. Ne réécrivez pas le code.

Lisez le journal ci-dessous. Listez les anomalies et les problèmes qui reviennent. Pour chacun, donnez la ligne ou l’heure qui le soutient. Puis n’écrivez que les corrections que le journal lui-même permet. Si la cause n’est pas dans le journal, dites-le. Ne corrigez pas à partir d’une supposition hors du fichier.

Transformez cette note de produit en PRD Markdown, avec ces sections : Vue d’ensemble, Objectifs, Public, Fonctions, Exigences fonctionnelles, Exigences non fonctionnelles, Indicateurs de succès. Chaque exigence doit pouvoir être vérifiée. Si un fait manque, écrivez « inconnu ». N’ajoutez pas de fonction absente de la note. {note}

Écrivez un seul récit utilisateur pour {fonction}. Sur trois lignes : En tant que {rôle} / Je veux / Afin de. Puis listez en puces simples les critères d’acceptation qu’un test peut vérifier. N’en écrivez pas un second. N’écrivez pas de critère que la note ne soutient pas. {note}

Écrivez une note de conception pour {système}. Sections : objectif métier, contexte, conteneurs, déploiement, risques, questions et hypothèses. Contexte, conteneurs et déploiement ont chacun un diagramme mermaid et un tableau : nom, type, responsabilité. Pour la sécurité, n’écrivez que les contrôles déjà indiqués dans la description. S’il n’y en a pas, écrivez « non indiqué ». N’écrivez pas comment attaquer ce système. {description}

Lisez le plan Terraform ci-dessous. En une phrase, dites ce qui va changer. Puis listez les créations, mises à jour et destructions importantes. Ne listez un changement de coût ou d’accès que si le texte du plan l’indique. S’il n’y a pas de coût, écrivez « coût non indiqué ». N’inventez pas de prix et n’écrivez pas d’étapes d’attaque.

Lisez le diff ci-dessous. La première ligne ne dépasse pas 100 caractères, est au présent, et porte l’un de ces préfixes : feat, fix, docs, refactor, test, chore. Puis 6 puces au plus. Chaque puce est une courte phrase au présent sur un changement de comportement. Sautez les fichiers qui ne modifient que des blancs.

Lisez l’argument ci-dessous. Pour chaque étape qui ne tient pas, nommez en langage clair de quelle erreur il s’agit, citez la phrase, et dites pourquoi cette étape ne prouve pas la conclusion. Une étape qui ne tient pas ne rend pas la conclusion fausse. Si l’argument tient, écrivez qu’il tient. Ne listez pas une erreur absente du texte.

Réécrivez le prompt ci-dessous pour qu’un modèle puisse le suivre. La tâche reste la même. Ajoutez la forme de la sortie, la longueur, ce qu’il ne faut pas écrire, et un emplacement pour l’entrée. Placez l’entrée dans une zone clairement marquée. N’ajoutez pas de rôle. Ne renvoyez que le prompt réécrit. {prompt}

Écrivez un rapport de défaut pour {symptôme}. Champs : titre, environnement, étapes, attendu, constaté, gravité. Le titre nomme le composant, l’action et le symptôme. Les étapes sont numérotées et aussi courtes que possible. La gravité est critique, haute, moyenne ou basse, avec l’effet sur la personne qui l’utilise. Pour un champ que je n’ai pas donné, écrivez « inconnu ». Ne proposez pas de correction de code.

Écrivez un plan de test pour {comportement}, en trois groupes : unitaire, intégration, bout en bout. Chaque cas est une phrase de la forme « donné / quand / alors », et ne vérifie qu’une chose. Placez la plupart des cas dans le groupe unitaire. Au plus 2 cas de bout en bout, et seulement pour un chemin qu’une personne emprunte. N’écrivez pas le code de test. N’utilisez pas d’attente fixe.

Transformez {fonction} en exigences qu’un test peut vérifier. Chaque ligne utilise l’une de ces formes : quand [événement], le système doit [comportement] ; pendant [état], le système doit [comportement] ; si [situation non voulue], le système doit [réponse]. Puis listez les limites que la description ne couvre pas encore, et marquez chacune « proposé ». N’écrivez pas de conception, et n’écrivez pas de code.

Notez une décision au sujet de {choix}. Sections : Décision, Contexte, Options, Raisons, Impact, Quand le revoir. N’écrivez que les options que j’ai nommées. Si je n’en ai donné qu’une, écrivez que les autres options ne sont pas fournies. Les raisons doivent exposer le compromis. Quand le revoir doit dire ce qui ferait rouvrir cette décision. N’inventez pas d’indicateur.

Lisez le diff ci-dessous. Ne listez que les documents qu’un lecteur doit mettre à jour : README, journal des changements, description d’API, exemple de configuration ou note de migration. Pour chacun, donnez la section et le fait du diff qui le rend périmé. Si le diff n’a aucun changement qu’un utilisateur peut remarquer, écrivez qu’aucune mise à jour de document n’est nécessaire. Ne rédigez pas une fonction absente du diff.

Voici d’abord les exemples, puis la nouvelle entrée. La réponse a la même forme que les exemples. N’utilisez que les étiquettes présentes dans les exemples. Si la nouvelle entrée n’en correspond à aucune, écrivez « sans correspondance » et indiquez l’exemple le plus proche. N’inventez pas d’étiquette. {exemples} Nouvelle entrée : {entrée}

Répondez à {question} par trois méthodes différentes. Chaque chemin ne dépasse pas 80 caractères et se termine par une ligne qui commence par « Réponse : ». Puis dites si les trois réponses concordent. Si elles concordent, donnez cette réponse. Si elles ne concordent pas, listez le désaccord. Ne les fusionnez pas en un nouveau chiffre.

Écrivez sur {sujet}. N’utilisez que ces sections, dans cet ordre : {sections}. L’ensemble ne dépasse pas {nombre} caractères. Si une section a besoin d’un fait que je n’ai pas donné, écrivez « inconnu » à cet endroit. N’ajoutez pas de section, n’ajoutez pas de slogan, et ne complétez pas un fait que je n’ai pas écrit.

Écrivez sur {sujet}. Rien de ce qui suit ne doit apparaître : {exclusions}. Ne les nommez pas, et ne les faites pas entrer sous un autre nom. Une fois le texte écrit, retirez encore toute phrase qui touche cette liste. S’il ne reste rien, écrivez que l’exclusion a retiré la réponse.

Trouvez-moi un skill qui transforme un plan Markdown en PPT, puis installez-le.

Questionnez ce plan de migration avec Grill Me. Ne sautez pas le retour arrière, le volume de données ni les manques de responsable.

Refaites cette page d’accueil marketing selon Frontend Design. Pas de dégradé violet, pas de rangée de trois cartes de fonctions.

Ouvrez la console de préproduction, connectez-vous avec le compte des variables d’environnement, et listez les tâches échouées de la dernière heure.

Auditez src/app/dashboard/page.tsx selon les bonnes pratiques Vercel React, et corrigez d’abord les trois points au plus fort impact.

Vérifiez cette page d’atterrissage avec Web Design Guidelines, et listez les points non conformes avec leur chemin de fichier.

Écrivez un skill : il transforme une issue GitHub en plan d’implémentation où les tests viennent d’abord.

Fusionnez ces trois PDF, inscrivez un vrai titre de document, et extrayez le tableau de la page 4.

Transformez cette page d’explication en support de 10 pages pour des investisseurs. Une seule idée par page.

Fusionnez ces trois CSV sur sku, supprimez les lignes en double, et écrivez inventory.xlsx.

Concevez un serveur MCP pour notre API interne de tickets. Trois outils au maximum. Montrez le schema d’abord.

Le total du paiement n’est faux qu’en euros. Diagnostiquez d’abord. Ne posez pas de correctif tant que vous ne pouvez pas le reproduire.

Proposez une carte des modules pour ce dossier billing. Nommez les jointures et les tests que chaque jointure exige.

Modélisez les remboursements de cette boutique. Avant d’écrire une fonction, listez les paires d’états illégales.

Comparez Agent Skills et MCP sur un agent de code. Citez les documents d’origine. Marquez ce qui n’est pas encore clair.

Révisez ce README. Retirez les traces d’AI. Les commandes et les chemins de fichiers doivent rester tels quels.

Apprenez-moi Astro Content Collections. Faites un contrôle avant la leçon suivante. Enregistrez la progression dans ./notes.

Retenez que nous utilisons trailingSlash never, et que la langue par défaut est l’anglais. Écrivez cela dans les notes de l’agent.

Passez ce composant à l’API de composition de Vue 3. Alignez-vous sur la version locale de vue. Pas de Vuex.

Auditez /guides/install-agent-skills pour la longueur du titre, le canonical, et le fait qu’il n’y ait qu’un seul h1.

Réécrivez le premier écran. Gardez un seul résultat. Pas de phrases vides. Le bouton doit dire ce que le clic ouvre.

Transformez ce plan en brief Word : styles de titre, page de couverture, et commentaires sur les questions ouvertes.

Démarrez le serveur de développement, puis testez avec Playwright le parcours de paiement : une passe pour le panier vide, une passe pour l’utilisateur connecté.

Ajoutez une table orders, et utilisez RLS pour que chaque utilisateur ne voie que ses propres lignes. Donnez la migration et les politiques.

Recomposez cette page de réglages en composants composés. Ne transmettez plus theme ni title sur cinq niveaux.

Faites une page de profil avec Expo. Pour la liste des publications, utilisez FlatList. N’utilisez pas une mise en page en div réservée au Web.

Ajoutez Checkout pour un achat en une fois. Vérifiez la signature du Webhook, et enregistrez l’état du paiement de façon idempotente.

Créez une branche Neon pour cette PR, lancez les migrations sur cette branche, et pointez l’environnement de prévisualisation vers elle.

Faites avec Remotion un générique produit de 15 secondes : carte de titre, trois arguments, Logo de fin. 1080p.

Ce test instable échoue une fois sur cinq. Passez par le débogage systématique. Ne posez pas de correctif tant que vous ne pouvez pas le reproduire.

Ajoutez une limite de débit avec TDD. Montrez d’abord le test qui échoue, puis écrivez l’implémentation.

Refaites cette page de réglages. Corrigez la hiérarchie, l’espacement et l’état de focus. Pas de dégradé violet de stock.

Ajoutez une authentification à cette API. Si un point reste flou, demandez-moi avant d’inventer vous-même un schéma.