TripCheat · Planificateur de voyage IA (`trip-cheat-sheet`)

Transformez les informations éparses de l'utilisateur (vols, hôtels, agendas de conférences, billets, captures d'écran de guides et conversations) en une page web portable : Frise chronologique (quoi et où aujourd'hui), listes de vérification (ce qu'il ne faut pas oublier), manuel (comment se déplacer, payer, qui contacter en cas de problème). Utilisable sur mobile, supporte le double fuseau horaire, le thème sombre, le réglage de la taille du texte, les liens profonds vers les cartes, les billets avec QR code, et peut être déployé sur n'importe quel hébergement statique.

La page est construite par le générateur intégré de ce skill à partir d'un fichier trip.json : le contrat de données est dans references/trip-schema.md, les règles de rédaction dans references/content-guide.md, et le déploiement dans references/deploy.md.

Quand l'utiliser

Scénarios de déclenchement

« Aide-moi à planifier un voyage », « Organise les billets d'avion, l'hôtel et l'agenda de la conférence en une page », « Préparation pour un voyage d'affaires / une conférence »
« Guide de voyage », « Page portable », « Manuel de voyage », « Liste de courses », « Que faire chaque jour »
L'utilisateur fournit des captures d'écran / PDF / emails / liens / conversations qui doivent être structurés + complétés par des recherches + transformés en page consultable
Un trip.json existe déjà : il faut régénérer la page, changer le thème, ajouter un mot de passe, déployer ou partager les pages de billets

Ne pas utiliser

Si l'utilisateur demande simplement une description de site, la météo ou une réservation : répondre directement, pas besoin de page
Si le besoin implique des stocks en temps réel, des commandes, des paiements ou de l'enregistrement : ce skill ne s'intègre pas aux API de réservation, il organise uniquement les informations et les liens
Pour un simple itinéraire de navigation : utiliser un outil de cartographie, pas une page de voyage

Livrables

Mode	Commande	Résultat
Fichier unique (par défaut)	`node scripts/build.mjs trip.json --out dist`	`dist/index.html` (CSS/JS/données/manifest PWA tout en un) + images de billets copiées si nécessaires
Site multi-pages	`node scripts/build.mjs trip.json --multi --out dist`	`dist/index.html`, `dist/ticket-<id>.html`, `dist/assets/style.css`, `dist/assets/app.js`, `dist/manifest.json`, ressources de billets copiées

Fonctionnalités de la page : frise chronologique / listes de vérification / manuel en trois vues ; mise en évidence de « l'événement en cours / suivant » ; horloges bi-fuseau et conversion horaire ; thèmes (paper/slate/night) et changement de taille de police ; liens profonds vers Google/Amap/Apple Maps (le lien Google inclut le paramètre de mode de transport) ; cases à cocher persistantes (localStorage) ; pages de billets avec QR code ; porte de mot de passe optionnelle (vérification SHA-256 côté client) ; ajout à l'écran d'accueil (PWA, désactivable avec --no-pwa).

Flux de travail (6 étapes)

