knownasnaffy Travel Guide Pages
Build a useful trip first, then build the webpage.
Core approach
Follow this sequence:
- Discover the travellers, constraints, and vibe.
- Decide the route logic before writing a day-by-day itinerary.
- Build a realistic itinerary with energy management.
- Add hotels, activities, transport legs, and booking urgency.
- Turn the plan into a skimmable, image-led static webpage.
- Deploy to Cloudflare Pages.
Do not jump straight to “top things to do”. Do not optimise for maximum attractions. Optimise for fit, flow, energy, and clarity.
Discovery checklist
Before proposing an itinerary, gather or confirm:
- destination(s)
- trip length
- who is going
- ages if relevant
- whether they have been before
- interests
- explicit dislikes / hard nos
- budget level
- pace preference: slow / packed / balanced
- style preference: practical / premium / adventurous / relaxing / design-led / traveller-friendly
- willingness to drive
- luggage or mobility constraints
- likely airports / rail / car usage
If details are missing, ask only the highest-value questions first.
Family / mixed-age optimisation branch
If the trip includes children, teens, mixed generations, or a group with clearly different energy levels, ask a more specific second layer:
- ages of each traveller
- interests by person, not just for the group overall
- any hard no's by person
- food pickiness / flexibility
- sleep, nap, jet lag, or bedtime constraints
- stamina / walking tolerance / motion sickness / transport tolerance
- rooming needs (e.g. one room vs two rooms, sofa bed vs separate beds, privacy needs)
- what the adults also want from the trip so the plan does not become child logistics only
Ask about gender only when it would materially affect rooming, privacy, safety, or comfort decisions. Do not ask for personal details that do not change the plan.
Route logic
Work out the structure before the days.
Always determine:
- number of bases
- best order of places
- whether the route should be rail, road, air, or mixed-mode
- where rental car pickup happens
- where rental car return happens
- where mixed-mode handoffs happen
For mixed-mode travel, label legs explicitly. Examples:
Train + car pickupScenic driveDrive to rail gateway + train into city
Do not collapse mixed-mode travel into vague one-line labels. If a leg uses two modes, show both.
Itinerary design rules
Design for humans, not robots.
Account for:
- arrival fatigue / jet lag
- group pacing / energy differences
- sensory overload
- realistic travel times
- recovery after big days
- flexibility for weather and mood
- rooming and sleep practicality when relevant
Use an energy curve:
- stimulating days
- slower reset days
- headline days
- transition days
- flexible buffer days
Common helpful pattern:
- arrival/reset day
- lighter recovery day after long travel if needed
- major highlight day once people are functioning well
- calmer or flexible day after a big one
Recommendations structure
For each base/segment, provide:
Why stay here
Explain what this base adds to the trip and why it suits the travellers.
What to do
Recommend only high-fit activities. For each one include:
- why it fits
- rough travel time
- whether it is essential / optional / weather-dependent
- whether it is half-day or full-day
- booking urgency if relevant
Where to stay
Provide a short practical shortlist, ideally:
- best practical option
- best stylish option
- best upgrade option (if relevant)
Explain the hotel logic:
- space / room fit
- location convenience
- scenery
- transport access
- vibe
Transport logic
Be explicit about:
- train start/end points
- car pickup location
- car return location
- rail handoff point
- what each leg is actually doing
Day-by-day output
Create a realistic day-by-day plan. For each day include:
- day title
- location/theme
- key plan
- travel mode/time if relevant
- effort/energy level when useful
- whether it is a highlight / reset / transition / flex day
Keep it concise and skimmable.
Traveller profiles and reusable preferences
Support reusable traveller profiles when helpful.
Default to a shared profile for the main travelling unit:
- individual
- couple
- family
- recurring friend group
- recurring multi-generational group
Use individual subprofiles only when useful or explicitly requested. A shared group profile should be the default; per-person profiles are optional layers, not mandatory dossiers.
The skill may:
- create a primary group profile
- create optional traveller-specific subprofiles when they materially affect planning
- reuse an existing profile for future travel planning
- update the profile after a trip or after the user clarifies a preference
Only store durable travel-planning preferences, such as:
- trip pace
- budget style
- hotel preferences
- transport tolerance
- rooming preferences
- food preferences
- activity preferences
- hard no's
- destination preferences
- children’s ages/interests when relevant to future planning
- traveller-specific constraints only when they materially affect planning
Good pattern:
- primary family/couple/group profile for shared defaults
- optional subprofile for notable exceptions, e.g. motion sickness, food restrictions, very different activity tolerance, or strong preferences
Do not treat the profile as a dossier. Do not store unnecessary sensitive or irrelevant personal details. Store only information that improves future travel recommendations.
When saving or updating profile information, follow the environment’s consent and memory rules. If profile information is uncertain, summarise it as a tentative preference rather than a hard fact.
When a returning traveller or group is involved, check whether a profile already exists before re-asking basic planning questions. Reuse what is durable, then ask only for what has changed.
Planning extras
Always include:
Book in advance
Split into:
- must book early
- can book later
- flexible / low urgency
Weather / packing
Keep practical and brief.
Travel tips / hacks
Include only useful tips:
- booking strategy
- luggage strategy
- local transport logic
- timing / crowd avoidance
- family pacing
Avoid social-media fluff unless it is genuinely helpful.
Webpage requirements
Build a static HTML/CSS page suitable for Cloudflare Pages.
Style goals:
- premium travel editorial
- clean, skimmable, uncluttered
- image-led
- useful before clever
Suggested sections:
- cover / hero
- trip overview
- route summary
- route map + leg links
- day-by-day itinerary
- visual galleries by place
- hotel suggestions
- transport logic
- booking checklist
- final summary
Writing rules for the page
The page must be user-facing only. Do not include:
- “this version...”
- process commentary
- defensive caveats
- workshop notes
- tool chatter
Write like a polished guide, not a development log.
Image rules
Prefer correctness over generic mood shots.
Good order of preference:
- exact place-matched images
- source pages with usable
og:image - official tourism / venue pages
- Wikimedia Commons
- stable generic mood imagery only when clearly labeled as general atmosphere
If the page names a specific place, do not use obviously unrelated visuals.
When image sourcing is messy:
- use fewer stronger images
- use source-page share images when available
- make gallery cards clickable to the source page
- host assets locally when reliability matters
Maps and leg links
Include a route summary visual where possible. Also include leg-by-leg links.
For each leg, ensure:
- the origin is correct
- the destination is correct
- the travel mode matches reality
Examples:
- transit for rail legs
- driving for car legs
- separate links for mixed-mode handoffs
Confidence gate before page build
Do not build or deploy the Cloudflare Pages site too early. Only move into page creation once the itinerary is stable enough that major structural changes are unlikely.
Minimum confidence before page build:
- route order is agreed or strongly recommended and accepted
- number of bases is settled
- core transport logic is settled
- major activity choices are reasonably locked
- hotel shortlist is directionally right
- the user is no longer still deciding the basic shape of the trip
If confidence is still low:
- stay in planning mode
- keep refining route, pacing, and activities
- summarise open decisions clearly
- avoid premature page production that will just cause churn
Once confidence is high enough:
- build the webpage
- treat the page as a packaging/output step, not as the discovery step itself
Cloudflare Pages deployment
After building the static page:
- make sure assets are local or stable
- create the Pages project if needed
- deploy the static folder
- return the live deploy URL and stable Pages URL
If Cloudflare auth is missing, ask for the minimum token/account/project info needed.
Quality bar
A good result should be:
- genuinely useful
- visually coherent
- easy to skim in under 5 minutes
- internally consistent about route and transport
- tailored to the travellers
If tradeoffs exist, prefer:
- correct route logic over pretty simplifications
- exact imagery over generic filler
- traveller fit over attraction maximisation
- group harmony and energy management over trying to “do everything”