curiositech/windags-skills

Coordinación de Calendarios con Agentes

Construye agentes de IA que negocien reuniones, protejan el tiempo de enfoque e infieran contexto a partir de datos del calendario. Navega por la complejidad de los husos horarios, implementa programación agente a agente y arquitectura lógica de calendario personalizada usando la API de Google Calendar y MCP.

Puntos de Decisión

Cuando se Detecta un Conflicto

Solicitud de reunión entrante entra en conflicto con evento existente
├─ Remitente = gerente/ejecutivo → Aceptar automáticamente, sugerir mover el evento existente
├─ Reunión = 1:1/etiquetada como urgente → Proponer alternativa dentro de 24h
├─ Colisión con bloque de enfoque
│  ├─ Prioridad del bloque = alta (trabajo profundo) → Rechazar automáticamente
│  └─ Prioridad del bloque = media → Proponer horario alternativo
└─ Doble reserva con reunión de compañeros → Contraofertar con 3 franjas horarias alternativas

Decisión: Rechazar Automáticamente vs. Proponer Alternativa

Factores: nivel_remitente (ejecutivo/gerente/compañero/externo) × tipo_reunión (1:1/equipo/todos) × prioridad_bloque_enfoque
Si ejecutivo + cualquier_tipo → Siempre proponer alternativa
Si gerente + (1:1 O urgente) → Proponer alternativa
Si compañero + recurrente + baja_asistencia → Rechazar automáticamente
Si externo + sin_relación_previa → Rechazar automáticamente con "usar enlace de calendario"
Si durante bloque_de_enfoque_alta_prioridad → Rechazar automáticamente sin importar el remitente

Selección de Franja Horaria con Conocimiento de Husos Horarios

Programación con múltiples participantes:
├─ Todos en el mismo huso horario → Usar horario laboral local (9-17)
├─ 2 husos horarios, <6h de diferencia → Encontrar ventana de superposición
├─ 2 husos horarios, >6h de diferencia → División temprano/tarde (uno toma las 8am, el otro las 6pm)
└─ 3+ husos horarios → Proponer alternativa asíncrona O horario rotativo

Clasificación de Franjas según Modelo de Energía

Prioridad del momento del día (descendente):
1. 9-11 AM (pico cognitivo) → Reservar para trabajo profundo, rechazar reuniones rutinarias
2. 11 AM-12 PM (enfoque sostenido) → Permitir solo reuniones importantes
3. 2-4 PM (punto dulce de colaboración) → Preferir para reuniones de equipo
4. 4-5 PM (cierre) → Bueno para 1:1s, actualizaciones de estado
5. 1-2 PM (bajón post-comida) → Evitar reuniones complejas

Modos de Falla

Conflictos Recurrentes con Huso Horario

Síntomas: La reunión semanal de las 9 AM muestra conflictos en invierno pero no en verano; la recurrencia entre husos horarios falla después del cambio de horario de verano (DST). Detección: if evento_recurrente && conversión_huso_horario && patrón_conflicto_estacional Solución: Siempre expandir los eventos recurrentes con singleEvents: true, convertir cada instancia a UTC para la verificación de conflictos, reevaluar después de las transiciones de DST.

Oscilación en la Aplicación de Bloques de Amortiguación

Síntomas: El agente reprograma repetidamente la misma reunión para crear bloques de amortiguación; las reuniones saltan entre franjas horarias. Detección: if misma_reunión_reprogramada > 2 veces en 24h por_razones_de_amortiguación Solución: Bloquear la reunión después de la primera reprogramación, ajustar los requisitos de amortiguación dinámicamente según la importancia de la reunión.

Arranque en Frío del Modelo de Energía

Síntomas: El agente nuevo programa reuniones en los peores momentos cognitivos del usuario; ignora los patrones establecidos. Detección: if puntuación_satisfacción_reunión < 3 para_reuniones_programadas_por_agente Solución: Inicializar con preferencias explícitas del usuario, aprender de los patrones de rechazo, requerir un período de observación de 2 semanas antes de la programación automática.

Fuga de Privacidad por Hinchazón del Esquema

Síntomas: El agente comparte demasiados detalles del calendario con sistemas externos; las descripciones de eventos se filtran a los LLMs. Detección: if llamada_api_externa contiene evento.descripción O asistente.email Solución: Implementar una capa de minimización de datos, eliminar PII antes de las llamadas externas, usar solo libre/ocupado para la programación.

Bucle de Negociación Recursiva

