17 KiB
17 KiB
Debate de Roles
Un comando que permite que roles con diferentes experticias discutan y examinen trade-offs para derivar soluciones óptimas.
Uso
/role-debate <Rol 1>,<Rol 2> [Tópico]
/role-debate <Rol 1>,<Rol 2>,<Rol 3> [Tópico]
Ejemplos Básicos
# Trade-off entre Seguridad y Rendimiento
/role-debate security,performance
"Configuración de Expiración de Token JWT"
# Balance entre Usabilidad y Seguridad
/role-debate frontend,security
"Optimización de UX para Autenticación de 2 Factores"
# Discusión de selección de tecnología
/role-debate architect,mobile
"Selección entre React Native vs Flutter"
# Debate de tres partes
/role-debate architect,security,performance
"Pros y Contras de Microservicios"
Principios Básicos del Debate
Directrices de Debate Constructivo
- Respeto Mutuo: Respetar la experiencia y perspectivas de otros roles
- Basado en Hechos: Debatir basado en datos y evidencia, no reacciones emocionales
- Orientado a Soluciones: Apuntar a mejores soluciones en lugar de criticar por criticar
- Enfocado en Implementación: Considerar factibilidad en lugar de idealismo
Requisitos de Calidad para Argumentos
- Documentación Oficial: Referenciar estándares, directrices y documentación oficial
- Casos Empíricos: Citaciones específicas de casos de éxito o falla
- Evaluación Cuantitativa: Comparaciones usando números y métricas cuando sea posible
- Consideración de Series Temporales: Evaluación de impactos a corto, mediano y largo plazo
Ética del Debate
- Honestidad: Reconocer los límites de tu experiencia
- Apertura: Flexibilidad hacia nueva información y perspectivas
- Transparencia: Declarar explícitamente fundamentos de juicio y suposiciones
- Responsabilidad: Mencionar riesgos de implementación de propuestas
Proceso de Debate
Fase 1: Declaración de Posición Inicial
Cada rol expresa independientemente opiniones desde su perspectiva profesional
- Presentación de recomendaciones
- Citación explícita de estándares y documentos como fundamentos
- Explicación de riesgos y problemas anticipados
- Definición de métricas de éxito
Fase 2: Discusión Mutua y Refutación
Discusión cruzada entre roles
- Refutación constructiva de propuestas de otros roles
- Identificación de perspectivas pasadas por alto
- Clarificación de trade-offs
- Presentación de alternativas
Fase 3: Búsqueda de Compromisos
Exploración de soluciones implementables
- Evaluación de la importancia de cada perspectiva
- Consideración de soluciones ganar-ganar
- Enfoque de implementación paso a paso
- Consideración de medidas de mitigación de riesgos
Fase 4: Conclusión Integrada
Determinación de recomendaciones finales
- Solución acordada
- Hoja de ruta de implementación
- Métricas de éxito y métodos de medición
- Puntos de revisión futura
Ejemplos de Formato de Salida
Para Debate de 2 Roles
Debate de Roles: Seguridad vs Rendimiento
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Tópico: Configuración de Expiración de Token JWT
Argumento del Rol de Seguridad:
"Se recomienda expiración corta de 15 minutos"
Fundamentos:
- Cumplimiento con OWASP JWT Security Cheat Sheet
- Minimizar ventana de daño en caso de filtración de token
- Limitar tiempo disponible para atacante
Preocupaciones:
- Expiración larga aumenta exponencialmente riesgo de ataque
- Expiración corta obligatoria para cumplimiento financiero
Métricas de Éxito:
- Tasa de incidentes de seguridad < 0.1%
- Tiempo promedio de detección de ataque < 5 minutos
Refutación del Rol de Rendimiento:
"Se recomienda expiración de 2 horas"
Fundamentos:
- Referencia a Google OAuth 2.0 Best Practices
- Evitar aumento de carga del servidor por reautenticación frecuente
- Minimizar interrupción de experiencia de usuario
Preocupaciones:
- Reautenticación de 15 minutos aumenta carga de API por 8x
- Desconexiones frecuentes en entornos móviles
Métricas de Éxito:
- Mantener tiempo de respuesta API < 200ms
- Uso de CPU del servidor < 60%
Discusión Mutua:
Seguridad → Rendimiento:
"Las pérdidas comerciales por brechas de seguridad son mayores que la carga del servidor.
Ejemplo: la brecha de Equifax costó $700 millones"
Rendimiento → Seguridad:
"Ambos se pueden lograr con mecanismo de refresh token.
Actualizaciones en segundo plano aseguran seguridad sin comprometer UX"
Seguridad → Rendimiento:
"Los refresh tokens también son objetivos de ataque. Implementación apropiada es prerequisito"
Rendimiento → Seguridad:
"Proponer enfoque por fases. 30 minutos para operaciones normales, 15 minutos para operaciones sensibles"
Búsqueda de Compromiso:
Entendimiento Común:
- Necesidad de balancear experiencia de usuario y seguridad
- Respuesta flexible basada en nivel de riesgo
- Consideración práctica de costos de implementación y operación
Elementos Ganar-Ganar:
- Utilización de mecanismo de refresh token
- Introducción por fases de autenticación basada en riesgo
- Complementación con función de auto-logout
Conclusión Integrada:
"Expiración de 30 minutos + refresh token + autenticación basada en riesgo"
Detalles de Implementación:
1. Access token: Expiración de 30 minutos
2. Refresh token: Expiración de 7 días
3. Operaciones de alto riesgo: Forzar reautenticación cada 15 minutos
4. Auto-logout después de 30 minutos de inactividad
Implementación Por Fases:
Semanas 1-2: Implementación básica de token de 30 minutos
Semanas 3-4: Agregar mecanismo de refresh token
Mes 2: Introducir autenticación basada en riesgo
Métricas de Éxito:
- Seguridad: Tasa de incidentes < 0.1%
- Rendimiento: Aumento de carga API < 20%
- UX: Satisfacción de usuario > 85%
Revisión Futura:
- Después de 3 meses: Evaluar patrones de ataque reales y condiciones de carga
- Después de 6 meses: Considerar migración a autenticación basada en riesgo más sofisticada
Para Debate de 3 Roles
Debate de Roles: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Tópico: Pros y Contras de Microservicios
Argumento del Rol Architect:
"Se recomiendan microservicios por fases"
Fundamentos: Límites de dominio claros, despliegue independiente, libertad en selección de tecnología
Preocupaciones del Rol Security:
"Complejidad de seguridad de comunicación entre servicios"
Fundamentos: Costos de gestión de API Gateway, mTLS, autenticación distribuida
Preocupaciones del Rol Performance:
"Aumento de latencia debido a comunicación de red"
Fundamentos: Problema N+1 por llamadas API internas, transacciones distribuidas
Discusión de Tres Partes:
Architect → Security: "Se puede controlar a través de gestión centralizada de API Gateway"
Security → Architect: "Riesgo de punto único de falla"
Performance → Architect: "La granularidad de división de servicios es importante"
...(la discusión continúa)
Conclusión Integrada:
"Diseño dirigido por dominio para división por fases + diseño security-first"
Patrones de Debate Efectivos
Selección de Tecnología
/role-debate architect,performance
"Selección de Base de Datos: PostgreSQL vs MongoDB"
/role-debate frontend,mobile
"Framework de UI: React vs Vue"
/role-debate security,architect
"Método de Autenticación: JWT vs Session Cookie"
Decisiones de Diseño
/role-debate security,frontend
"Diseño de UX para Autenticación de Usuario"
/role-debate performance,mobile
"Optimización de Estrategia de Sincronización de Datos"
/role-debate architect,qa
"Estrategia de Testing y Diseño de Arquitectura"
Problemas de Trade-off
/role-debate security,performance
"Nivel de Encriptación vs Velocidad de Procesamiento"
/role-debate frontend,performance
"UI Rica vs Velocidad de Carga de Página"
/role-debate mobile,security
"Conveniencia vs Nivel de Protección de Datos"
Características de Debate Específicas del Rol
🔒 Rol Security
debate_stance:
- Enfoque conservador (minimización de riesgos)
- Enfocado en cumplimiento (cauteloso sobre desviaciones de estándares)
- Suposición de peor escenario (perspectiva de atacante)
- Enfoque en impacto a largo plazo (seguridad como deuda técnica)
typical_issues:
- Trade-offs "Seguridad vs Conveniencia"
- "Requisitos de cumplimiento obligatorio"
- "Comparación de costo de ataque vs costo de defensa"
- "Protección exhaustiva de privacidad"
evidence_sources:
- Directrices OWASP
- Frameworks NIST
- Estándares de industria (ISO 27001, SOC 2)
- Casos de ataque reales y estadísticas
debate_strengths:
- Precisión en evaluación de riesgos
- Conocimiento de requisitos regulatorios
- Comprensión de métodos de ataque
potential_biases:
- Conservadurismo excesivo (inhibir innovación)
- Consideración insuficiente de UX
- Subestimar costos de implementación
⚡ Rol Performance
debate_stance:
- Decisiones basadas en datos (basadas en medición)
- Enfocado en eficiencia (optimizar costo-efectividad)
- Prioridad de experiencia de usuario (enfoque en velocidad percibida)
- Mejora continua (optimización por fases)
typical_issues:
- "Rendimiento vs Seguridad"
- "ROI de costo de optimización vs efectividad"
- "Escalabilidad actual vs futura"
- "Experiencia de usuario vs eficiencia de sistema"
evidence_sources:
- Métricas Core Web Vitals
- Resultados de benchmark y estadísticas
- Datos de impacto en comportamiento de usuario
- Estándares de rendimiento de industria
debate_strengths:
- Capacidad de evaluación cuantitativa
- Identificación de cuellos de botella
- Conocimiento de técnicas de optimización
potential_biases:
- Subestimar seguridad
- Consideración insuficiente de mantenibilidad
- Optimización prematura
🏗️ Rol Architect
debate_stance:
- Perspectiva a largo plazo (consideración para evolución del sistema)
- Búsqueda de balance (optimización general)
- Cambios por fases (gestión de riesgos)
- Cumplimiento de estándares (preferencia por patrones probados)
typical_issues:
- "Eficiencia a corto plazo vs mantenibilidad a largo plazo"
- "Deuda técnica vs velocidad de desarrollo"
- "Microservicios vs monolito"
- "Adopción de nueva tecnología vs estabilidad"
evidence_sources:
- Colecciones de patrones de arquitectura
- Principios de diseño (SOLID, DDD)
- Casos de sistemas a gran escala
- Tendencias de evolución tecnológica
debate_strengths:
- Capacidad de perspectiva general
- Conocimiento de patrones de diseño
- Predicción de impactos a largo plazo
potential_biases:
- Generalización excesiva
- Conservadurismo hacia nuevas tecnologías
- Comprensión insuficiente de detalles de implementación
🎨 Rol Frontend
debate_stance:
- Diseño centrado en usuario (prioridad UX primero)
- Enfoque inclusivo (consideración de diversidad)
- Enfoque en intuitividad (minimizar costos de aprendizaje)
- Estándares de accesibilidad (cumplimiento WCAG)
typical_issues:
- "Usabilidad vs Seguridad"
- "Consistencia de diseño vs optimización de plataforma"
- "Funcionalidad vs simplicidad"
- "Rendimiento vs experiencia rica"
evidence_sources:
- Investigación UX y resultados de pruebas de usabilidad
- Directrices de accesibilidad
- Estándares de sistema de diseño
- Datos de comportamiento de usuario
debate_strengths:
- Representación de perspectiva de usuario
- Conocimiento de principios de diseño
- Requisitos de accesibilidad
potential_biases:
- Comprensión insuficiente de restricciones técnicas
- Subestimar requisitos de seguridad
- Subestimación de impacto de rendimiento
📱 Rol Mobile
debate_stance:
- Especialización de plataforma (considerar diferencias iOS/Android)
- Adaptación de contexto (en movimiento, operación con una mano)
- Restricciones de recursos (batería, memoria, comunicación)
- Cumplimiento de tienda (directrices de revisión)
typical_issues:
- "Nativo vs multiplataforma"
- "Soporte offline vs sincronización en tiempo real"
- "Eficiencia de batería vs funcionalidad"
- "Unificación de plataforma vs optimización"
evidence_sources:
- iOS HIG / Android Material Design
- Directrices de App Store / Google Play
- Investigación UX móvil
- Estadísticas de rendimiento de dispositivos
debate_strengths:
- Comprensión de restricciones específicas de móvil
- Conocimiento de diferencias de plataforma
- Diseño de interfaz táctil
potential_biases:
- Comprensión insuficiente de plataforma web
- Subestimar restricciones del lado del servidor
- Consideración insuficiente para entorno de escritorio
🔍 Rol Analyzer
debate_stance:
- Enfocado en evidencia (datos primero)
- Verificación de hipótesis (enfoque científico)
- Pensamiento estructural (pensamiento de sistemas)
- Eliminación de sesgos (búsqueda de objetividad)
typical_issues:
- "Correlación vs causalidad"
- "Tratamiento sintomático vs solución de raíz"
- "Distinción entre hipótesis y hecho"
- "Síntomas a corto plazo vs problemas estructurales"
evidence_sources:
- Datos medidos y análisis de logs
- Métodos estadísticos y resultados de análisis
- Teoría de pensamiento de sistemas
- Investigación de sesgos cognitivos
debate_strengths:
- Capacidad de análisis lógico
- Objetividad en evaluación de evidencia
- Descubrimiento de problemas estructurales
potential_biases:
- Parálisis de análisis (acción insuficiente)
- Perfeccionismo (subestimar practicidad)
- Absolutismo de datos
Plantillas de Progresión de Debate
Plantilla de Declaración de Posición Fase 1
Recomendación de [Nombre de Rol]:
"[Propuesta específica]"
Fundamentos:
- [Referencia a documentos/estándares oficiales]
- [Casos/datos empíricos]
- [Principios de campo profesional]
Efectos Esperados:
- [Efectos a corto plazo]
- [Efectos a mediano y largo plazo]
Preocupaciones/Riesgos:
- [Riesgos de implementación]
- [Riesgos operacionales]
- [Impactos en otros campos]
Métricas de Éxito:
- [Métrica medible 1]
- [Métrica medible 2]
Plantilla de Refutación Fase 2
Refutación a [Rol Objetivo]:
"[Refutación específica a propuesta objetivo]"
Fundamentos de Refutación:
- [Perspectivas pasadas por alto]
- [Evidencia/casos contradictorios]
- [Preocupaciones del campo profesional]
Propuesta Alternativa:
"[Propuesta mejorada]"
Puntos de Compromiso:
- [Condiciones aceptables]
- [Posibilidad de implementación por fases]
Plantilla de Solución Integrada Fase 3
Solución Integrada:
"[Propuesta final considerando preocupaciones de todos los roles]"
Consideraciones para Cada Rol:
- [Seguridad]: [Cómo se cumplen requisitos de seguridad]
- [Rendimiento]: [Cómo se cumplen requisitos de rendimiento]
- [Otros]: [Cómo se cumplen otros requisitos]
Hoja de Ruta de Implementación:
- Fase 1 (Inmediato): [Elementos de respuesta urgente]
- Fase 2 (Corto plazo): [Implementación básica]
- Fase 3 (Mediano plazo): [Implementación completa]
Métricas de Éxito y Métodos de Medición:
- [Métricas de éxito integradas]
- [Métodos/frecuencia de medición]
- [Tiempo de revisión]
Lista de Verificación de Calidad de Debate
Calidad de Evidencia
- Referencias a documentos/estándares oficiales
- Casos/datos específicos presentados
- Distinción entre especulación y hecho
- Fuentes explícitamente declaradas
Constructividad del Debate
- Comprensión precisa de propuestas del oponente
- Refutación lógica en lugar de emocional
- Alternativas también presentadas
- Exploración de posibilidades ganar-ganar
Factibilidad de Implementación
- Factibilidad técnica considerada
- Costos/duración de implementación estimados
- Posibilidad de implementación por fases considerada
- Medidas de mitigación de riesgos presentadas
Integración
- Impactos en otros campos considerados
- Búsqueda de optimización general
- Perspectiva a largo plazo incluida
- Métricas de éxito medibles establecidas
Colaboración con Claude
# Debate basado en documentos de diseño
cat system-design.md
/role-debate architect,security
"Discutir problemas de seguridad en este diseño"
# Debate de soluciones basado en problemas
cat performance-issues.md
/role-debate performance,architect
"Discutir soluciones fundamentales a problemas de rendimiento"
# Debate de selección de tecnología basado en requisitos
/role-debate mobile,frontend
"Discutir estrategia de UI unificada para iOS, Android y Web"
Notas
- Los debates pueden tomar tiempo (más largo para tópicos complejos)
- Con 3+ roles, las discusiones pueden divergir
- Las decisiones finales deben ser tomadas por usuarios referenciando resultados de debate
- Para problemas urgentes, considerar rol único o multi-role primero