days until, for everyone invited.
a countdown for an event is not really about the number. it is a link people open that happens to answer where, when and what to bring while they are there.
which is why a bare countdown site is less useful than it looks — it counts, and then everyone messages you anyway.
a page you build has the number at the top and the details underneath, previews properly when pasted into a chat, and can be corrected when something changes.
the number, and the answers.
01 / what it isthe countdown gets people to open it; the details are why it is worth sending. address, start time, what to bring, where to park, what the dress code is — the six questions that otherwise arrive individually over three weeks.
nothing is stored and nothing is fetched, so it works for everyone identically and keeps working offline once loaded. when something changes you republish and the link everyone has shows the new version.
- the countdown, large, from the visitor’s own clock
- the details people keep asking for, underneath
- a link preview that looks right in a group chat
- a sensible state once the date passes
- a page that works on every phone with nothing installed
- a design that suits the occasion
- what is on it
- the date, the countdown, and the practical details you chose
- what it stores
- nothing per visitor
- sharing
- public to anyone with the url, with og tags so it previews in chat
- changing it
- republish to the same address; everyone sees the update
see one in action.
02 / examplea countdown to one evening, with the address, timings and what to bring underneath
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 countdown page for an event as a single web page, to send to everyone coming.
Ask me first:
- The event, the date and the start time.
- Where it is, and any practical details people will ask about — parking, what to bring, dress code, what time to actually arrive.
- Whether the countdown should use each visitor's local time or a fixed time zone.
- What the page should say once the event has started, and afterwards.
- The tone and any colours or imagery.
Put in only what I give you. Do not invent an address, a schedule, or details about the event.
WHAT IT DOES
- The countdown is the top of the page and the largest thing on it. Days, and hours and minutes when it gets close.
- Underneath, the practical details as short labelled lines — the things people would otherwise message me about.
- Address as copyable text and a plain link to a map search. No embedded map.
- Handle the event starting and finishing gracefully: a sensible message rather than a negative number.
- Open Graph and Twitter tags with a title, description and image, so the link previews properly when pasted into a group chat. This is how most people will see it first.
DESIGN
- Built for a phone in a message thread. That is where it will be opened.
- Design it around the occasion rather than using a generic countdown look.
- Readable, with the details scannable in a few seconds.
BE HONEST ON THE PAGE
- Do not claim reminders, rsvp collection or notifications — the page cannot send or receive anything.
- If there is nowhere for people to reply, say how they should instead.
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="event-countdown">
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
- this link goes into a group chat and stays there for weeks. claim the page, pick a slug that reads like an invitation, and make sure the og tags are right before you send it.
you are counting down more than one day.
05 / keeping it aroundonly works if the event is tomorrow. the page stops serving 24 hours after publishing, with a 7-day recovery window.
claim it before you send the link. a countdown that expires before the thing it counts to is a uniquely embarrassing failure.
- keep it around
- the link is sent weeks ahead. it has to work on the day.
- stable updates
- start times move. change the page, not the link forty people already have.
- custom url
- a readable slug looks like an invitation rather than something to be suspicious of.
questions.
06 / questionscan people rsvp on it?
no. there is nowhere for a submission to go — no form handler, no database. say on the page how to reply instead, which is usually just answering the message you sent it in.
what does it look like when i paste the link?
whatever your og tags say, which is why the prompt asks for them. test it by sending it to yourself first.
is it private?
no — anyone with the url can read it, including the address. for anything where that matters, leave the precise location off and send it separately.
what happens after the event?
whatever you specified. a message, a thank-you, or a photo. the prompt asks for it because an unattended countdown showing a negative number is the standard way these pages age badly.