572 lines
16 KiB
Markdown
572 lines
16 KiB
Markdown
## Role Debate
|
|
|
|
Une commande qui permet aux rôles avec différentes expertises de discuter et examiner les compromis pour dériver des solutions optimales.
|
|
|
|
### Utilisation
|
|
|
|
```bash
|
|
/role-debate <Rôle 1>,<Rôle 2> [Sujet]
|
|
/role-debate <Rôle 1>,<Rôle 2>,<Rôle 3> [Sujet]
|
|
```
|
|
|
|
### Exemples de base
|
|
|
|
```bash
|
|
# 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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```bash
|
|
/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
|
|
|
|
```bash
|
|
/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
|
|
|
|
```bash
|
|
/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é
|
|
|
|
```yaml
|
|
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
|
|
|
|
```yaml
|
|
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
|
|
|
|
```yaml
|
|
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
|
|
|
|
```yaml
|
|
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
|
|
|
|
```yaml
|
|
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
|
|
|
|
```yaml
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```bash
|
|
# 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
|