Prompting avancé et multi-agents

# Étape 1 : Reproduction du problème
"Je rencontre ce problème : [description symptôme précis].
Stack : [technologies]
Erreur exacte : [message d'erreur complet]
Code concerné : [coller le code minimal qui reproduit le problème]

Ne propose pas encore de solution. Dis-moi d'abord :
1. Ce que tu comprends du problème
2. Quelles informations supplémentaires tu aurais besoin pour diagnostiquer"

# Étape 2 : Isolation
"Voici les informations complémentaires : [répondre aux questions de Claude].
Maintenant, liste les 3-5 causes possibles par ordre de probabilité.
Pour chaque cause, comment la valider en 2 minutes ?"

# Étape 3 : Fix ciblé
"La cause est confirmée : [cause identifiée].
Génère uniquement le fix minimal pour ce problème précis.
Ne refactorise pas le reste du code.
Explique pourquoi ce fix résout le problème."

# Étape 4 : Test de régression
"Fix appliqué et validé. Génère un test qui aurait détecté ce bug
avant qu'il arrive en production. Le test doit reproduire exactement
les conditions qui déclenchaient le bug."

# Étape 1 : Analyse d'impact
"Analyse ce code [coller] et évalue son état actuel :
1. Quels sont les problèmes de lisibilité, testabilité et maintenabilité ?
2. Quels fichiers seraient impactés par un refactoring ?
3. Quels risques de régression existe-t-il ?
4. Propose un plan de refactoring en étapes indépendantes (chacune déployable séparément)"

# Étape 2 : Migration progressive (pour chaque étape du plan)
"Étape 1 du refactoring : [titre de l'étape].
Contraintes :
- Conserve le même comportement observable (les tests doivent passer)
- Chaque étape doit être indépendamment déployable
- Pas de changement de logique métier dans cette étape, uniquement la structure
Génère le code de cette étape uniquement."

# Étape 3 : Validation
"Étape 1 déployée. Avant de passer à l'étape 2 :
1. Quels tests dois-je lancer pour valider que rien n'a régressé ?
2. Y a-t-il des edge cases dans l'étape 1 que je devrais vérifier manuellement ?"

# Prompt complet pour une code review structurée
"Tu es un développeur senior. Review ce code [coller] en 4 passes successives :

Passe 1 : Structure :
- L'organisation des responsabilités est-elle claire ?
- Les noms sont-ils expressifs et cohérents ?
- La lisibilité est-elle bonne (nesting, longueur des fonctions) ?

Passe 2 : Logique :
- Y a-t-il des bugs potentiels ?
- Les edge cases sont-ils gérés (null, vide, limite) ?
- La logique métier est-elle correcte ?

Passe 3 : Sécurité :
- Y a-t-il des inputs non validés ?
- Des données sensibles exposées ?
- Des injections possibles ?

Passe 4 : Performance :
- Y a-t-il des requêtes N+1 ?
- Des calculs qui pourraient être mis en cache ?
- Des opérations synchrones bloquantes évitables ?

Pour chaque issue : sévérité (CRITICAL/HIGH/MEDIUM/LOW), description, correction suggérée."

# Étape 1 : Inventaire complet
"Analyse le codebase pour établir l'inventaire de migration [technologie A] → [technologie B].

Pour chaque fichier/module :
- Nom et chemin
- Complexité de migration estimée (1 = trivial, 5 = complexe)
- Dépendances qui bloquent la migration
- Risques spécifiques

Génère un tableau trié : d'abord les quick wins (complexité 1-2), puis les complexes."

# Étape 2 : Plan par phases
"Sur la base de l'inventaire, génère un plan de migration en phases.
Contraintes :
- Chaque phase doit laisser le projet en état déployable
- Les dépendances circulaires doivent être identifiées et résolues
- Estimation de durée par phase pour une équipe de [X] développeurs
- Définir les critères de succès (métriques) pour chaque phase"

# Étape 3 : Exécution module par module
"Phase 1 validée. Commence la migration de [module spécifique].
Règles :
- Coexistence avec l'ancienne version pendant la transition
- Feature flag pour basculer progressivement
- Tests de parité : vérifier que le comportement est identique avant/après"

# Étape 4 : Vérification post-migration
"Migration de [module] terminée.
Génère :
1. Les tests de smoke pour valider le module migré
2. La checklist de vérification manuelle
3. Le plan de rollback si un problème est détecté en production"

# Étape 1 : Identification des cas de test
"Avant d'écrire une ligne d'implémentation, identifie tous les cas de test
pour cette fonctionnalité : [description de la feature].

Classe-les en :
- Cas nominaux (happy path)
- Cas d'erreur (inputs invalides, ressource inexistante)
- Edge cases (vide, limite, concurrence)
- Cas de régression (bugs connus à ne pas réintroduire)

Pour chaque cas : description, input, output attendu."

# Étape 2 : Écriture des tests (RED)
"Sur la base des cas identifiés, écris les tests avec [Vitest/Jest/pytest].
Les tests doivent échouer pour l'instant (RED).
Utilise des noms de test descriptifs : 'should [expected behavior] when [condition]'
Mock uniquement les dépendances externes (base de données, API)."

# Étape 3 : Implémentation minimale (GREEN)
"Tests écrits. Maintenant implémente le minimum de code pour faire passer ces tests.
Pas d'optimisation prématurée, pas de features non testées.
Le code peut être 'moche' tant qu'il est correct."

# Étape 4 : Refactoring (IMPROVE)
"Tous les tests passent. Phase de refactoring :
1. Nettoie le code sans changer le comportement
2. Extrais les duplications
3. Améliore les noms
4. Vérifie que les tests passent toujours après chaque changement"

# Sans chain-of-thought (résultat médiocre)
"Quelle est la meilleure architecture pour notre API ?"

# Avec chain-of-thought (résultat approfondi)
"Analyse notre besoin d'architecture API. Raisonne étape par étape :

1. Identifie les contraintes actuelles (volume, latence, coût)
2. Liste les options viables (REST, GraphQL, tRPC, gRPC)
3. Pour chaque option, évalue :
   - Performance avec notre volume de données
   - Complexité d'implémentation pour l'équipe
   - Compatibilité avec notre stack Next.js/TypeScript
   - Facilité de testing et de documentation
4. Compare les trade-offs dans un tableau
5. Formule ta recommandation avec les arguments clés

Montre ton raisonnement à chaque étape."

Analyse les composants React pour identifier les problèmes de performance.
Voici comment je veux que tu raisonnes :

## Exemple 1
Composant : un UserList qui fait un fetch à chaque re-render
Analyse : Le composant n'a pas de dépendances stables pour son useEffect.
À chaque re-render du parent, le fetch se relance inutilement.
Impact : requêtes réseau excessives, flickering de l'UI, charge serveur.
Solution : extraire le fetch dans useSWR ou React Query avec une clé
de cache stable. Ajouter un staleTime de 5 minutes.

## Exemple 2
Composant : un Dashboard qui rend 50 composants enfants
Analyse : Chaque changement de state dans le Dashboard provoque
le re-render des 50 enfants, même ceux qui n'ont pas changé.
Impact : lag perceptible, surtout sur mobile.
Solution : React.memo sur les enfants stables, useCallback sur
les handlers passés en props, virtualisation pour les listes longues.

## Maintenant, analyse ce composant :
[Copiez votre composant ici]

# Mauvais (suppose un contexte que le subagent n'a pas)
"Vérifie la sécurité du code qu'on vient d'écrire"

# Bon (prompt autonome pour un subagent)
"Tu es un expert en sécurité applicative (OWASP Top 10).
Analyse les fichiers suivants pour détecter des vulnérabilités :
- src/controllers/auth.controller.ts
- src/services/auth.service.ts
- src/middlewares/auth.middleware.ts

Vérifie spécifiquement :
1. Injection (SQL, NoSQL, command injection)
2. Authentification cassée (tokens prédictibles, pas de rate limiting)
3. Exposition de données sensibles (password hash dans les réponses)
4. XSS (sanitization des inputs, CSP headers)

Format de sortie :
| Sévérité | Fichier | Ligne | Vulnérabilité | Correction |
|----------|---------|-------|---------------|------------|"

# Dans votre prompt principal, demandez à Claude de lancer en parallèle :

"Lance 3 analyses en parallèle sur le module d'authentification :

Agent 1 (code-reviewer) :
- Qualité du code, patterns, maintenabilité
- Respect des conventions du projet (CLAUDE.md)
- Suggestions d'amélioration

Agent 2 (security-reviewer) :
- Analyse OWASP Top 10
- Vérification des secrets et tokens
- Surface d'attaque de chaque endpoint

Agent 3 (tdd-guide) :
- Couverture de tests actuelle
- Tests manquants critiques
- Cas limites non couverts

Synthétise les résultats des 3 agents dans un rapport unifié."

# Activer/désactiver Extended Thinking
Alt+T (Linux/Windows) ou Option+T (macOS)

# Configurer via variable d'environnement
export MAX_THINKING_TOKENS=10000

# Voir la pensée de Claude
Ctrl+O (mode verbose)

# Activez le Plan Mode puis demandez :
"Je veux migrer notre state management de Redux vers Zustand.
Propose un plan de migration détaillé avant de commencer.

Pour chaque étape du plan, indique :
- Les fichiers impactés
- Les changements à effectuer
- Les risques de régression
- L'estimation de complexité (simple/moyen/complexe)"

"Avant de coder, reformule ce que tu as compris de ma demande :
- Quel est l'objectif principal ?
- Quelles sont les contraintes techniques ?
- Quel format de sortie est attendu ?
- Quels sont les edge cases à gérer ?

Si ta compréhension est correcte, proceed. Sinon, dis-moi ce qui n'est pas clair."

# Mauvais (repartir de zéro)
"Non, ce n'est pas ce que je voulais. Recommence."

# Bon (correction ciblée)
"Le composant est bien structuré. Voici 2 corrections :
1. Le state loading doit être géré avec un skeleton, pas un spinner
2. La pagination doit être cursor-based (pas offset-based) car la liste
   peut être modifiée pendant la navigation"

# Prompt classique (tout est explicite)
"Crée un composant Card en React avec TypeScript, Tailwind CSS,
qui accepte les props : title, description, icon, variant..."

# Prompt contextuel (s'appuie sur le codebase)
"Crée un composant Card qui suit les mêmes patterns que
src/components/ui/Callout.tsx (même structure de props, même style
Tailwind, même gestion des variantes avec CVA).
Variantes : default, accent, highlight.
Utilise le design system existant dans globals.css."

"Crée le endpoint GET /api/projects/:id/tasks en suivant :
- Le pattern du controller dans src/controllers/user.controller.ts
- La validation Zod comme dans src/schemas/user.schema.ts
- Les tests comme dans src/controllers/__tests__/user.controller.test.ts

La seule différence : ajoute un filtre par statut (query param ?status=todo)
et une pagination cursor-based."