wasabeef Débat multi-rôle pour explorer les compromis
Une commande qui permet aux rôles avec différentes expertises de discuter et examiner les compromis pour dériver des solutions optimales.
Utilisation
/role-debate <Rôle 1>,<Rôle 2> [Sujet]
/role-debate <Rôle 1>,<Rôle 2>,<Rôle 3> [Sujet]
Exemples de base
# 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"
Principes de base du débat
Directives de débat constructif
- Respect mutuel : Respecter l'expertise et les perspectives des autres rôles
- Basé sur les faits : Débattre basé sur des données et preuves, pas des réactions émotionnelles
- Orienté solutions : Viser de meilleures solutions plutôt que critiquer pour critiquer
- Axé implémentation : Considérer la faisabilité plutôt que l'idéalisme
Exigences de qualité pour les arguments
- Documentation officielle : Référencer standards, directives et documentation officielle
- Cas empiriques : Citations spécifiques de cas de succès ou d'échec
- Évaluation quantitative : Comparaisons utilisant nombres et métriques quand possible
- Considération temporelle : Évaluation des impacts court, moyen et long termes
Éthique du débat
- Honnêteté : Reconnaître les limites de votre expertise
- Ouverture : Flexibilité vers nouvelles informations et perspectives
- Transparence : Déclarer explicitement les bases de jugement et hypothèses
- Responsabilité : Mentionner les risques d'implémentation des propositions
Processus de débat
Phase 1 : Déclaration de position initiale
Chaque rôle exprime indépendamment des opinions depuis leur perspective professionnelle
- Présentation de recommandations
- Citation explicite de standards et documents comme bases
- Explication des risques et questions anticipés
- Définition des métriques de succès
Phase 2 : Discussion mutuelle et réfutation
Discussion croisée entre rôles
- Réfutation constructive des propositions d'autres rôles
- Identification de perspectives négligées
- Clarification des compromis
- Présentation d'alternatives
Phase 3 : Recherche de compromis
Exploration de solutions implémentables
- Évaluation de l'importance de chaque perspective
- Considération de solutions gagnant-gagnant
- Approche d'implémentation étape par étape
- Considération de mesures de mitigation des risques
Phase 4 : Conclusion intégrée
Détermination des recommandations finales
- Solution convenue
- Feuille de route d'implémentation
- Métriques de succès et méthodes de mesure
- Points de révision futurs
Exemples de format de sortie
Pour un débat à 2 rôles
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
Pour un débat à 3 rôles
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"
Motifs de débat efficaces
Sélection technologique
/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"
Décisions de conception
/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"
Questions de compromis
/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"
Caractéristiques de débat spécifiques aux rôles
🔒 Rôle Sécurité
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
⚡ Rôle Performance
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
🏗️ Rôle Architecte
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
🎨 Rôle Frontend
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
📱 Rôle Mobile
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
🔍 Rôle Analyste
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
Modèles de progression de débat
Phase 1 : Modèle déclaration position
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]
Phase 2 : Modèle réfutation
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]
Phase 3 : Modèle solution intégrée
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]
Liste de vérification qualité débat
Qualité preuves
- Références documents/standards officiels
- Cas/données spécifiques présentés
- Distinction spéculation et fait
- Sources explicitement déclarées
Constructivité débat
- Compréhension précise propositions adversaire
- Réfutation logique plutôt qu'émotionnelle
- Alternatives aussi présentées
- Exploration possibilités gagnant-gagnant
Faisabilité implémentation
- Faisabilité technique considérée
- Coûts/durée implémentation estimés
- Possibilité implémentation par phases considérée
- Mesures mitigation risques présentées
Intégration
- Impacts autres domaines considérés
- Recherche optimisation globale
- Perspective long terme incluse
- Métriques succès mesurables définies
Collaboration avec Claude
# 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"
Notes
- Les débats peuvent prendre du temps (plus long pour sujets complexes)
- Avec 3+ rôles, discussions peuvent diverger
- Décisions finales devraient être prises par utilisateurs référençant résultats débat
- Pour questions urgentes, considérer rôle unique ou multi-rôle d'abord