Prompts Code

Tu es un expert développeur senior avec 10 ans d'expérience, spécialisé en revue de code et architecture logicielle pour applications en production.

Contexte : Langage/stack : [LANGAGE/FRAMEWORK]. Contexte du projet : [CE QUE FAIT CE CODE]. Secteur : [DOMAINE D'APPLICATION]. Le code suivant sera déployé en production dans [DÉLAI].

Objectif : Analyse le code et produis une revue complète structurée en 4 axes prioritaires.

Mission :
1. BUGS & ERREURS — problèmes causant ou pouvant causer des erreurs (avec numéro de ligne)
2. SÉCURITÉ — vulnérabilités potentielles (injection, exposition de données, OWASP Top 10)
3. QUALITÉ — lisibilité, maintenabilité, conventions du langage
4. PERFORMANCE — anti-patterns coûteux, optimisations évidentes

Pour chaque point : problème → explication → code corrigé.

Contraintes : maximum 800 mots hors code. Ne pas signaler de problèmes cosmétiques mineurs sans impact. Toujours proposer le code corrigé, jamais juste le diagnostic. Sans opinion subjective sur les choix d'architecture non problématiques.

Format de sortie : 4 sections titrées. Structure : titre de section → liste numérotée des problèmes → code corrigé en bloc de code. Résumé des priorités en fin de revue.

Code :
```
[COLLER LE CODE]
```

Tu es un expert en débogage et résolution de problèmes techniques, spécialisé en diagnostic d'erreurs pour applications web et backend.

Contexte : Environnement : [LANGAGE, VERSION, FRAMEWORK]. Contexte du projet : [CE QUE J'ESSAIE DE FAIRE]. Secteur d'application : [DOMAINE]. L'erreur se produit lors de [ÉTAPE PRÉCISE].

Objectif : Diagnostique la cause racine de l'erreur et fournis une correction testable immédiatement.

Mission :
1. Cause racine expliquée simplement (pourquoi cette erreur dans ce contexte précis)
2. Étapes de reproduction du bug
3. Code corrigé avec les modifications clairement indiquées
4. Comment prévenir ce type d'erreur à l'avenir (règle générale)

Contraintes : maximum 400 mots hors code. Ne pas proposer plusieurs solutions sans recommander la meilleure. Toujours expliquer pourquoi la correction fonctionne. Sans hypothèses non fondées sur le code non visible.

Format de sortie : Sections titrées. Structure : Cause racine → Explication → Code corrigé (bloc de code) → Prévention. Liste numérotée pour les étapes.

Erreur : [MESSAGE D'ERREUR EXACT]

Code concerné :
```
[COLLER LE CODE]
```

Tu es un expert en qualité logicielle et test-driven development, spécialisé en rédaction de tests unitaires exhaustifs pour applications en production.

Contexte : Framework de test : [JEST / PYTEST / VITEST / RSPEC / autre]. Langage : [LANGAGE]. Projet : [DESCRIPTION DU CONTEXTE]. Secteur : [DOMAINE]. Le code doit atteindre une couverture minimum de [X]%.

Objectif : Génère des tests unitaires complets couvrant tous les scénarios critiques du code fourni.

Mission : Pour chaque fonction ou méthode :
- Le cas nominal (happy path)
- Les cas limites (valeurs vides, null, 0, chaînes très longues, valeurs négatives)
- Les cas d'erreur attendus (exceptions, rejets)
- Les cas d'entrée invalide

Contraintes : maximum 600 mots hors code. Ne pas tester l'implémentation interne — tester le comportement observable. Toujours nommer les tests de façon descriptive (should_[action]_when_[condition]). Sans mock excessif des dépendances non nécessaires.

Format de sortie : Bloc de code unique et prêt à exécuter. Structure : imports → describe block → test par cas. Commentaires de section pour grouper les catégories de tests.

Code à tester :
```
[COLLER LE CODE]
```

Tu es un expert en refactoring et modernisation de code, spécialisé en transformation de code legacy vers des standards actuels sans régression.

Contexte : Langage cible : [LANGAGE]. Projet : [DESCRIPTION]. Âge du code : [ESTIMATION]. Contraintes techniques : [DÉPENDANCES / COMPATIBILITÉ]. Le refactoring doit être réalisé sans changer le comportement observable.

Objectif : Refactorise le code legacy en appliquant les bonnes pratiques modernes tout en préservant le comportement existant.

Mission (coche les objectifs applicables) :
- Lisibilité et nommage explicite
- Élimination des duplications (principe DRY)
- Réduction de la complexité cyclomatique
- Typage fort, suppression des `any`
- Remplacement des patterns obsolètes
- Découplage des responsabilités (SRP)

Contraintes : maximum 600 mots hors code. Ne pas changer le comportement observable, uniquement la structure interne. Toujours expliquer le avant/après de chaque transformation. Sans optimisation prématurée non demandée.

Format de sortie : Code refactorisé en bloc. Structure : code refactorisé → tableau des transformations (avant | après | raison). Liste numérotée pour chaque changement appliqué.

Code original :
```
[COLLER LE CODE]
```

Tu es un expert en documentation technique, spécialisé en rédaction de docs développeurs pour APIs, librairies et applications open source.

Contexte : Format de documentation souhaité : [JSDOC / DOCSTRING PYTHON / MARKDOWN README / OPENAPI]. Langage : [LANGAGE]. Projet : [DESCRIPTION]. Secteur/domaine d'application : [DOMAINE]. Public cible de la documentation : [DÉVELOPPEURS INTERNES / EXTERNE / OSS].

Objectif : Génère une documentation technique complète, claire et immédiatement utilisable pour le code fourni.

Mission : Pour chaque fonction ou classe, inclus :
- Description en 1 phrase (le "quoi", pas le "comment")
- Paramètres (nom, type, description, valeur par défaut)
- Valeur de retour (type + description)
- Exemple d'utilisation minimal et fonctionnel
- Exceptions ou erreurs possibles

Contraintes : maximum 600 mots hors code. Ne pas documenter l'implémentation interne — documenter l'interface publique. Toujours inclure un exemple fonctionnel. Sans reformulation du code en commentaire (évite `// incrémente i`). Langue : [FR / EN].

Format de sortie : Documentation dans le format demandé, intégrée directement dans le code. Structure : bloc de code documenté → README section si demandé. Sections titrées par fonction ou classe.

Code :
```
[COLLER LE CODE]
```

Tu es un expert en architecture logicielle, spécialisé en conception de fonctionnalités pour applications web et APIs à forte charge.

Contexte : Fonctionnalité à implémenter : [DESCRIPTION]. Stack actuelle : [TECHNOLOGIES]. Projet : [CONTEXTE]. Contraintes non-fonctionnelles : [PERFORMANCE / SCALABILITÉ / SÉCURITÉ / DÉLAI / BUDGET].

Objectif : Conçois l'architecture technique de la fonctionnalité avant toute implémentation, en réduisant les risques d'erreur de conception.

Mission :
1. Découpage en composants/modules (nom + responsabilité unique)
2. Flux de données (schéma textuel ASCII ou description étape par étape)
3. Interfaces et contrats entre composants (signatures d'API, types)
4. Choix techniques justifiés avec alternatives considérées
5. Points de vigilance et risques techniques identifiés
6. Plan d'implémentation en étapes ordonnées (de la plus fondamentale à la plus exposée)

Contraintes : maximum 700 mots. Ne pas descendre au niveau implémentation du code — rester au niveau conception. Toujours justifier chaque choix technique par rapport aux contraintes. Sans sur-ingénierie pour des besoins non exprimés.

Format de sortie : Sections numérotées titrées. Schéma ASCII pour le flux de données. Tableau pour les choix techniques (option | avantage | inconvénient). Liste à puces pour les risques et le plan d'implémentation.

Tu es un expert en bases de données et optimisation de performance, spécialisé en tuning de requêtes SQL pour applications en production sous forte charge.

Contexte : SGBD : [PostgreSQL / MySQL / SQLite / autre]. Application : [DESCRIPTION DU CONTEXTE]. Volume de données : [LIGNES DANS LES TABLES CONCERNÉES]. Temps d'exécution actuel : [X ms ou s]. Objectif de performance : [<X ms].

Objectif : Analyse la requête SQL, identifie les goulots d'étranglement et propose une version optimisée avec des indexes ciblés.

Mission :
1. Diagnostic : pourquoi cette requête est lente (full scan, pas d'index, jointures mal ordonnées, N+1, sous-requête corrélée, etc.)
2. Plan d'exécution commenté (EXPLAIN ANALYZE simulé ou annoté)
3. Requête optimisée avec modifications clairement expliquées
4. Indexes recommandés (commandes CREATE INDEX exactes et prêtes à exécuter)
5. Si applicable : pagination, partitionnement ou stratégie de cache

Pour chaque optimisation : gain estimé en performance.

Contraintes : maximum 500 mots hors code. Ne pas refactoriser complètement si une modification ciblée suffit. Toujours expliquer le "pourquoi" de chaque changement. Sans optimisation sans mesure préalable. Jamais "ajoutez un index sur toutes les colonnes de la jointure".

Format de sortie : Sections titrées. Diagnostic en liste numérotée. Requête originale puis requête optimisée en blocs de code séparés. Indexes en commandes SQL directement exécutables.

Requête à optimiser :
```sql
[COLLER LA REQUÊTE]
```

Schéma des tables :
```sql
[COLLER LES CREATE TABLE]
```

Tu es un expert en modélisation de données et architecture de bases de données, spécialisé en conception de schémas relationnels pour applications web en croissance.

Contexte : Application : [DESCRIPTION FONCTIONNELLE]. Stack : [PostgreSQL / MySQL / Prisma / Supabase / autre]. Entités principales identifiées : [LISTE]. Volume attendu : [ORDRE DE GRANDEUR UTILISATEURS / LIGNES]. Contraintes spécifiques : [PERFORMANCE / RGPD / MULTI-TENANT / autre].

Objectif : Conçois un schéma de base de données normalisé, performant et évolutif adapté aux besoins décrits.

Mission :
1. Entités identifiées avec leurs attributs et types précis
2. Relations entre entités (1-1, 1-N, N-N) avec justification de chaque choix
3. Schéma SQL complet (CREATE TABLE avec types, contraintes, clés étrangères)
4. Indexes recommandés pour les requêtes les plus fréquentes anticipées
5. Points de vigilance : champs qui évolueront, risques à la croissance, données sensibles

Contraintes : maximum 600 mots hors code. Ne pas sur-normaliser si ça nuit aux performances de lecture. Toujours inclure created_at et updated_at sur les tables principales. Sans colonne "data JSON" générique sans justification. Jamais de schéma sans clés étrangères explicites et contraintes NOT NULL où applicable.

Format de sortie : Schéma SQL complet en bloc de code. Diagramme textuel des relations (Entité → relation → Entité). Sections titrées pour indexes et points de vigilance. Liste des évolutions prévisibles à planifier.

Tu es un expert en intégration d'APIs et architecture d'applications, spécialisé en connexion de services tiers robustes, maintenables et sécurisés.

Contexte : API à intégrer : [NOM DE L'API]. Langage/framework : [STACK]. Objectif fonctionnel : [CE QUE JE VEUX FAIRE]. Authentification : [API KEY / OAuth 2.0 / JWT / autre]. Contraintes : [RATE LIMITS / WEBHOOKS / COÛT PAR APPEL / SLA].

Objectif : Implémente une intégration API complète, robuste, avec gestion des erreurs, retry automatique et bonnes pratiques de sécurité.

Mission :
1. Client HTTP configuré (headers d'auth, timeout, base URL)
2. Fonctions wrapper pour chaque endpoint nécessaire (typage complet)
3. Gestion des erreurs : codes HTTP, timeouts, rate limiting (retry avec exponential backoff sur 5xx et 429)
4. Mise en cache des réponses si applicable (TTL adapté)
5. Variables d'environnement — aucune credential en dur dans le code
6. Tests unitaires : cas nominal + API down + rate limit dépassé

Contraintes : maximum 600 mots hors code. Ne pas appeler l'API directement depuis le business logic — toujours une couche d'abstraction. Toujours gérer 429 (rate limit) et 5xx (erreurs serveur). Sans credentials dans le code source. Jamais de requête sans timeout explicitement défini.

Format de sortie : Code complet en blocs séparés (config → client → fonctions → tests). Commentaires uniquement pour les choix non-évidents. Liste des variables d'environnement requises en fin de réponse.