Initial commit
This commit is contained in:
Zhongwei Li
571
commands/role-debate.md
Normal file
571
commands/role-debate.md
Normal file
@@ -0,0 +1,571 @@
|
||||
## 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
|
||||
Reference in New Issue
Block a user