curiositech/windags-skills

Coordination Calendaire Agentique

Construisez des agents IA qui négocient des réunions, protègent les plages de concentration et infèrent le contexte à partir des données de calendrier. Naviguez dans la complexité des fuseaux horaires, mettez en œuvre la planification agent-à-agent et architectez une logique calendaire personnalisée à l'aide de l'API Google Agenda et de MCP.

Points de Décision

Lorsqu'un Conflit est Détecté

Demande de réunion entrante en conflit avec un événement existant
├─ Expéditeur = manager/dirigeant → Accepter automatiquement, suggérer de déplacer l'existant
├─ Réunion = marquée comme 1:1/urgente → Proposer une alternative dans les 24h
├─ Collision avec un bloc de concentration
│  ├─ Priorité du bloc = élevée (travail profond) → Refuser automatiquement
│  └─ Priorité du bloc = moyenne → Proposer une alternative horaire
└─ Double réservation avec une réunion de pair → Contre-proposer 3 créneaux alternatifs

Décision : Refus Automatique vs. Proposition d'Alternative

Facteurs : niveau_expéditeur (dirigeant/manager/pair/externe) × type_réunion (1:1/équipe/tous) × priorité_bloc_concentration
Si dirigeant + tout_type → Toujours proposer une alternative
Si manager + (1:1 OU urgent) → Proposer une alternative
Si pair + récurrent + faible_présence → Refuser automatiquement
Si externe + aucune_relation_antérieure → Refuser automatiquement avec "utiliser le lien de calendrier"
Si pendant_bloc_concentration_haute_priorité → Refuser automatiquement quel que soit l'expéditeur

Sélection de Créneaux avec Conscience des Fuseaux Horaires

Planification multi-participants :
├─ Tous même fuseau horaire → Utiliser les heures de travail locales (9-17)
├─ 2 fuseaux horaires, écart <6h → Trouver une fenêtre de chevauchement
├─ 2 fuseaux horaires, écart >6h → Répartition tôt/tard (l'un prend 8h, l'autre 18h)
└─ 3+ fuseaux horaires → Proposer une alternative asynchrone OU un roulement

Classement des Créneaux par Modèle Énergétique

Priorité horaire (décroissante) :
1. 9h-11h (pic cognitif) → Réserver pour le travail profond, refuser les réunions de routine
2. 11h-12h (concentration soutenue) → Autoriser uniquement les réunions importantes
3. 14h-16h (zone de collaboration idéale) → Préférer pour les réunions d'équipe
4. 16h-17h (clôture) → Idéal pour les 1:1, les mises à jour de statut
5. 13h-14h (creux post-déjeuner) → Éviter les réunions complexes

Modes de Défaillance

Conflits Récurrents liés aux Fuseaux Horaires

Symptômes : La réunion hebdomadaire de 9h présente des conflits en hiver mais pas en été ; la récurrence cross-fuseau échoue après un changement d'heure (DST) Détection : if événement_récurrent && conversion_fuseau_horaire && motif_conflit_saisonnier Correctif : Toujours développer les récurrences avec singleEvents: true, convertir chaque instance en UTC pour la vérification des conflits, réévaluer après les transitions DST

Valse des Tampons de Transition

Symptômes : L'agent reprogramme la même réunion à plusieurs reprises pour créer des tampons ; les réunions rebondissent entre les créneaux Détection : if même_réunion_reprogrammée > 2 fois en 24h pour_raisons_de_tampon Correctif : Verrouiller la réunion après la première reprogrammation, ajuster les exigences de tampon dynamiquement en fonction de l'importance de la réunion

Démarrage à Froid du Modèle Énergétique

Symptômes : Un nouvel agent planifie des réunions aux pires moments cognitifs de l'utilisateur ; ignore les modèles établis Détection : if score_satisfaction_réunion < 3 pour réunions_planifiées_par_agent Correctif : Amorcer avec les préférences explicites de l'utilisateur, apprendre des motifs de refus, exiger une période d'observation de 2 semaines avant la planification automatique

Fuite de Données par Gonflement de Schéma

Symptômes : L'agent partage trop de détails de calendrier avec des systèmes externes ; les descriptions d'événements fuient vers les LLM Détection : if appel_api_externe contient event.description OU attendee.email Correctif : Implémenter une couche de minimisation des données, supprimer les informations personnelles avant les appels externes, utiliser uniquement libre/occupé pour la planification

Boucle de Renégociation Récursive

Symptômes : Deux agents se contre-proposent sans fin ; aucune convergence sur l'horaire de la réunion Détection : if tours_négociation > 3 && aucun_créneau_accepté Correctif : Escalader vers un humain après 2 contre-propositions, implémenter un seuil d'acceptation "assez bon", limiter la durée des négociations