Étape 1 : Collecte des informations (questionnaire + fichiers/captures d'écran/liens)

Posez d'abord une série de questions, maximum 6, pour éviter les relances incessantes ; si l'utilisateur ne répond pas, utilisez des hypothèses par défaut et marquez-les explicitement « Hypothèse ».

Qui voyage, nombre de personnes, relations (besoins spécifiques : personne âgée, enfant, accessibilité)
Lieu de départ, dates (incluant les vols de nuit / les journées chevauchantes), destinations (multi-villes / correspondances)
Ce qui est réservé, ce qui reste à réserver (vols, hôtel, inscription conférence, billets, restaurant)
Horaires clés de la conférence/activité (inscription, ouverture, votre propre présentation/poster, dîner de gala)
Préférences et limites (budget, restrictions alimentaires/allergies, rythme, éléments à abandonner)
Exigences de confidentialité (partage public ou non, besoin de porte de mot de passe, informations à ne pas mettre en ligne)

Collectez les supports : captures d'écran, PDF, emails, conversations, liens. Organisez d'abord en liste de faits avant d'écrire le JSON, ne devinez pas en collectant.

Étape 2 : Recherche approfondie (en ligne, en distinguant « confirmé » et « à vérifier »)

Recherchez par ordre de priorité, et notez les sources et la date de vérification :

Priorité	Contenu de la recherche
P0	Visa/passeport validité, vols/trains, hébergement, inscription conférence/billets, assurance
P1	Transport aéroport ↔ centre-ville (dernier bus, terminal), transports urbains, réservation de créneaux pour les musées, réservation de restaurants
P2	Sites touristiques, shopping, plans B, météo

Priorité aux sources officielles : compagnie aérienne/aéroport/chemin de fer, hôtel, site de la conférence, musée/site officiel, ambassade, opérateur de transport.
Chaque information clé est classée en quatre catégories : Confirmé / À vérifier / Non décidé / Exemple (règles dans references/content-guide.md §6).
N'inventez pas les prix, horaires, heures d'ouverture, statuts de réservation ; si vous ne trouvez pas, écrivez « À vérifier » et ajoutez une clause de sauvegarde « Se référer aux sources officielles ».
Pièges courants (transport aéroport, réservation de billets, Wi-Fi, paiement, numéros d'urgence, fuseau horaire/heure d'été) : vérifiez un par un et incluez-les dans le manuel ou la description de l'événement.

Étape 3 : Rédiger `trip.json`

Respectez strictement references/trip-schema.md ; vous pouvez vous référer directement à l'exemple examples/tokyo-conference/trip.json.

meta : titre, sous-titre, lieu de résidence (home), dates de début et fin, thème, fournisseur de cartes, pied de page (date limite des données).
destinations : chaque destination a un id + fuseau horaire IANA (ex. Asia/Tokyo).
days[].events : chaque événement doit avoir au moins time / title / short / detail / kind ; si lieu, ajoutez location + map ; si lien officiel, ajoutez links ; si lié à une liste de vérification, ajoutez checkId.
checklists : groupées par phase (avant le départ / à l'arrivée / pendant / avant le retour), id unique global.
handbook : sections transport, réseau, paiement, sécurité/urgence, participation à la conférence, alimentation, bagages, etc. (peut être combiné/ajouté, mais ne manquez aucun thème).
tickets : un par personne, qr pointe vers une image placeholder ou une image fournie par l'utilisateur (ne soumettez pas de vrais codes de billets).

Règles des doubles fuseaux horaires (le plus sujet aux erreurs)

time / endTime sont les heures locales de l'événement ; tz hérite du fuseau horaire de la destination du jour si non spécifié.
Pour un vol traversant des fuseaux horaires, tz indique le fuseau horaire du lieu de départ, et endTime est interprété dans ce même tz. Si vous fusionnez le vol en un seul événement, endTime doit être la valeur de l'heure d'arrivée convertie dans le fuseau du départ, et dans detail, écrivez « Heure locale d'arrivée : HH:MM » ; une méthode plus simple est de séparer le décollage et l'atterrissage en deux événements, chacun avec son propre fuseau horaire local.
L'arrivée le lendemain est placée dans le days[] suivant, avec detail indiquant « +1 jour » / « lendemain » ; si endTime est inférieur à time pour des événements chevauchant minuit, il sera traité comme le lendemain, mais une explication textuelle est recommandée.
Pour les événements sans horaire précis (journée entière), utilisez skipTimezone: true ; les fuseaux horaires doivent toujours être en nom IANA, pas UTC+9 ou JST.
La page convertit automatiquement les heures dans le fuseau du lieu de résidence, ne répétez pas la conversion manuellement dans le texte, sauf pour des choses comme « Ouverture de l'enregistrement en ligne / réunion à distance » qui doivent être faites avant le départ et sont donc en heure du lieu de résidence.

Étape 4 : Construction

Exécutez depuis le répertoire racine du skill (contenant scripts/, templates/) ; le script résout les chemins par rapport au répertoire de travail actuel, ou vous pouvez utiliser des chemins complets depuis n'importe quel dossier.

node scripts/build.mjs <trip.json> --out dist

Paramètres courants :

# Site multi-pages (génère des ticket-<id>.html partageables individuellement)
node scripts/build.mjs trip.json --multi --out dist

# Surcharger le thème / ajouter un mot de passe / désactiver PWA / forcer la sortie dans un dossier non vide / mode silencieux
node scripts/build.mjs trip.json --theme night --gate-password "votre-mot-de-passe" --out dist
node scripts/build.mjs trip.json --no-pwa --out dist
node scripts/build.mjs trip.json --force --quiet --out dist

Par défaut, sortie dans dist/index.html ; --out par défaut dist.
build lance d'abord la même validation de données ; s'il y a des erreurs, il quitte avec le code 1 et ne génère pas de demi-produit ; les avertissements sont affichés mais ne bloquent pas.
Si le répertoire de sortie existe déjà et n'est pas vide, --force est obligatoire (il vide d'abord le répertoire).
--help pour tous les paramètres.

Étape 5 : Validation

node scripts/verify.mjs <trip.json>          # Par défaut : les erreurs échouent (code 1), les avertissements sont simplement notifiés
node scripts/verify.mjs <trip.json> --strict # Les avertissements échouent aussi (recommandé avant publication)
node scripts/verify.mjs <trip.json> --quiet  # Affiche seulement un résumé des erreurs

Couverture de la validation : champs obligatoires de meta et fuseau horaire/date valides, références de destinations, format horaire des days/events et validité de tz, protocole des liens, liste blanche HTML de handbook, existence des fichiers tickets.qr, et scan de la vie privée (les numéros de téléphone suspects ou longs identifiants numériques génèrent un avertissement). Les avertissements doivent être corrigés ou expliqués.

Étape 6 : Prévisualisation et déploiement

Prévisualisation locale : ouvrez dist/index.html dans un navigateur (fichier unique, double-clic) ; pour le mode multi-pages, utilisez un serveur local :
```
npx serve dist
# ou python -m http.server --directory dist
```
Déploiement : voir references/deploy.md (GitHub Pages / Cloudflare Pages / tout hébergement statique).
Partage des pages de billets : en mode multi-pages, ticket-<id>.html peut être envoyé individuellement à la personne concernée ; en mode fichier unique, utilisez l'ancre #ticket-<id>, mais la même page contient le contenu de tout le monde.
Rappel de confidentialité : un site public = visible par tout le monde. N'incluez pas de vrais QR codes, codes de billets, numéros de pièce d'identité ou numéros de téléphone dans les pages publiques ; la porte de mot de passe n'est qu'une validation côté client (voir deploy.md pour plus de détails).

Exemples d'appel

Exemple 1 : Conférence académique à Tokyo (données identiques à l'exemple)

Utilisateur : Je vais à une conférence académique à Tokyo du 20 au 24 novembre, deux personnes (A/B), voici les captures d'écran des vols et de l'hôtel, et le lien de l'agenda ;
      intègre l'inscription, l'ouverture, les posters, le dîner de gala, fais-en une page consultable sur mobile.

Agent :
1. Collecte des informations → pose 3 questions : le petit-déjeuner est-il inclus dans la réservation d'hôtel, types de badges pour A et B, heure d'enregistrement en ligne pour le retour
2. Recherche → moyens de transport de Haneda au centre-ville et dernier bus, position relative du lieu de la conférence et de l'hôtel, temps d'immigration à l'arrivée
3. Rédaction de trip.json → se référer à examples/tokyo-conference/trip.json (l'exemple fusionne le vol en un seul événement, endTime converti dans le fuseau du lieu de départ)
4. Construction → node scripts/build.mjs trips/tokyo-2026/trip.json --multi --out dist
5. Validation → node scripts/verify.mjs trips/tokyo-2026/trip.json --strict
6. Prévisualisation → ouvrir dist/index.html ; proposer le déploiement sur GitHub Pages / envoyer ticket-badge-a.html à A

Exemple 2 : Voyage familial à l'étranger (multi-destinations + double fuseau + informations d'assurance)

Utilisateur : Je pars 10 jours cet été avec mes parents en Espagne, entrée par Madrid, sortie par Barcelone, aide-moi à planifier, je veux pouvoir consulter le métro et les numéros d'urgence.

Agent :
- destinations : deux entrées (Madrid / Barcelona, fuseau Europe/Madrid comparé au lieu de départ)
- handbook : insister sur aéroport↔centre-ville, tickets de métro, paiement et pourboires, numéros d'urgence et ambassade, alimentation (allergies des parents)
- Dans les événements, expliquer le « pourquoi » et les « éléments à abandonner » (ex. « Ne pas aller au Retiro aujourd'hui, garder de l'énergie pour le Palais royal »)
- Après build, lancer verify, déployer dist sur GitHub Pages, envoyer le lien à la famille

Exemple 3 : Mise à jour de données existantes + partage uniquement de la page de billets d'une personne

Utilisateur : Le programme a changé : le dîner de gala passe du 23 au 24 à 19:30, et envoie-moi uniquement la page du badge de ma femme.

Agent :
1. Modifier trip.json : changer le time/detail de l'événement concerné (conserver la mention « Confirmé » et les sources)
2. node scripts/build.mjs trip.json --multi --out dist --force
3. node scripts/verify.mjs trip.json
4. Partager dist/ticket-badge-b.html uniquement ; rappel : un lien public expose le QR code, suggérer de ne le donner qu'à la personne concernée ou d'ajouter un contrôle d'accès

Lignes rouges qualité

N'inventez pas : prix, horaires, heures d'ouverture, statuts de réservation, téléphones doivent avoir une source ; si vous n'avez pas, écrivez « À vérifier » + « Se référer aux sources officielles ».
Confirmé vs À vérifier : confirmation de l'utilisateur/page officielle = Confirmé ; plateforme tierce/ancienne capture/guide = À vérifier ; formulation fixe dans content-guide.md §6, n'utilisez pas « paraît-il » ou « devrait ».
Double fuseau : time = heure locale de l'événement ; pour un vol fusionné, endTime est converti dans le tz (fuseau du lieu de départ), detail contient l'heure locale d'arrivée ; les chevauchements de jours sont placés le jour suivant ; utilisez uniquement des noms IANA.
Confidentialité et codes de billets : n'incluez pas de vrais QR codes, codes de billets, PNR, numéros de pièce d'identité, numéros de téléphone ou adresses dans les pages publiques ; utilisez des placeholders pour les qr ; les données d'exemple doivent être fictives et anonymisées ; le dépôt ne contient que des QR placeholders.
Ne promettez pas de capacités : ne promettez pas de stocks en temps réel / réservation / enregistrement ; les actions irréversibles comme commander, payer, modifier/annuler sont laissées à l'utilisateur, ne les exécutez pas à sa place.
Exécutez la validation avant la livraison : verify.mjs --strict zéro erreur avant livraison ; vérifiez à nouveau avant déploiement qu'aucune information sensible n'est présente.
Expliquez les limites : la porte de mot de passe est une protection de niveau « partage entre proches », pas du chiffrement ; pour une vraie sécurité, utilisez un hébergement privé / un contrôle d'accès.

Comment choisir entre fichier unique et multi-pages

Besoin	Choisir fichier unique (par défaut)	Choisir multi-pages (`--multi`)
Envoyer à la famille/aux collègues, par WeChat/email, double-clic hors ligne	✅ Un seul HTML est le plus simple	Déconseillé (nécessite tout un dossier)
Déployer en site, utilisation à long terme, mises à jour fréquentes	Possible (renvoyer un fichier à chaque fois)	✅ Cache-friendly, structure claire
Partager individuellement les pages de billets	❌ L'ancre expose les billets des autres sur la même page	✅ `ticket-<id>.html` page indépendante
Vouloir un seul fichier (incluant les QR codes)	Remplacez `tickets[].qr` par une URI `data:` ou une URL externe	—
Besoin d'une porte de mot de passe	✅ Supporté (s'affiche sur la page principale et la vue des billets dans la page)	✅ La page principale et `ticket-<id>.html` affichent tous une boîte de mot de passe (même mot de passe, déverrouillage une fois par navigateur)

Note : en mode fichier unique, les images locales pointées par qr sont automatiquement intégrées en URI data: , le résultat est vraiment un seul fichier HTML ; les QR déjà en data:/http(s) sont conservés tels quels.

Arborescence des fichiers

skills/trip-cheat-sheet/
├── SKILL.md                     # Ce fichier : quand l'utiliser, comment l'utiliser, lignes rouges
├── references/
│   ├── trip-schema.md           # Contrat de données unique (champs/fuseau/commandes de construction)
│   ├── content-guide.md         # Règles de rédaction (six éléments/double fuseau/sections du manuel/règles d'étiquetage)
│   └── deploy.md                # Déploiement et partage (Pages/Cloudflare/fichier unique ou multi/mot de passe)
├── scripts/
│   ├── build.mjs                # trip.json → page web
│   └── verify.mjs               # Validateur trip.json (réutilisé en interne par build)
├── templates/                   # style.css / app.js / index.html / ticket.html
└── examples/tokyo-conference/   # Exemple exécutable (avec QR placeholders)
    ├── trip.json
    └── assets/qr-a.svg, qr-b.svg

Questions fréquentes

Phénomène	Traitement
`❌ Le répertoire de sortie n'est pas vide`	Ajoutez `--force`, ou changez de répertoire avec `--out`
Page blanche / styles manquants	En mode multi-pages, téléchargez tout le dossier `dist/` (y compris `assets/`) sur le serveur ; assurez-vous que `index.html` et `assets/` sont au même niveau
Heure affichée incorrecte	Vérifiez l'orthographe de `tz` (nom IANA) ; pour un vol fusionné, vérifiez que `endTime` est converti dans le fuseau du lieu de départ
`verify` affiche des avertissements	Corrigez-les, ou confirmez qu'ils sont acceptables avant de livrer ; `--strict` échouera
Mot de passe de la porte oublié	Reconstruisez : `node scripts/build.mjs trip.json --gate-password "nouveau mot de passe"`
404 après déploiement	Vérifiez la branche/répertoire des Pages, si les Actions sont terminées, la casse des noms de fichiers
Erreur de version Node	Utilisez Node.js ≥ 18 (nécessite les données complètes de fuseau horaire `Intl` et ESM)

English quick reference (Aide-mémoire anglais)

What: generate a mobile-first travel cheat-sheet web page from one trip.json — itinerary timeline, checklists, destination handbook, dual-timezone display, map deep links, QR ticket pages, optional password gate, PWA.
Build: node scripts/build.mjs <trip.json> --out dist (single file, default) or --multi (static site with ticket-<id>.html). Flags: --theme paper|slate|night, --gate-password, --no-pwa, --force, --quiet.
Verify: node scripts/verify.mjs <trip.json> [--strict] [--quiet].
Contract: references/trip-schema.md; writing rules: references/content-guide.md; deployment: references/deploy.md.
Never: fabricate prices/schedules, mix up timezones, or commit real ticket codes, QR images, IDs or phone numbers. Mark verified vs unverified content explicitly.

TripCheat · Planificateur de voyage IA (`trip-cheat-sheet`)

Qu'est-ce que TripCheat · Planificateur de voyage IA (`trip-cheat-sheet`) ?

Demander à votre IA préférée

Documentation