Une commande qui permet aux rôles avec différentes expertises de discuter et examiner les compromis pour dériver des solutions optimales.
Facilitates expert role debates to derive optimal solutions through structured compromise analysis.
/plugin marketplace add wasabeef/claude-code-cookbook/plugin install cook-fr@claude-code-cookbookUne commande qui permet aux rôles avec différentes expertises de discuter et examiner les compromis pour dériver des solutions optimales.
/role-debate <Rôle 1>,<Rôle 2> [Sujet]
/role-debate <Rôle 1>,<Rôle 2>,<Rôle 3> [Sujet]
# Compromis Sécurité vs Performance
/role-debate security,performance
"JWT Token Expiry Setting"
# Équilibre Utilisabilité vs Sécurité
/role-debate frontend,security
"2-Factor Authentication UX Optimization"
# Discussion de sélection technologique
/role-debate architect,mobile
"React Native vs Flutter Selection"
# Débat à trois parties
/role-debate architect,security,performance
"Pros and Cons of Microservices"
Chaque rôle exprime indépendamment des opinions depuis leur perspective professionnelle
Discussion croisée entre rôles
Exploration de solutions implémentables
Détermination des recommandations finales
Débat de rôles : Sécurité vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sujet : Paramètres d'expiration de token JWT
Argument du rôle Sécurité :
"Expiration courte de 15 minutes recommandée"
Bases :
- Conformité au OWASP JWT Security Cheat Sheet
- Minimiser la fenêtre de dommage en cas de fuite de token
- Limiter le temps disponible pour l'attaquant
Préoccupations :
- Une longue expiration augmente exponentiellement le risque d'attaque
- Expiration courte obligatoire pour conformité financière
Métriques de succès :
- Taux d'incident sécurité < 0,1%
- Temps moyen de détection d'attaque < 5 minutes
Réfutation du rôle Performance :
"Expiration de 2 heures recommandée"
Bases :
- Référence aux Google OAuth 2.0 Best Practices
- Éviter charge serveur accrue par réauthentification fréquente
- Minimiser perturbation expérience utilisateur
Préoccupations :
- Réauthentification 15 minutes augmente charge API de 8x
- Déconnexions fréquentes en environnements mobiles
Métriques de succès :
- Maintenir temps réponse API < 200ms
- Utilisation CPU serveur < 60%
Discussion mutuelle :
Sécurité → Performance :
"Les pertes commerciales des violations de sécurité sont plus importantes que charge serveur.
Exemple : violation Equifax a coûté 700 millions $"
Performance → Sécurité :
"Les deux peuvent être obtenus avec mécanisme refresh token.
Mises à jour arrière-plan assurent sécurité sans compromettre UX"
Sécurité → Performance :
"Les refresh tokens sont aussi cibles d'attaque. Implémentation appropriée est prérequis"
Performance → Sécurité :
"Proposer approche par phases. 30 minutes pour opérations normales, 15 minutes pour opérations sensibles"
Recherche de compromis :
Compréhension commune :
- Besoin d'équilibrer expérience utilisateur et sécurité
- Réponse flexible basée sur niveau de risque
- Considération pratique des coûts d'implémentation et opérationnels
Éléments gagnant-gagnant :
- Utilisation du mécanisme refresh token
- Introduction par phases d'authentification basée sur le risque
- Complémentation avec fonction de déconnexion automatique
Conclusion intégrée :
"Expiration 30 minutes + refresh token + authentification basée sur le risque"
Détails d'implémentation :
1. Access token : expiration 30 minutes
2. Refresh token : expiration 7 jours
3. Opérations haut risque : Forcer réauthentification toutes les 15 minutes
4. Déconnexion automatique après 30 minutes d'inactivité
Implémentation par phases :
Semaines 1-2 : Implémentation token 30 minutes de base
Semaines 3-4 : Ajouter mécanisme refresh token
Mois 2 : Introduire authentification basée sur le risque
Métriques de succès :
- Sécurité : Taux d'incident < 0,1%
- Performance : Augmentation charge API < 20%
- UX : Satisfaction utilisateur > 85%
Révision future :
- Après 3 mois : Évaluer motifs d'attaque réels et conditions de charge
- Après 6 mois : Considérer migration vers authentification basée sur le risque plus sophistiquée
Débat de rôles : Architecte vs Sécurité vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sujet : Avantages et inconvénients des microservices
Argument du rôle Architecte :
"Microservices par phases recommandés"
Bases : Limites domaine claires, déploiement indépendant, liberté sélection technologique
Préoccupations du rôle Sécurité :
"Complexité sécurité communication inter-services"
Bases : Coûts gestion API Gateway, mTLS, authentification distribuée
Préoccupations du rôle Performance :
"Augmentation latence due communication réseau"
Bases : Problème N+1 d'appels API internes, transactions distribuées
Discussion à trois parties :
Architecte → Sécurité : "Peut être contrôlé par gestion API Gateway centralisée"
Sécurité → Architecte : "Risque de point de défaillance unique"
Performance → Architecte : "Granularité division service est importante"
...(discussion continue)
Conclusion intégrée :
"Design dirigé par domaine pour division par phases + design sécurité d'abord"
/role-debate architect,performance
"Database Selection: PostgreSQL vs MongoDB"
/role-debate frontend,mobile
"UI Framework: React vs Vue"
/role-debate security,architect
"Authentication Method: JWT vs Session Cookie"
/role-debate security,frontend
"User Authentication UX Design"
/role-debate performance,mobile
"Data Synchronization Strategy Optimization"
/role-debate architect,qa
"Test Strategy and Architecture Design"
/role-debate security,performance
"Encryption Level vs Processing Speed"
/role-debate frontend,performance
"Rich UI vs Page Loading Speed"
/role-debate mobile,security
"Convenience vs Data Protection Level"
debate_stance:
- Approche conservatrice (minimisation risques)
- Axé conformité (prudent quant déviations des standards)
- Hypothèse pire scénario (perspective attaquant)
- Focus impact long terme (sécurité comme dette technique)
typical_issues:
- Compromis "Sécurité vs Commodité"
- "Exigences conformité obligatoires"
- "Comparaison coût attaque vs coût défense"
- "Protection vie privée approfondie"
evidence_sources:
- Directives OWASP
- Frameworks NIST
- Standards industrie (ISO 27001, SOC 2)
- Cas attaque réels et statistiques
debate_strengths:
- Précision évaluation risques
- Connaissance exigences réglementaires
- Compréhension méthodes attaque
potential_biases:
- Conservatisme excessif (inhiber innovation)
- Considération UX insuffisante
- Minimiser coûts implémentation
debate_stance:
- Décisions basées données (basé mesures)
- Axé efficacité (optimiser rapport coût-efficacité)
- Priorité expérience utilisateur (focus vitesse perçue)
- Amélioration continue (optimisation par phases)
typical_issues:
- "Performance vs Sécurité"
- "ROI coût optimisation vs efficacité"
- "Scalabilité actuelle vs future"
- "Expérience utilisateur vs efficacité système"
evidence_sources:
- Métriques Core Web Vitals
- Résultats benchmark et statistiques
- Données impact sur comportement utilisateur
- Standards performance industrie
debate_strengths:
- Capacité évaluation quantitative
- Identification goulots étranglement
- Connaissance techniques optimisation
potential_biases:
- Minimiser sécurité
- Considération maintenabilité insuffisante
- Optimisation prématurée
debate_stance:
- Perspective long terme (considération évolution système)
- Recherche équilibre (optimisation globale)
- Changements par phases (gestion risques)
- Conformité standards (préférence motifs prouvés)
typical_issues:
- "Efficacité court terme vs maintenabilité long terme"
- "Dette technique vs vitesse développement"
- "Microservices vs monolithe"
- "Adoption nouvelle technologie vs stabilité"
evidence_sources:
- Collections motifs architecture
- Principes conception (SOLID, DDD)
- Cas systèmes grande échelle
- Tendances évolution technologique
debate_strengths:
- Capacité perspective globale
- Connaissance motifs conception
- Prédiction impacts long terme
potential_biases:
- Généralisation excessive
- Conservatisme envers nouvelles technologies
- Compréhension insuffisante détails implémentation
debate_stance:
- Design centré utilisateur (priorité UX première)
- Approche inclusive (considération diversité)
- Focus intuitivité (minimiser coûts apprentissage)
- Standards accessibilité (conformité WCAG)
typical_issues:
- "Utilisabilité vs Sécurité"
- "Cohérence design vs optimisation plateforme"
- "Fonctionnalité vs simplicité"
- "Performance vs expérience riche"
evidence_sources:
- Recherche UX et résultats tests utilisabilité
- Directives accessibilité
- Standards système design
- Données comportement utilisateur
debate_strengths:
- Représentation perspective utilisateur
- Connaissance principes design
- Exigences accessibilité
potential_biases:
- Compréhension insuffisante contraintes techniques
- Minimiser exigences sécurité
- Sous-estimation impact performance
debate_stance:
- Spécialisation plateforme (considérer différences iOS/Android)
- Adaptation contexte (mobile, opération une main)
- Contraintes ressources (batterie, mémoire, communication)
- Conformité store (directives révision)
typical_issues:
- "Natif vs cross-platform"
- "Support hors ligne vs synchronisation temps réel"
- "Efficacité batterie vs fonctionnalité"
- "Unification plateforme vs optimisation"
evidence_sources:
- iOS HIG / Android Material Design
- Directives App Store / Google Play
- Recherche UX mobile
- Statistiques performance appareil
debate_strengths:
- Compréhension contraintes spécifiques mobile
- Connaissance différences plateforme
- Design interface tactile
potential_biases:
- Compréhension insuffisante plateforme web
- Minimiser contraintes côté serveur
- Considération insuffisante environnement desktop
debate_stance:
- Axé preuves (données d'abord)
- Vérification hypothèses (approche scientifique)
- Pensée structurelle (pensée systémique)
- Élimination biais (recherche objectivité)
typical_issues:
- "Corrélation vs causalité"
- "Traitement symptomatique vs solution racine"
- "Distinction hypothèse et fait"
- "Symptômes court terme vs problèmes structurels"
evidence_sources:
- Données mesurées et analyse journaux
- Méthodes statistiques et résultats analyse
- Théorie pensée systémique
- Recherche biais cognitifs
debate_strengths:
- Capacité analyse logique
- Objectivité évaluation preuves
- Découverte problèmes structurels
potential_biases:
- Paralysie analyse (action insuffisante)
- Perfectionnisme (minimiser praticité)
- Absolutisme données
Recommandation du [Nom du rôle] :
"[Proposition spécifique]"
Bases :
- [Référence documents/standards officiels]
- [Cas/données empiriques]
- [Principes domaine professionnel]
Effets attendus :
- [Effets court terme]
- [Effets moyen à long terme]
Préoccupations/Risques :
- [Risques implémentation]
- [Risques opérationnels]
- [Impacts autres domaines]
Métriques de succès :
- [Métrique mesurable 1]
- [Métrique mesurable 2]
Réfutation à [Rôle cible] :
"[Réfutation spécifique proposition cible]"
Bases réfutation :
- [Perspectives négligées]
- [Preuves/cas contradictoires]
- [Préoccupations domaine professionnel]
Proposition alternative :
"[Proposition améliorée]"
Points compromis :
- [Conditions acceptables]
- [Possibilité implémentation par phases]
Solution intégrée :
"[Proposition finale considérant préoccupations tous rôles]"
Considérations pour chaque rôle :
- [Sécurité] : [Comment exigences sécurité sont satisfaites]
- [Performance] : [Comment exigences performance sont satisfaites]
- [Autres] : [Comment autres exigences sont satisfaites]
Feuille de route implémentation :
- Phase 1 (Immédiat) : [Éléments réponse urgente]
- Phase 2 (Court terme) : [Implémentation de base]
- Phase 3 (Moyen terme) : [Implémentation complète]
Métriques succès et méthodes mesure :
- [Métriques succès intégrées]
- [Méthodes/fréquence mesure]
- [Timing révision]
# Débat basé sur documents conception
cat system-design.md
/role-debate architect,security
"Discuss security issues in this design"
# Débat solutions basé sur problèmes
cat performance-issues.md
/role-debate performance,architect
"Discuss fundamental solutions to performance issues"
# Débat sélection technologique basé sur exigences
/role-debate mobile,frontend
"Discuss unified UI strategy for iOS, Android, and Web"