Exemples Concrets

Négociation de Réunion Cross-Fuseau Horaire

Scénario : Votre agent (Chicago) a besoin de 30min avec l'agent d'un pair (Tokyo) pour une revue d'API. Les deux ont des contraintes énergétiques.

Étape 1 : Analyse Initiale

• Chicago : 9h-17h CST = 0h-6h JST (jour suivant)
• Tokyo : 9h-18h JST = 19h-4h CST (jour précédent)
• Fenêtre de chevauchement : 19h-20h CST = 9h-10h JST

Étape 2 : Vérification du Modèle Énergétique

• Chicago 19h = fin de journée de travail (énergie : 6/10)
• Tokyo 9h = heures de pic cognitif (énergie : 9/10)
• Déséquilibre détecté → Nécessité d'un compromis

Étape 3 : Génération des Propositions

Agent Chicago → Agent Tokyo : PROPOSER
Créneaux : [
  "2024-03-19T01:00Z" (Chi: 19h, Tok: 10h),
  "2024-03-19T23:00Z" (Chi: 17h, Tok: 8h),  
  "2024-03-20T00:00Z" (Chi: 18h, Tok: 9h)
]
Priorité : normal
Sujet : "Revue API - discussion sur la complexité des fuseaux horaires"

Étape 4 : Contre-Proposition

Agent Tokyo → Agent Chicago : CONTRE-PROPOSER
Raison : "Préfère une matinée plus tardive à Tokyo pour une discussion technique complexe"
Alternatives : [
  "2024-03-19T02:00Z" (Chi: 20h, Tok: 11h),
  "2024-03-20T01:00Z" (Chi: 19h, Tok: 10h)
]
Contraintes : "Besoin d'un tampon de 15min avant le standup de 11h30 JST"

Étape 5 : Résolution L'agent de Chicago accepte le créneau 20h CST / 11h JST, crée l'événement avec les deux fuseaux horaires dans la description : "Revue API - 20h00 CST / 11h00 JST+1"

Débutant vs Expert :

• Débutant : Planifie à un horaire pratique pour Chicago sans vérifier les heures cognitives de Tokyo
• Expert : Reconnaît le déséquilibre énergétique, propose une fin de journée à Chicago quand Tokyo est frais

Contrôles Qualité

• Tous les horodatages stockés en UTC en interne, convertis uniquement aux frontières d'affichage/API
• Noms de fuseaux horaires IANA utilisés partout (pas de chaînes de décalage UTC comme "-05:00")
• Les requêtes libre/occupé suppriment les détails des événements, ne partagent que les blocs horaires avec les agents externes
• La mise en œuvre des tampons crée un minimum de 10 à 15 minutes entre les réunions consécutives
• Les blocs de concentration marqués comme "occupé" mais avec une priorité inférieure à celle des réunions réelles pour la négociation
• Le modèle énergétique prend en compte les heures de pic cognitif de l'utilisateur et les modèles de fatigue liée aux réunions
• Les jetons OAuth chiffrés au repos avec un flux d'actualisation automatique implémenté
• La limitation de débit gère les quotas de l'API Google Agenda avec un back-off exponentiel
• Les événements récurrents développés en instances individuelles avant la détection de conflits
• La fusion multi-calendriers testée sur des calendriers personnels/professionnels avec différentes autorisations
• Les négociations entre agents limitées dans le temps avec escalade humaine après des tours infructueux
• Le journal d'audit capture toutes les mutations du calendrier avec capacité de restauration

Limites : Ce Que Ce N'EST PAS

Cette compétence N'est PAS pour :

• Construire des composants d'interface utilisateur de calendrier → Utilisez form-validation-architect
• Les diagrammes de Gantt de projet ou le suivi des jalons → Utilisez project-management-guru-adhd
• Les minuteurs Pomodoro ou les applications de suivi du temps → Utilisez adhd-daily-planner
• Les modèles d'architecture d'agent généraux → Utilisez agentic-patterns
• Construire le framework de base de l'agent → Utilisez agent-creator

Déléguer à d'autres compétences lorsque :

• L'utilisateur a besoin d'une gestion du temps spécifique au TDAH → adhd-daily-planner
• Construire une mémoire persistante d'agent → always-on-agent-architecture
• Coordination multi-agents au-delà du calendrier → multi-agent-coordination
• Architecture de démon en arrière-plan → daemon-development

Cette compétence se concentre spécifiquement sur les structures de données calendaires, les algorithmes de planification et la logique de coordination des réunions.