Síntomas: Dos agentes se contraproponen sin fin; no hay convergencia en una hora de reunión. Detección: if rondas_negociación > 3 && sin_franja_aceptada Solución: Escalar a humano después de 2 contraofertas, implementar un umbral de aceptación "suficientemente bueno", limitar la negociación en el tiempo.

Ejemplos Prácticos

Negociación de Reunión entre Husos Horarios

Escenario: Tu agente (Chicago) necesita 30 minutos con el agente de un compañero (Tokio) para una revisión de API. Ambos tienen restricciones energéticas.

Paso 1: Análisis Inicial

• Chicago: 9 AM-5 PM CST = 12 AM-6 AM JST (día siguiente)
• Tokio: 9 AM-6 PM JST = 7 PM-4 AM CST (día anterior)
• Ventana de superposición: 7-8 PM CST = 9-10 AM JST

Paso 2: Verificación del Modelo de Energía

• Chicago 7 PM = fin de la jornada laboral (energía: 6/10)
• Tokio 9 AM = horas pico cognitivas (energía: 9/10)
• Desequilibrio detectado → Se necesita un compromiso

Paso 3: Generación de Propuesta

Agente Chicago → Agente Tokio: PROPONER
Franjas: [
  "2024-03-19T01:00Z" (Chi: 7PM, Tok: 10AM),
  "2024-03-19T23:00Z" (Chi: 5PM, Tok: 8AM),
  "2024-03-20T00:00Z" (Chi: 6PM, Tok: 9AM)
]
Prioridad: normal
Tema: "Revisión de API - discusión sobre complejidad de husos horarios"

Paso 4: Contrapropuesta

Agente Tokio → Agente Chicago: CONTRAOFERTA
Motivo: "Preferir mañana más tarde en Tokio para discusión técnica compleja"
Alternativas: [
  "2024-03-19T02:00Z" (Chi: 8PM, Tok: 11AM),
  "2024-03-20T01:00Z" (Chi: 7PM, Tok: 10AM)
]
Restricciones: "Necesito 15 minutos de amortiguación antes de la reunión diaria de las 11:30 AM JST"

Paso 5: Resolución El agente de Chicago acepta la franja de las 8 PM CST / 11 AM JST, crea el evento con ambos husos horarios en la descripción: "Revisión de API - 8:00 PM CST / 11:00 AM JST+1"

Principiante vs Experto:

• Principiante: Programa en un horario conveniente para Chicago sin verificar las horas cognitivas de Tokio
• Experto: Reconoce el desequilibrio energético, propone al final del día en Chicago cuando Tokio está fresco

Puertas de Calidad

• Todas las marcas de tiempo almacenadas en UTC internamente, convertidas solo en los límites de visualización/API
• Nombres de huso horario IANA utilizados en todo momento (sin cadenas de desplazamiento UTC como "-05:00")
• Las consultas de libre/ocupado eliminan los detalles del evento, compartiendo solo bloques de tiempo con agentes externos
• La aplicación de amortiguación crea un mínimo de 10-15 minutos entre reuniones consecutivas
• Los bloques de enfoque se marcan como "ocupado" pero con menor prioridad que las reuniones reales para la negociación
• El modelo de energía considera las horas pico cognitivas del usuario y los patrones de fatiga de reuniones
• Los tokens OAuth están cifrados en reposo con un flujo de actualización automática implementado
• La limitación de velocidad maneja las cuotas de la API de Google Calendar con retroceso exponencial
• Los eventos recurrentes se expanden a instancias individuales antes de la detección de conflictos
• La fusión de múltiples calendarios se prueba en calendarios personales y laborales con diferentes permisos
• Las negociaciones de agentes tienen límite de tiempo con escalada humana después de rondas fallidas
• El registro de auditoría captura todas las mutaciones del calendario con capacidad de reversión

Límites (NO APLICA PARA)

Este skill NO es para:

• Construir componentes de interfaz de usuario de calendario → Usa form-validation-architect
• Diagramas de Gantt de proyectos o seguimiento de hitos → Usa project-management-guru-adhd
• Temporizadores Pomodoro o aplicaciones de seguimiento de tiempo → Usa adhd-daily-planner
• Patrones generales de arquitectura de agentes → Usa agentic-patterns
• Construir el marco base del agente → Usa agent-creator

Delegar a otros skills cuando:

• El usuario necesita gestión del tiempo específica para TDAH → adhd-daily-planner
• Construir memoria persistente del agente → always-on-agent-architecture
• Coordinación multiagente más allá del calendario → multi-agent-coordination
• Arquitectura de demonio en segundo plano → daemon-development

Este skill se enfoca específicamente en estructuras de datos de calendario, algoritmos de programación y lógica de coordinación de reuniones.