the days, in order, for everyone.
once a trip is booked, the information exists — it is just scattered across eleven emails, two apps and a text message from whoever booked the restaurant.
so the answer to "what time is the train on thursday" is always somebody scrolling, and usually the same somebody.
an itinerary page is one link that holds all of it, opens offline once loaded, and can be corrected after you have sent it. which is the thing a pdf cannot do.
the one link you send.
01 / what it isthis page exists to stop six people asking one person the same question. it holds the days in order with the details attached, it opens on any phone with nothing installed, and once it has loaded it works with data turned off — which is the state most people are in the moment they need it.
because the content is in the page rather than in a browser’s storage, everyone sees the same version, and when something changes you republish rather than sending a correction.
- each day in order, with times and what is happening
- travel legs with times, numbers and where to be
- accommodation with addresses and check-in details
- references and confirmations, at the level of detail you choose
- today highlighted automatically during the trip
- a page that keeps working with no signal
- what is on it
- days, times, travel, accommodation, references, addresses
- where it lives
- in the published page — identical for everyone with the url
- offline
- works once loaded. no runtime requests, no maps to fetch
- privacy
- public to anyone with the link. choose the level of detail accordingly
see one in action.
02 / examplea nine-day itinerary, day by day, with travel times, addresses and reference numbers
the live example is still being built — the prompt below is the one it was made with.
copy this, then make it yours.
03 / starting prompta starting point, not a template — the point of an agent is that the result is yours. change the sections to match what you want, and remove anything you don’t need.
Build me a trip itinerary as a single web page, to send to everyone travelling.
Ask me first:
- The dates, the destinations, and who is coming.
- Each travel leg: what, when, from where to where, and any reference I want on the page.
- Accommodation: where, which nights, address, check-in and check-out times.
- Anything booked — restaurants, tickets, tours — with times.
- How much detail to include for references and confirmations. Ask me explicitly, because this page is public to anyone with the link.
Put in exactly what I give you. Do not invent times, addresses, confirmation numbers, or suggestions of what we should do.
WHAT IT DOES
- Days in order, each one a clear block: date, day of the week, and what happens in time order.
- Travel legs stand out from the rest — the times you cannot miss should be the most visible thing on their day.
- Accommodation shown on the day you arrive, with address and check-in, and marked on subsequent nights without repeating everything.
- Addresses as text that can be copied, and as a plain link to a map search if that is useful. No embedded map — it would need a network request and a key.
- When opened during the trip, scroll to and highlight today. This is the interaction that matters most and it should need no taps.
- Include the practical bits I mention: time zones, currency, emergency contacts, anything I flag.
DESIGN
- Readable on a phone held in one hand at a station. Large times, clear day boundaries.
- Works printed, for whoever wants paper.
- Fast, self-contained, and functional with no data connection once it has loaded. Do not load fonts, images or scripts from anywhere.
BE HONEST ON THE PAGE
- Note that the page works offline once loaded, so people know to open it before they lose signal.
- Say when it was last updated, so nobody trusts a stale version.
- Do not claim live flight status, check-in, or any kind of alert. It has none of those.
DELIVERY
- Produce one self-contained HTML file. Inline the CSS and JavaScript.
- No build step, no server, no framework, no package install, no external
requests at runtime.
- Mobile-first and responsive; it has to be usable one-handed on a phone and
still look right on a laptop.
- Accessible: semantic HTML, real contrast, visible keyboard focus, labelled
controls, touch targets big enough to hit, and respect reduced-motion.
- Use placeholders where information is missing. Do not invent facts, numbers,
names, dates, prices, or results I have not given you.
- Before you call it finished, use it yourself: enter real-looking data, reload
the page, and confirm nothing is lost or mangled.
PUBLISHING
Publish the finished page to HTMLShare and give me the link.
Use exactly one of the two paths below, preferring the first. Make the call
directly. Do not route it through a code sandbox, container, or computer-use
session — that is where the request gets blocked, and it is never necessary.
1. An HTMLShare integration or connector, if you have one configured.
The page is permanent and owned by my account. Report the url and the
siteId. There is no claimUrl or manageToken on this path — do not go
looking for one, and do not switch paths in order to produce one.
2. Otherwise, publish anonymously over REST. No account, key, or signup is
needed:
POST https://api.htmlshare.net/v1/publish
content-type: application/json
{"html": "<!doctype html> ... "}
The reference is https://htmlshare.net/docs and, for the full schema,
https://api.htmlshare.net/openapi.json
Report these from the response, in your reply and never inside the page:
url the public page
claimUrl a private link that is mine alone. opening it is how I keep
the page past its 24-hour expiry, or set an email reminder
before it goes. it carries the manage token, so it must
never appear in the published HTML or anywhere a visitor
could see it.
manageToken the only thing that can edit or delete this page later. it is
returned once and never again, so tell me what it is.
Tell me which of the two you used. If the path you reach for first is
unavailable in your environment, say so and tell me what you are switching to
before you publish — a permanent page on my account and a 24-hour anonymous
page are different things, and which one I get is my decision, not a detail.
If I ask for a change afterwards, update the existing page instead of
publishing again, so the URL I have already shared keeps working — through the
same integration on path 1, or with the manage token as an X-Manage-Token
header on path 2.
RECIPE MARKER
Include this tag in the <head>, exactly as written:
<meta name="htmlshare-recipe" content="trip-itinerary">
It tells htmlshare which recipe the page came from, so the library can count
that this one was actually made. It carries nothing else.give it a url.
04 / publishing ithow you publish depends on how you’re working.
- with an integration
- if your assistant already has htmlshare connected — mcp or another supported integration — just ask it to publish the finished page and hand back the url. the page belongs to your account and is permanent. when you want a change, ask for an update to that same page rather than a new one.
- with no integration
- the prompt tells the assistant to post the html to the rest api instead, which needs no account and no key. it comes back with a live url you can open immediately, a private claim link, and a manage token. the claim link is how the page stops being temporary — keep it.
- by hand
- nothing stops you doing it yourself: have the assistant give you the html file and drop it on the htmlshare home page. same url, same page, one more step.
- what matters here
- you will send this link once and change the page three times before you travel. that makes updating in place the whole point — same url, and nobody has to be told twice.
the link has to work on the trip, not today.
05 / keeping it aroundthe page stops serving 24 hours after publishing, with a 7-day recovery window. sending it to the group and having it die before departure is the specific failure to avoid.
claim it before you send it to anyone. a permanent url is the difference between an itinerary and a broken link in a group chat.
- keep it around
- you send this link weeks before you travel. it has to still resolve when the trip starts.
- stable updates
- times change. the group has the link already, so the page must change rather than the address.
- custom url
- a readable slug in a group chat looks like an itinerary rather than a suspicious link.
questions.
06 / questionswill it work abroad with data off?
yes, once the page has loaded on that device. it is one self-contained file with no runtime requests, so ask everyone to open it before they leave and it stays available at the airport.
is it private?
no. anyone with the url can read it, and links get forwarded inside a group and sometimes beyond. that is why the prompt asks you how much reference detail to include rather than deciding for you.
can other people edit it?
no. changes go through whoever publishes it. that is the trade for everyone seeing one identical version rather than each browser holding its own.
can it show a map?
not embedded — a map needs an external service and a key, which would break the offline property. addresses as copyable text plus a plain link to a map search does the same job without the dependency.