15 prompts prets a l emploi pour le developpement#

Tu es un developpeur senior qui fait de l onboarding.

Lis le fichier [CHEMIN_DU_FICHIER] et explique-le moi.

FORMAT DE SORTIE
1. A quoi sert ce fichier, en 2 phrases.
2. Le chemin des donnees : ce qui entre, ce qui sort, ce qui est modifie au passage.
3. Les 3 fonctions les plus importantes, une ligne chacune.
4. Les pieges : effets de bord, dependances cachees, comportements surprenants.
5. Ce que je dois lire ensuite pour comprendre le reste.

CONTRAINTES
- Niveau : je connais [LANGAGE] mais pas ce projet.
- Pas de paraphrase ligne par ligne.

Fais-moi une vue d ensemble de ce depot : architecture, dossiers cles,
et comment les morceaux s emboitent.

Puis reponds a ces 3 questions :
- Par ou passe une requete entrante, de l entree jusqu a la reponse ?
- Ou sont la configuration et les secrets ?
- Comment on lance les tests et le build ?

FORMAT DE SORTIE
Un tableau `dossier | role | a lire en priorite oui/non`, puis les 3 reponses.
Maximum 40 lignes au total.

Tu es un developpeur [LANGAGE] senior.

CONTEXTE
Projet : [DESCRIPTION_DU_PROJET_EN_UNE_PHRASE]
Stack : [VERSIONS_ET_LIBRAIRIES]
Le code existant suit le style de [FICHIER_EXEMPLE_A_IMITER].

TACHE
Ecris la fonction `[NOM_DE_LA_FONCTION]`.
Elle recoit [ENTREES_AVEC_LEURS_TYPES].
Elle renvoie [SORTIE_AVEC_SON_TYPE].
Elle doit gerer ces cas limites : [CAS_LIMITE_1], [CAS_LIMITE_2].

CONTRAINTES
- Pas de nouvelle dependance.
- Type hints et docstring courte obligatoires.
- Maximum [NOMBRE] lignes.

VERIFICATION
Ecris aussi 5 cas de test, dont 2 qui doivent echouer, puis lance-les et montre la sortie.

Ecris des tests pour [CHEMIN_DU_FICHIER], lance-les, et corrige les echecs.

CONTRAINTES
- Framework : [PYTEST_OU_JEST_OU_AUTRE].
- Couvre en priorite le cas ou [SCENARIO_RISQUE_A_COUVRIR].
- Evite les mocks : si tu dois en mettre un, explique pourquoi en une ligne.
- Suis la structure des tests deja presents dans [DOSSIER_DES_TESTS].

FORMAT DE SORTIE
Le fichier de test, puis la sortie reelle de l execution.

On travaille en TDD.

ETAPE 1 : ecris d abord les tests de [FONCTIONNALITE_A_CONSTRUIRE].
Ne touche a aucun code de production pour l instant.
Les tests doivent echouer. Lance-les et montre-moi qu ils echouent.

ETAPE 2 : attends mon accord.

ETAPE 3 : implemente le minimum pour faire passer les tests, puis relance-les.
Ne modifie jamais un test pour le faire passer.

J ai cette erreur :

[COLLE_ICI_LE_MESSAGE_ET_LA_TRACE_COMPLETE]

CONTEXTE
Ce que je faisais : [ACTION_QUI_DECLENCHE_L_ERREUR]
Ce qui a change recemment : [DEPLOIEMENT_MIGRATION_OU_RIEN]
Environnement : [LOCAL_OU_PROD], [VERSIONS]

TACHE
1. Donne-moi les 3 causes les plus probables, classees par probabilite.
2. Pour chacune, la commande exacte qui permet de confirmer ou d eliminer.
3. Ensuite seulement, corrige la cause racine.

CONTRAINTE
Ne masque pas l erreur avec un try/except ou un flag. Repare la cause.

VERIFICATION
Relance [COMMANDE_DE_TEST_OU_DE_BUILD] et montre la sortie.

Le test [NOM_DU_TEST] echoue. Trouve pourquoi et repare-le.

Avant de modifier quoi que ce soit, dis-moi en 2 lignes si le bug est
dans le test ou dans le code teste, et sur quoi tu te bases.

Ensuite corrige, relance la suite complete, et montre-moi la sortie.
Si un autre test casse a cause de ta correction, signale-le.

Tu es un developpeur senior prudent.

TACHE
Refactore [CIBLE : FICHIER_CLASSE_OU_FONCTION] pour [OBJECTIF : LISIBILITE_PERFORMANCE_TESTABILITE].

CONTRAINTES
- Le comportement externe ne change pas. Aucune signature publique modifiee.
- Un seul type de changement a la fois. Pas de renommage + restructuration en meme temps.
- Si les tests actuels ne couvrent pas la zone, ecris-les AVANT de refactorer.

FORMAT DE SORTIE
1. La liste des fichiers que tu vas toucher, avant de coder.
2. Attends mon accord.
3. Puis le diff, et la sortie des tests.

