zexuanw958-svg/travel-plan-viz

Travel Plan Visualization

Turn a trip into a single-file HTML page: interactive map, daily timeline, and pre-departure booking reminders. The mechanical logic uses the built-in engine (assets/map.js, assets/reminders.js), while aesthetics are left to the design step (frontend-design / huashu-design, or fallback built-in guidelines).

Step 1: Determine the Mode

• The user only gives a destination + number of days (e.g., "Hong Kong 4 days 3 nights") → Mode A (plan from scratch).
• The user already provides an itinerary (text or old HTML file) → Mode B (parse existing plan).

Mode A: Plan from Scratch

1. Read references/research-guide.md and research the destination online.
2. In the conversation, propose a detailed day-by-day plan in markdown (morning/afternoon/evening, attractions, transportation, accommodation).
3. Iterate with the user until they explicitly confirm.
4. Proceed to "Research Completion + Generation".

Mode B: Existing Plan

1. Parse the itinerary the user provided (if it's an old HTML file, extract structured data from it).
2. Optionally offer suggestions (Agent value-add, but don't force it): Quickly audit the user's plan against the dimensions of "itinerary completeness" (pre-trip essentials/weather contingencies, items needing advance booking, point-to-point transportation, rhythm and buffer time, local must-eats, whether accommodation areas make sense, etc.) and give, in the conversation, at most 3–4 specific, optional improvement tips. Principles:
   • Only point out real gaps; if the plan is already solid, just say "Looks complete" — don't force suggestions, don't preach, don't rearrange the itinerary for the user.
   • Keep it concise: one sentence to state the issue + one sentence to suggest a direction; defaults to verbal suggestions to keep the final HTML clean (the user can ask to include suggestions in the page later).
   • This is how we differentiate from a "pure prompt-to-HTML" tool — exercise the Agent's judgment, but stop at the right point.
3. Proceed to "Research Completion + Generation" (generation is not blocked by suggestions; the user decides which to adopt).

Research Completion + Generation

1. Following references/research-guide.md, complete the plan online: coordinates, real image URLs, ratings, reviews, opening hours/closure days, ticket reference prices, items needing advance booking with leadDays; pre-trip essentials (weather/typhoon/clothing/payment/apps/timing for booking), point-to-point transportation (mode/fare/duration), seasonal activities, must-order dishes + reference prices for each meal; flights show 3-5 candidate flights, hotels recommended by area + price range, and include disclaimers and tips throughout. Scheduling should reflect weather/season logic (outdoor activities during cooler times). Do not fetch real-time ticket prices.
2. Organize the data into the trip data structure defined in assets/page-contract.md.
3. Use the design step to generate a styled HTML: preferentially call a professional design skill — frontend-design or huashu-design (Huashu Design), whichever is installed; if neither is available, follow the built-in aesthetic guidelines in references/design-guidelines.md. Regardless of the method, strictly follow the blocks and constraints in assets/page-contract.md:
   • Inline the contents of assets/map.js and assets/reminders.js into the HTML (single-file guarantee).
   • Use computeReminders + renderChecklistHTML for the page-top checklist.
   • Show the pre-trip essentials block; flights section shows candidate flights (already-booked ones highlighted), hotels recommended by area + price range, and display the disclaimer prominently nearby.
   • Timeline cards show optional fields such as opening hours/ticket reference prices/transportation/seasonal activities; show daily meals (must-order dishes + prices), tips for the day and the whole trip, and alternative plans for the day (if any).
   • Use initTravelMap for the map, importing Leaflet CDN's CSS/JS.
   • Insert reminderBadgeHTML(leadDays) for items with needsBooking in the timeline.
   • Each trip uses a different color scheme.
4. Save the file as <TripName>-travel-plan.html in the working directory.
5. Tell the user: later they can drop this HTML file back and say "move Day 3's X to Day 4", and you will modify it on the existing structure.

Don't Do

Real-time ticket/airfare prices, ticket booking services, multi-language UI, or backend. Entirely static single file.