Un comando que permite que roles con diferentes experticias discutan y examinen trade-offs para derivar soluciones óptimas.
Facilitates expert role-based debates to derive optimal solutions through structured trade-off analysis.
/plugin marketplace add wasabeef/claude-code-cookbook/plugin install cook-es@claude-code-cookbookUn comando que permite que roles con diferentes experticias discutan y examinen trade-offs para derivar soluciones óptimas.
/role-debate <Rol 1>,<Rol 2> [Tópico]
/role-debate <Rol 1>,<Rol 2>,<Rol 3> [Tópico]
# 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"
Cada rol expresa independientemente opiniones desde su perspectiva profesional
Discusión cruzada entre roles
Exploración de soluciones implementables
Determinación de recomendaciones finales
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
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"
/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"
/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"
/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"
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
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
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
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
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
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
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]
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]
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]
# 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"