a quiz about the people in the room.
general knowledge quizzes are a solved problem and mostly not very interesting. the quiz people actually enjoy is the one about them — the office, the family, the group chat, the ten years of shared history.
nobody sells that, obviously, and building it used to mean a powerpoint.
now it is a page: you supply the questions and answers, an agent makes it playable, and everyone opens the same link.
the questions are yours; the page just runs them.
01 / what it iswriting the questions is the work and it is the part you cannot outsource — a quiz about your group is only funny because you know the group. what an agent does is turn a list into something playable, in the time it would take to format a slide.
the important structural choice is two views: one for the host with the answers on it, one for everyone else without. that mirrors how a quiz in a room actually works and it is the thing a generic quiz tool does not give you.
- your questions, in rounds if you want them
- a host view with the answers, and a play view without
- a reveal the host controls
- self-marking for people playing alone
- a page you can send to the whole group
- a design that suits the occasion
- where the questions live
- in the published page, readable by anyone with the url
- what it stores
- each player’s own answers, in their own browser
- scoring
- per device. there is no shared leaderboard — the host tallies
- the host view
- a separate view with the answers, controlled by the person running it
see one in action.
02 / examplea thirty-question quiz in four rounds, written for one specific group, with a host view and a play view
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 trivia quiz as a single web page. The questions are mine.
Ask me first:
- For the questions and answers. I will paste them; they may be scrappy.
- Whether there are rounds, and what they are called.
- Whether people play on their own phones, or one screen with a host reading out.
- How answers work: multiple choice, typed, or said out loud and self-marked.
- The occasion and the tone, so the design suits it.
Use my questions exactly as written unless I ask you to tidy them. Do not add questions of your own, do not correct my answers against your own knowledge, and do not replace an in-joke with something more general — if an answer looks wrong to you, ask me rather than changing it.
WHAT IT DOES
- A play view: one question at a time, rounds clearly marked, with the answer hidden until it should not be.
- A host view, on a separate screen or behind a control: the same questions with the answers, and control over when the play view reveals. Make it obvious which view someone is in, so nobody hosts by accident.
- If people play individually: they answer, mark themselves at the reveal, and see their own running score.
- Round scores and a total, per device.
- A way to restart for the next group.
DESIGN
- Readable from across a room if it is being projected, and on a phone if it is not.
- Design for the occasion I described rather than a generic quiz-show look.
- Keep any animation short. Momentum matters in a room.
BE HONEST ON THE PAGE
- Say that scores are per device, so the host is the one who tallies. Nobody should be waiting for a leaderboard that cannot exist.
- The questions and answers are in the page, so anyone with the url can read the answers if they look. Say so — it is a party, not an exam, but people should know.
STORING THE DATA
- Save everything to localStorage in the browser, automatically, as I go. No
accounts, no login, no server call.
- On the page, say plainly that data lives in this browser only and does not
sync to other devices. Do not bury it.
- Give me an "export" button that copies or downloads everything as JSON, and an
"import" that reads the same JSON back. That is the only way my data can move
between devices, so it is not optional.
- Never lose what I have already entered. If the stored data is from an older
version of the page, read what you can rather than throwing it away.
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="trivia-game">
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 to a group an hour before the quiz and change a question twice before then. claim it, republish over the same url, and nobody has to be sent a second link.
one evening, or the annual one.
05 / keeping it aroundhonestly fine for tonight — publish in the afternoon, play in the evening, and it stops serving 24 hours later with a 7-day recovery window.
claim it if the quiz is an institution, or if you want to add rounds to it next year rather than starting again.
- stable updates
- you will change three questions after you send the link. same url, no second link.
- keep it around
- if the quiz is annual, next year is an edit rather than a rebuild.
- custom url
- a slug that reads like the occasion, in a group chat.
questions.
06 / questionscan everyone’s scores go on one leaderboard?
no. each phone keeps its own score and there is no shared state, so the host adds up at the end. that is how most quizzes in a room work anyway, but it is worth knowing before you promise a live leaderboard.
can people see the answers?
if they look in the page, yes — the answers are in the file. fine for a party; if there is a prize, keep the answers off the page and read them out yourself.
who writes the questions?
you. an agent cannot know that your colleague once reversed into a bollard, and the prompt tells it not to invent questions or quietly generalise your in-jokes.
does it work with no signal?
yes, once everyone has loaded it — send the link before people arrive at a venue with bad wifi.