the game you made up, playable.
most groups have a game. it came from somewhere, the rules have drifted, and playing it requires someone to remember the cards or make up prompts on the spot.
the version on an app store is not your version, and it wants five pounds and an account.
describing your rules to an agent and getting a page back takes a message. it can be passed around a room, it needs nothing installed, and the rules are finally written down.
one device, passed around.
01 / what it isthe honest design constraint is that there is no shared state, so this is a game for one screen in a room rather than for everyone on their own phone. that turns out to suit most party games, which were passing something around anyway.
the sleeper benefit is the rules being written down. half the arguments in a made-up game are about what the rule actually is, and a page that states it settles that permanently.
- your rules, written on the page
- the prompts or cards, all of them yours
- a pass-the-phone flow that works in a room
- scoring, if your game has any
- prompts that do not repeat until the pack is done
- a reset for the next game
- where the game lives
- in the page — rules, prompts and all
- what it stores
- the round in progress, on the device playing
- players
- one device passed around. not several phones in sync
- the prompts
- yours. nothing generated, nothing borrowed from elsewhere
see one in action.
02 / examplea prompt-and-pass game for six players, with the rules on the first screen and a round counter
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 party game as a single web page, from rules I will describe.
Ask me first:
- How the game works, in my own words. Ask follow-up questions until you can explain it back to me correctly.
- How many people play, and whether there are teams.
- Whether it needs prompts, cards or questions, and whether I am supplying them or we make them up as we go.
- Whether there is scoring, and how it works.
- How a round ends and how the game ends.
Play it back to me before building. Do not invent rules to fill a gap, do not substitute a standard game you think this resembles, and do not write prompts of your own unless I ask you to.
WHAT IT DOES
- The rules are on the page, stated plainly, reachable at any time without losing the current game. This solves the argument that this game actually has.
- Designed for one device passed around a room: whoever holds it can see what they need and nothing they should not.
- If there are prompts or cards: work through them without repeating until the pack is exhausted, and let me add more in the page.
- If there is scoring: keep it, show the standings, and let me correct a mistake.
- A clear round structure — whose turn, what round, what happens next.
- Reset for a new game without losing anything I added.
DESIGN
- Large text, readable by someone holding the phone out for others to see.
- Very large tap targets; this is played by people who are not concentrating.
- No small print, no menus, nothing that needs a second look.
BE HONEST ON THE PAGE
- Say the game state is on this device, so it should be passed around rather than opened separately by everyone.
- Do not claim multiplayer across phones, lobbies, or anything that needs a server.
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="party-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
- this link gets sent to a group chat and re-found at the next gathering. claim it, because the second time it comes out is the point at which it has become your group’s game.
the second time is the real test.
05 / keeping it aroundfine for tonight. the page stops serving 24 hours later, with a 7-day recovery window — which means the next gathering starts from nothing.
claim it and the game exists. that is the difference between a thing you did once and a thing your group plays.
- keep it around
- the point is playing it again. an anonymous page does not survive to the next gathering.
- custom url
- findable by whoever remembers it exists, which will not be you.
- stable updates
- the rules will drift again. update the page and the link in the group chat keeps working.
questions.
06 / questionscan everyone play on their own phone?
no. there is no shared state between browsers, so this is one device passed around a room. most party games were that anyway, and designing for it produces a better page than pretending otherwise.
will it write the prompts for me?
only if you ask, and it is usually worse. the prompts that make a group’s game work are about that group, which is the one thing an assistant cannot supply.
what if we change the rules?
describe the change and republish to the same url. the rules being written down at a fixed address is arguably the most useful thing this page does.
does it work without signal?
yes, once loaded. open it before everyone arrives somewhere with bad wifi.