Party Mode y Workflows Avanzados
Que es Party Mode
En los capitulos anteriores, cada agente trabajaba de forma secuencial: el Analyst genera el brief, el PM lo toma y crea el PRD, el Architect lo recibe y disena la arquitectura. Un agente a la vez, una fase a la vez.
Party Mode rompe esa secuencia. Permite que multiples agentes participen en una misma sesion de trabajo, colaborando en tiempo real sobre una decision o problema especifico.
Como funciona
En Party Mode, el BMad Master actua como orquestador. Cuando recibes un mensaje o planteas una pregunta, el Master analiza el contexto y selecciona 2-3 agentes relevantes para responder. No activa todos los agentes a la vez; eso seria ruido innecesario.
El flujo es:
- Tu planteas una pregunta o problema
- El BMad Master identifica que agentes son relevantes
- Cada agente responde desde su perspectiva y expertise
- Tu tomas la decision informada con multiples puntos de vista
Cuando usar Party Mode
- Decisiones tecnicas con impacto en producto (arquitectura que afecta UX)
- Trade-offs donde no hay respuesta “correcta” unica
- Refinamiento de requisitos ambiguos
- Evaluacion de riesgo antes de implementar features complejas
Cuando NO usar Party Mode
- Tareas mecanicas que un solo agente resuelve (escribir un test, corregir un bug)
- Fases bien definidas del Standard Flow (el PM no necesita ayuda del Developer para escribir el PRD)
- Preguntas con respuesta unica y clara
Ejemplo Practico: Drag & Drop en el Kanban
Veamos Party Mode en accion. Necesitamos decidir como implementar drag & drop en nuestro tablero Kanban. Parece una decision puramente tecnica, pero tiene implicaciones en producto, arquitectura, implementacion y calidad.
La pregunta
“Como implementamos drag & drop de tarjetas entre columnas en el Kanban?”
El BMad Master selecciona agentes
El Master activa: PM, Architect, Developer y QA. El Analyst no participa porque no es una decision de vision de producto.
Cada agente aporta su perspectiva
PM responde primero con los requisitos de producto:
- Debe funcionar en desktop y mobile (touch events)
- El usuario necesita feedback visual de donde puede soltar la tarjeta
- Si la conexion se pierde durante el drag, la tarjeta debe volver a su posicion original
- La operacion debe sentirse instantanea (actualizacion optimista)
Architect responde con opciones tecnicas:
- Opcion A:
@dnd-kit/core- libreria moderna, soporta touch, tree-shakeable, buen soporte de accesibilidad - Opcion B:
react-beautiful-dnd- mas madura pero ya no se mantiene activamente - Opcion C: HTML5 Drag and Drop API nativa - sin dependencias pero sin soporte touch nativo
- Recomienda Opcion A por alinearse con los requisitos del PM
Developer identifica limitaciones tecnicas:
- Con
@dnd-kitnecesitamos manejar el reordenamiento con indices fraccionales para evitar reindexar toda la columna en cada movimiento - El estado optimista requiere reconciliacion con el server response, lo que agrega complejidad al store
- Los sortables anidados (drag entre columnas) requieren configuracion adicional de collision detection
QA advierte sobre riesgos:
- Accesibilidad: el drag & drop debe ser operable por teclado (ARIA live regions, anuncios de screen reader)
- Testing:
@dnd-kitrequiere mocks especificos para tests, necesitamos verificar que la libreria tiene buena testability - Edge case: que pasa si dos usuarios mueven la misma tarjeta simultaneamente
El resultado
Con estas cuatro perspectivas, la decision es informada y documentada. Se elige @dnd-kit, se agregan los requisitos de accesibilidad como criterios de aceptacion, se documenta el approach de indices fraccionales y se crea una story especifica para el caso de concurrencia.
Sin Party Mode, probablemente el Developer habria elegido una libreria, se habria olvidado del soporte mobile, y el QA habria detectado los problemas de accesibilidad al final del ciclo.
Workflows Alternativos
El Standard Flow de 6 fases no es el unico camino. BMAD ofrece workflows alternativos para diferentes situaciones.
Quick Spec Flow
Para cambios pequenos que no justifican las 6 fases completas. Ideal para:
- Bug fixes con causa conocida
- Cambios de configuracion
- Ajustes de UI menores
- Hotfixes en produccion
El flujo simplificado:
Problema definido
→ Developer escribe spec minima
→ Developer implementa
→ QA valida (checklist reducido)Se saltan las fases de Analyst, PM, Architect y Scrum Master. El Developer trabaja directamente con una spec reducida que describe: que esta roto, cual es la causa, y como se corrige.
El QA usa un checklist reducido: solo verifica que el fix funciona, no introduce regresiones, y tiene test correspondiente.
Enterprise Compliance Flow
Para organizaciones que requieren auditoria, compliance o aprobaciones formales. Agrega capas sobre el Standard Flow:
Standard Flow
+ Security Auditor Agent (revisa antes del QA)
+ Compliance gates (aprobaciones entre fases)
+ Documentacion de auditoria automatica
+ Code review formal (no solo QA)Security Auditor Agent: un agente especializado que revisa exclusivamente aspectos de seguridad. Analiza dependencias contra bases de vulnerabilidades, verifica patrones de autenticacion/autorizacion y genera reportes de compliance.
Gates de aprobacion: entre cada fase, se requiere una aprobacion explicita antes de avanzar. Esto genera un trail de auditoria completo.
Documentacion automatica: cada decision, cada artefacto y cada aprobacion se documenta automaticamente para auditorias futuras.
Este flow es mas lento pero necesario en contextos regulados (fintech, healthcare, gobierno).
BMad Builder: Agentes Custom
BMAD no esta limitado a los 6 agentes predefinidos. Con el BMad Builder, puedes crear agentes especializados para tu contexto.
Donde viven los agentes custom
Los agentes se definen en _bmad/agents/ como archivos markdown con una estructura especifica:
_bmad/agents/
performance-analyst.md
ux-reviewer.md
data-modeler.mdEjemplo: Crear un Performance Analyst
Un agente custom tiene tres secciones:
Identidad: quien es y cual es su expertise.
# Performance Analyst Agent
## Role
Especialista en performance de aplicaciones web.
Analiza metricas, identifica bottlenecks y sugiere optimizaciones.
## Expertise
- Core Web Vitals (LCP, FID, CLS)
- Database query optimization
- Bundle size analysis
- Runtime performance profilingInstrucciones: como debe comportarse y que herramientas usa.
## Instructions
- Analizar cada endpoint por tiempo de respuesta esperado
- Verificar que los componentes criticos usen lazy loading
- Revisar queries por patrones N+1
- Sugerir indices de base de datos basados en query patterns
- Reportar metricas con benchmarks de referenciaInteracciones: como se relaciona con otros agentes.
## Interactions
- Recibe: architecture.md del Architect
- Produce: performance-report.md
- Colabora con: Developer (optimizaciones), QA (tests de carga)Una vez creado, el agente esta disponible en Party Mode y puede ser invocado explicitamente en cualquier fase del workflow.
Modulos Oficiales de BMAD
BMAD ofrece modulos que extienden la funcionalidad base. Los principales son:
| Modulo | Nombre | Funcion |
|---|---|---|
| BMM | BMad Master Module | Orquestador de agentes y selector de workflows |
| BMB | BMad Builder | Creacion y configuracion de agentes custom |
| TEA | Task Execution Agent | Ejecuta tareas atomicas dentro de stories |
| BMGD | BMad Guideline Docs | Documentacion y templates de referencia |
| CIS | Context Intelligence System | Gestion inteligente de contexto entre sesiones |
CIS: Context Intelligence System
Merece mencion especial. CIS resuelve el problema de la ventana de contexto limitada de los LLMs. Cuando un proyecto crece, no cabe todo en una sola sesion.
CIS gestiona:
- Que artefactos cargar para cada fase
- Resumen automatico de contexto previo
- Priorizacion de informacion relevante segun la tarea actual
- Versionado de contexto entre sesiones
Integracion con IDEs
BMAD funciona en cualquier IDE agentico, pero tiene optimizaciones especificas para los mas populares.
Cursor con Composer Mode
Cursor ofrece un “Composer Mode” que permite interacciones de largo alcance. BMAD lo aprovecha para:
- Sesiones completas de una fase (ej: toda la fase de Architect en una sesion de Composer)
- Party Mode usando el contexto extendido de Composer
- Aplicacion de cambios en multiples archivos simultaneamente
Claude Code con slash commands
Claude Code permite definir comandos personalizados que mapean directamente a agentes BMAD:
- Invocacion directa de agentes especificos
- Carga automatica de artefactos relevantes via CLAUDE.md
- Ejecucion de workflows desde la terminal
Principio general
Independientemente del IDE, BMAD funciona porque sus artefactos son archivos markdown y JSON en el repositorio. Cualquier herramienta que pueda leer archivos y generar texto puede ejecutar BMAD. El IDE solo facilita la interaccion.
Resumen del capitulo
Party Mode transforma BMAD de un pipeline secuencial a un sistema colaborativo. Los workflows alternativos (Quick Spec, Enterprise) adaptan el proceso al tamano del problema. Los agentes custom y modulos oficiales permiten extender BMAD segun las necesidades del equipo.
La clave es usar el workflow correcto para cada situacion. No todo necesita las 6 fases, y no toda decision necesita Party Mode. La madurez con BMAD viene de saber cuando usar cada herramienta.