4 prompts code & développement prêts à copier

Tu es ingénieur senior expérimenté en [LANGAGE / FRAMEWORK]. Fais une code review du code suivant en suivant ces dimensions :

**Code à reviewer :**
```[LANGAGE]
[COLLER LE CODE]
```

**Contexte :** [À QUOI SERT CE CODE, QUI L'UTILISE, CONTRAINTES]

Reviews à faire dans cet ordre :

1. **Bugs / sécurité (CRITIQUE)** : injection, race conditions, fuites, edge cases non gérés
2. **Correction logique** : la fonction fait-elle ce qu'elle dit faire ? Cas limites ?
3. **Performance** : complexité, allocations inutiles, requêtes N+1, cache
4. **Lisibilité / maintenabilité** : naming, longueur des fonctions, abstractions
5. **Tests** : couverture des cas, qualité des tests, manque
6. **Style / conventions** : respect des conventions du langage/framework

Pour chaque point trouvé :
- Sévérité (🔴 critique / 🟠 important / 🟡 nice-to-have)
- Description du problème
- Code corrigé avec explication courte
- Pourquoi c'est important

Termine par une synthèse : "Globalement, ce code est [état]. Les 3 actions prioritaires sont X, Y, Z."

Sois direct mais constructif. Pas de "super job" si c'est pas vrai.

Tu es débugger senior. J'ai le problème suivant :

**Symptôme observé :**
[DECRIS CE QUI SE PASSE - error message, comportement inattendu, screenshot du log]

**Contexte technique :**
- Stack : [LANGAGE / FRAMEWORK / VERSION]
- Environnement : [LOCAL / STAGING / PROD]
- Quand ça a commencé : [TIMING - après quel changement ?]

**Code suspect (extrait) :**
```
[COLLE LE CODE]
```

**Ce que j'ai déjà essayé :**
[CE QUI N'A PAS MARCHÉ]

Aide-moi à debugger en :
1. Listant 5 hypothèses possibles classées de la plus probable à la moins probable
2. Pour chaque hypothèse : une commande / log / test à exécuter pour la confirmer ou l'infirmer
3. Une fois la cause identifiée : 2-3 façons de la fixer, avec trade-offs
4. Comment éviter ce bug à l'avenir (test, lint, monitoring)

Sois pragmatique : le but est que je résolve mon bug en 10 minutes max, pas de comprendre toute la théorie.

Tu es expert en testing en [LANGAGE]. Génère une suite de tests unitaires complète pour la fonction / module suivant :

```[LANGAGE]
[COLLE LE CODE A TESTER]
```

**Framework de test à utiliser :** [Jest / Vitest / Pytest / Mocha / etc.]

Couvre :
1. **Cas nominal** (le happy path)
2. **Cas limites** (valeurs extrêmes, vides, null/undefined)
3. **Cas d'erreur** (inputs invalides → erreurs attendues)
4. **Mocking** des dépendances externes (API, base de données, fs, etc.)
5. **Tests asynchrones** si applicable

Pour chaque test :
- Nom descriptif ("should return X when Y")
- AAA pattern : Arrange / Act / Assert
- Un seul comportement testé par test

À la fin :
- Liste des cas que tu n'as PAS pu tester (dépendance externe, side-effect impossible à mock)
- Suggestions de refactoring qui rendraient le code plus testable

Code prêt à coller dans le projet.

Tu es Staff Engineer expérimenté. Aide-moi à rédiger un ADR (Architecture Decision Record) pour la décision suivante :

**Contexte :** [DECRIS LE PROBLÈME, LES CONTRAINTES, LE BUSINESS]

**Options considérées :**
1. [OPTION A]
2. [OPTION B]
3. [OPTION C]

**Mon inclination actuelle :** [SI TU EN AS UNE]

Structure l'ADR en :
1. **Titre** (court, descriptif)
2. **Statut** : Proposed / Accepted / Deprecated / Superseded
3. **Contexte** : pourquoi cette décision se pose maintenant
4. **Forces en présence** : contraintes techniques, business, organisationnelles
5. **Options analysées** : pour chacune, pros et cons honnêtes (pas de straw man)
6. **Décision recommandée** : laquelle et pourquoi
7. **Conséquences** : ce que ça change positivement et négativement
8. **À reconsidérer si** : conditions qui pourraient remettre en cause la décision

Sois rigoureux : ne minimise pas les inconvénients de l'option recommandée. Si une option a un gros risque, dis-le.

Format Markdown propre, prêt à coller dans /docs/adr/.