Relis mes modifications non commitees et signale ce qui est risque avant que je commite.

FORMAT DE SORTIE
1. Ce que fait ce changement, en 3 puces.
2. Risques, classes en bloquant / a surveiller / cosmetique :
   erreurs non gerees, valeurs en dur, secrets, requetes non parametrees,
   tests manquants, changement d interface non documente.
3. La liste des corrections a faire avant commit, par ordre de priorite.

CONTRAINTE
Ne commente pas le style si le linter le fait deja.

Relis la pull request [NUMERO_OU_BRANCHE].

FORMAT DE SORTIE
1. Resume du changement en 3 puces, du point de vue fonctionnel.
2. Questions que je devrais poser a l auteur (maximum 5).
3. Problemes concrets, avec fichier et ligne : [CE_QUI_T_INQUIETE, ex : securite, perf, migration].

CONTRAINTE
Ne signale que ce qui affecte la correction ou les exigences enoncees.
Ignore les preferences de style. Si tu ne trouves rien de grave, dis-le clairement.

Je dois choisir entre deux approches pour [PROBLEME_A_RESOUDRE].

Option A : [DESCRIPTION_OPTION_A]
Option B : [DESCRIPTION_OPTION_B]

CONTEXTE ET CRITERES QUI COMPTENT POUR MOI
- Volume / charge attendue : [CHIFFRE]
- Equipe : [TAILLE_ET_NIVEAU]
- Contrainte forte : [DELAI_COUT_MAINTENANCE]

FORMAT DE SORTIE
1. Un tableau comparatif : critere | option A | option B.
2. Ce qui te ferait changer d avis dans chaque sens.
3. Ta recommandation en une phrase, avec la raison principale.
4. Le cout de sortie : si je me trompe, qu est-ce que ca coute de revenir en arriere ?

Ecris une expression reguliere qui capture [CE_QUE_TU_VEUX_CAPTURER].

Moteur : [PYTHON_RE_OU_JAVASCRIPT_OU_POSIX_OU_AUTRE]

DOIT MATCHER
[EXEMPLE_1]
[EXEMPLE_2]

NE DOIT PAS MATCHER
[CONTRE_EXEMPLE_1]
[CONTRE_EXEMPLE_2]

FORMAT DE SORTIE
1. La regex.
2. Une explication morceau par morceau, en francais simple.
3. Un petit script qui teste tous les exemples ci-dessus. Lance-le et montre la sortie.
4. Les cas ou cette regex se trompera quand meme.

Ecris un script [LANGAGE] en ligne de commande qui [CE_QUE_LE_SCRIPT_DOIT_FAIRE].

ENTREES
- Arguments : [LISTE_DES_ARGUMENTS]
- Fichiers ou API lus : [SOURCES]

COMPORTEMENT ATTENDU
- Mode `--dry-run` qui affiche ce qui serait fait sans le faire.
- Journalisation lisible sur la sortie standard.
- Code de sortie 0 si succes, non nul sinon.
- Message d erreur explicite si [CAS_D_ERREUR_PROBABLE].

CONTRAINTES
- Bibliotheque standard uniquement, sauf [EXCEPTION_AUTORISEE].
- Doit tourner sous [WINDOWS_OU_LINUX_OU_LES_DEUX].

VERIFICATION
Lance le script en `--dry-run` sur un exemple et montre-moi la sortie.

Question 1 : qu est-ce qui casserait si je supprimais [FONCTION_CLASSE_OU_FICHIER] ?
Question 2 : quels fichiers devrais-je toucher pour [CHANGEMENT_ENVISAGE] ?

FORMAT DE SORTIE
Un tableau : fichier | ce qui change | risque faible/moyen/eleve | test qui couvre.
Puis une ligne : ce qui n est couvert par aucun test.

CONTRAINTE
Base-toi sur le code reel du depot, pas sur des suppositions.
Si tu n es pas sur d un appel, dis-le au lieu de l affirmer.

Regarde mes modifications et ecris :

1. Un message de commit.
   - Ligne 1 : maximum 72 caracteres, a l imperatif, sans point final.
   - Ligne vide, puis 2 a 4 puces qui expliquent le POURQUOI, pas le QUOI.
2. Une description de pull request avec ces sections :
   - Contexte : le probleme en 2 phrases.
   - Ce qui change.
   - Ce qui ne change pas (pour rassurer le relecteur).
   - Comment tester : les commandes exactes.
   - Risques et plan de retour arriere.

CONTRAINTE
N invente aucun ticket ni aucun numero que tu n as pas vu dans le depot.

# 1. Explorer (sans rien modifier)
lis [DOSSIER] et explique-moi comment [MECANISME] fonctionne aujourd hui.

# 2. Planifier
je veux ajouter [FONCTIONNALITE]. quels fichiers changent ? ecris un plan, ne code pas.

# 3. Coder
implemente le plan. ecris les tests, lance-les, corrige jusqu au vert.

# 4. Relire et commiter
relis le diff, signale les risques, puis commite avec un message descriptif.