À copier-coller dans une IA

Prompts prêts à l'emploi

Une sélection de prompts prêts à coller dans une IA pour accélérer les tâches du quotidien : rédaction de documentation, user stories, revue de code, tests… Copiez, adaptez les éléments entre crochets [ ] et lancez.

Analyse ce projet et rédige un README.md complet : présentation du projet en 2-3 phrases,
prérequis, instructions d'installation, exemples d'utilisation, structure des dossiers
principaux, et section contribution. Base-toi uniquement sur le code et la configuration
réels du repo, ne suppose rien qui n'y figure pas.

Documente [nom du fichier/module/fonction] : son rôle, ses paramètres d'entrée et de sortie,
les cas d'erreur possibles, et un exemple d'appel. Le format doit être adapté aux
conventions déjà utilisées dans le projet (docstring, JSDoc, Markdown...).

À partir des commits entre [tag/branche de référence] et [tag/branche actuelle], génère
une entrée de CHANGELOG au format "Keep a Changelog" (catégories Ajouté / Modifié /
Corrigé / Supprimé). Ignore les commits purement techniques (formatage, typos) sans
impact utilisateur.

Rédige une ADR pour la décision suivante : [décrire la décision, ex : "choix de
PostgreSQL plutôt que MongoDB pour le stockage des dossiers patients"]. Structure-la
avec : Contexte, Décision, Alternatives envisagées, Conséquences (positives et
négatives).

Rédige une user story au format "En tant que [rôle], je veux [besoin], afin de [bénéfice]"
pour la fonctionnalité suivante : [décrire la fonctionnalité]. Ajoute 3 à 5 critères
d'acceptation au format Gherkin (Étant donné / Quand / Alors), en couvrant le cas
nominal et au moins un cas d'erreur.

Découpe la fonctionnalité suivante en plusieurs user stories indépendantes et livrables
séparément : [décrire la fonctionnalité]. Pour chaque story, indique un titre court,
une estimation relative (S/M/L) et les dépendances éventuelles avec les autres stories.

À partir du besoin métier suivant : [décrire le besoin], rédige une épopée avec :
objectif métier, périmètre inclus/exclu, indicateurs de succès mesurables, et une
liste indicative des user stories qui pourraient la composer.

Voici mes notes brutes de [réunion/atelier] : [coller les notes]. Rédige un
compte-rendu structuré : contexte, décisions prises, points en suspens, et une liste
d'actions avec responsable et échéance quand elles sont identifiables.

Écris des tests unitaires pour [fichier/fonction] en utilisant [framework de test du
projet]. Couvre le cas nominal, les cas limites (valeurs vides, nulles, extrêmes) et
au moins un cas d'erreur attendu. Respecte les conventions de nommage et la structure
des tests déjà présents dans le projet.

Fais une revue de [fichier/diff] en te concentrant sur [sécurité / performance /
lisibilité / gestion d'erreurs]. Pour chaque problème identifié, indique la ligne
concernée, la raison, et une correction proposée. Ne signale que des problèmes réels,
pas de style personnel.

Rédige un plan de test manuel pour valider la fonctionnalité suivante avant mise en
production : [décrire la fonctionnalité]. Liste les scénarios à tester (nominal,
limites, erreurs), le résultat attendu pour chacun, et les prérequis d'environnement
nécessaires.

Explique ce que fait [fichier/fonction] étape par étape, comme si tu l'expliquais à un
développeur qui découvre le projet. Signale les parties peu claires, les risques
potentiels, et les dépendances implicites avec d'autres modules.

Analyse les changements actuellement en attente (diff) et rédige un message de commit
concis qui explique le "pourquoi" du changement plutôt que le "quoi". Respecte le
format déjà utilisé dans l'historique du projet (Conventional Commits ou autre).

À partir des commits de cette branche par rapport à [branche de base], rédige une
description de pull request avec : résumé des changements, motivation, et une
checklist de plan de test pour le relecteur.