Light-TravelPage

Turn travel materials into a maintained page for a travel group. This is a model-invoked capability. The default delivery uses GitHub for code and Cloudflare Pages, Functions and D1 for the website and shared state. Local preview is a development step.

Prepare

Read supplied materials and any existing trip once. Extract confirmed itinerary, dates, places, flights, accommodation bookings, tickets and explicit tasks; collect actual conflicts. Prepare Chinese and English display translations without changing facts; retain local place names and original addresses. For navigation, record each place's country/region and any verified provider links or coordinate system/source. Honor choices already made. Ask only questions needed to resolve a material ambiguity; leave unknown facts visibly pending. Do not invent bookings, coordinates or travel advice to fill the template.

Use data-contract.md when preparing or validating data. Keep a small private source index for conflicting or easily misread dates, times, locations and booking details; do not publish raw documents, extraction notes or local paths.

Before generating a new page, briefly ask whether to enable AI when that choice is still unknown; default to off. Honor an existing choice without asking again. If enabled, read ai-integration.md: the page owner connects any OpenAI- or Anthropic-format API by running scripts/ai-setup.mjs in their own terminal, so the key never enters the conversation; the model is fixed at deployment and travelers cannot change it.

Generate or update

• New page: run node <skill>/scripts/create.mjs <new-project-directory> (AI off), or append --ai on when authorized. Then fill its trip-data.json and explicitly supplied ticket assets. Use the travel-handbook template and handbook-design.md for chapter layout and typography, unless the user requests a redesign. Enable modules matching the requested content.
• Existing page: read its current data and runtime/deployment settings first. Prepare a complete next data file preserving the trip ID, unchanged entity IDs, existing map selection and unrelated user edits. Apply it with node <skill>/scripts/update.mjs <project-directory> <next-trip.json>. See update-and-export.md for backup and publication boundaries. Changes to source data do not reset shared runtime state.

Run npm ci, npm run build and npm test in the generated project. PDF ticket builds require pdftoppm; keep the original PDF and deploy the generated same-name PNG preview beside it under the same authentication. Fix invalid facts/references or report the precise unresolved input; do not weaken the validator to produce a green result. Dates may remain null in an explicitly undated draft. For a known destination with verified WGS84 places, source its matching real geographic outline and build with geographic-outline as described in display-and-navigation.md; choose this from the trip facts without asking the traveler to select a map style. Use place navigation links for actual navigation. When geography or a usable boundary is unavailable, report that limit and label any template map as schematic.