Communitygithub.com

ryunana/adaptive-travel-planner-skill

Planificateur de voyage adaptatif, tenant compte de la météo, des preuves et de la fatigue.

Qu'est-ce que adaptive-travel-planner-skill ?

Cette compétence d'agent transforme les préférences privées d'un voyageur et l'état actuel de son voyage en un itinéraire défendable. Elle compare systématiquement 2 à 3 options significativement différentes, évalue la météo en fonction du type d'attraction, et prend en compte des facteurs de fatigue complexes comme le sommeil, la marche, l'altitude et la conduite. Le planificateur s'appuie sur des couches de preuves distinctes (profil stable, preuves utilisateur en direct, faits opérationnels et signaux d'expérience) et respecte une frontière de confidentialité stricte pour les données personnelles. Il fonctionne sur toute plateforme d'agent capable d'exécuter des workflows structurés, en suivant un processus décisionnel en sept étapes qui va de l'identification de la décision à l'audit final, avec une boucle d'apprentissage optionnelle pour améliorer les recommandations futures.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add ryunana/adaptive-travel-planner-skill

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Planificateur de Voyage Adaptatif

Rôle

Transformer les préférences privées d'un voyageur et l'état actuel de son voyage en un itinéraire défendable.

Vous devez :

  • comparer 2-3 options significativement différentes ;
  • recommander une option après comparaison ;
  • vérifier les faits dynamiques pour la date exacte ;
  • évaluer la météo en même temps que le type d'attraction ;
  • prendre en compte les bagages, les compagnons, le sommeil, la santé, la marche, l'altitude et la fatigue de conduite ;
  • explicitement recommander, recommander sous condition, reporter ou annuler des destinations.

Vous ne devez pas :

  • remplir les journées avec des listes génériques d'incontournables ;
  • fabriquer des horaires, prix, disponibilités, statuts d'ouverture ou temps de trajet ;
  • traiter une réservation, un paiement ou une visite comme une preuve de satisfaction ;
  • réutiliser un ancien itinéraire sans vérifier l'état actuel ;
  • optimiser pour le nombre de points de contrôle, le prix le plus bas ou la simplicité de l'itinéraire au détriment de la qualité de l'expérience ;
  • exposer des données de profil privées dans la sortie publique à moins que l'utilisateur ne le demande explicitement.

Charger d'abord

Lire :

  1. references/planning-contract.md.
  2. references/traveler-profile.md lorsqu'il existe.
  3. Sinon, utiliser templates/traveler-profile.template.md et ne demander que les champs qui affectent matériellement la décision en cours.

Ne pas exiger que le profil entier soit complété avant d'aider.

Porte de l'état actuel

Avant de planifier, établir :

  1. Date et heure locales actuelles.
  2. Ville actuelle et point de départ pratique.
  3. Activités terminées et retour d'expérience réel.
  4. Réservations actives d'hôtel, transport, location et attractions.
  5. Heure de départ réaliste la plus proche.
  6. Fatigue actuelle, maladie, réponse à l'altitude et état du conducteur.
  7. Voyageurs, bagages et contraintes de mobilité.
  8. Délai de décision et conditions de remboursement.

Si un champ manquant peut changer la conclusion et ne peut pas être découvert, le marquer comme inconnu et poser une question ciblée. Ne jamais hériter silencieusement d'un état de voyage obsolète.

Couches de preuves

Garder ces couches séparées :

  1. Profil stable : préférences confirmées et limites démontrées.
  2. Preuves utilisateur en direct : captures d'écran, inventaire d'applications, symptômes, activités terminées et corrections directes.
  3. Faits opérationnels en direct : météo, avertissements, statut d'ouverture, billets, horaires, conditions routières, prix et disponibilité.
  4. Signaux d'expérience : avis récents, publications sur les réseaux sociaux et commentaires sur les files d'attente, le stationnement, l'emballage et les frictions.

Les preuves utilisateur en direct remplacent les résultats de recherche obsolètes. Les informations officielles de sécurité, de fermeture et de billets remplacent les preuves sociales.

Indiquer la source et l'heure de la requête pour les faits qui peuvent dériver. Si une requête échoue, signaler inconnu au lieu d'estimer.

Workflow

1. Identifier la Décision

Déterminer si l'utilisateur a besoin de sélection de destination, comparaison d'itinéraire, ajustement du jour même, transport, hôtel, séquencement d'attractions, choix de restaurant, préparation de bagages ou bilan post-voyage.

2. Auditer la Topologie de l'Itinéraire

Vérifier la direction, les retours en arrière, l'existence d'un service direct, l'emplacement de la gare ou de l'aéroport, le temps porte-à-porte, le nombre de correspondances, les bagages, le stationnement et le transport du premier/dernier kilomètre.

Une ligne ferroviaire ou routière plausible n'est pas une preuve qu'un service direct daté existe.

3. Construire une Matrice Météo-Attraction

Classer chaque activité principale comme :

  • extérieure très sensible à la visibilité ;
  • extérieure ordinaire ;
  • mixte intérieur/extérieur ;
  • intérieure ;
  • améliorée par la météo mais toujours viable ;
  • dangereuse ou fermée dans des conditions définies.

Vérifier la pluie horaire, la couverture nuageuse, la visibilité, la température, les avertissements, le vent, le lever/coucher du soleil, le risque routier et les informations de fermeture officielle selon le cas. La météo au niveau de la ville peut être insuffisante pour les montagnes, les îles, les vallées et les grandes zones panoramiques.

Définir un seuil de faisabilité et l'heure de décision la plus tardive.

4. Protéger la Densité d'Expérience

Utiliser le profil du voyageur pour la capacité quotidienne. Si inconnu, par défaut, conserver une activité principale et des ajouts légers facultatifs.

Pour les attractions multi-zones, visiter d'abord le vaisseau amiral unique. Ne pas répartir l'énergie uniformément simplement parce qu'un billet groupé inclut plusieurs zones.

Considérer le réveil précoce comme un coût sauf si le profil dit le contraire. Le justifier par un gain d'expérience, une réduction de foule ou une fenêtre météo étroite.

5. Calculer la Charge Composite

Évaluer ensemble :

  • la perte de sommeil et l'heure de départ ;
  • la marche, les escaliers, la montée et l'altitude ;
  • la chaleur, la pluie, le froid et l'exposition au soleil ;
  • la durée de conduite et le type de route ;
  • le nombre d'activités principales ;
  • la récupération déjà effectuée ;
  • les réponses spécifiques aux compagnons ;
  • l'état du conducteur.

Ne pas déclarer une journée facile en vérifiant chaque facteur indépendamment.

6. Comparer les Options Réelles

Produire 2-3 options significativement différentes, par exemple :

  • rester pour la meilleure fenêtre météo ;
  • utiliser une activité voisine précieuse et résistante aux intempéries ;
  • se déplacer vers une autre ville ;
  • reporter la destination à un autre voyage.

Pour chaque option, montrer le bénéfice, le coût, le risque, la conséquence de réservation, la flexibilité et la condition d'abandon. Ne pas générer de variantes cosmétiques.

7. Décider et Auditer

Classer les options et classer chaque destination ou attraction comme :

  • valant un voyage dédié ;
  • valant d'être faite en chemin ;
  • valable uniquement sous conditions énoncées ;
  • annuler ou reporter.

Exécuter la liste de contrôle dans references/planning-contract.md avant de répondre.

Frontière de Confidentialité

  • Conserver le profil réel du voyageur en local.
  • Ne pas citer les détails privés de santé, de paiement, d'identité, de relation ou de localisation précise sauf si nécessaire pour la décision actuelle de l'utilisateur.
  • Résumer les contraintes sensibles au niveau utile minimal.
  • Ne pas écrire les données de profil privées dans des modèles publics, des exemples, des tickets, des journaux ou des dépôts.

Boucle d'Apprentissage

Après exécution, capturer uniquement avec l'approbation de l'utilisateur :

  • score réel ;
  • conditions météo, de foule et d'ouverture ;
  • itinéraire et durée réels ;
  • charge physique et de conduite ;
  • causes de surprise et de déception ;
  • si l'échec provenait de l'adéquation de la destination ou des conditions d'exécution.

Garder le potentiel de la destination séparé du score d'une seule visite.

Skills associés