the list, in aisle order.
a shopping list on paper is fine. a shopping list in a notes app is fine. the thing neither does is put the items in the order you will walk past them.
that sounds trivial until you have doubled back for the milk. a list sorted by aisle is measurably faster and nobody sells you one, because it would have to know your specific shop.
you know your specific shop. tell an agent the sections in order, and the list sorts itself for the rest of your life.
sorted for one particular shop.
01 / what it isgeneral shopping lists sort alphabetically or not at all, because a generic app cannot know that in your supermarket the bread is at the far end past the tills. yours can, because you are going to tell it once.
the second thing it knows is what you buy. after a couple of shops the regulars list covers most of a trip, and adding an item is tapping a name rather than typing it with one thumb while holding a basket.
- sections in the order you walk them
- your regular items, one tap to add
- new items sorted into the right section automatically where possible
- ticking that keeps items visible rather than hiding them
- a clear-the-list that keeps the regulars and the layout
- export and import as json
- what it holds
- your section order, your regular items, and the current list
- where that goes
- localStorage in one browser — a second shopper sees their own copy
- after the shop
- clear the list; the layout and the regulars survive
- offline
- works once loaded, which matters in a shop with no signal
see one in action.
02 / examplea list of twenty-eight items grouped into the nine sections of one particular shop, in walking order
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 grocery list as a single web page, sorted for my supermarket.
Ask me first:
- The sections of my usual shop, in the order I walk past them. This is the important one — take my answer literally, including any odd order.
- The things I buy most weeks, so they can be one-tap regulars.
- Whether more than one person adds to the list.
- Whether I want quantities, or just item names.
Build from my answers. Do not reorder my sections into a layout you think is more logical, and do not invent items.
WHAT IT DOES
- The list is grouped by my sections, in my order, always. Items appear under the section they belong to.
- Adding an item: type it, and it goes into the right section automatically if it matches something known, or asks me which section once and remembers thereafter.
- My regulars are one-tap buttons, sorted by how often I use them.
- Ticking an item keeps it visible but clearly done — I want to see what is in the trolley, not have it vanish.
- Show how many items remain in each section, so I know whether to double back before I leave it.
- Clear the list after shopping. This must keep the sections and the regulars; only the current list goes.
- If I asked for quantities, keep them optional and inline — never a separate field I have to tab to.
DESIGN
- One-handed, in a shop, while pushing a trolley. Large targets, thumb-reachable controls, no precision taps.
- High contrast; supermarket lighting and a bright phone are a bad combination.
- No search-as-you-shop UI that requires a keyboard for regular items.
BE HONEST ON THE PAGE
- Say the list is stored in this browser only, so if someone else opens the url at home they are not looking at the same list.
- Do not claim prices, stock, offers, or anything about the actual shop. The page knows the layout because I typed it, and nothing else.
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="grocery-list">
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 only pays off from the second shop onwards, once it knows your regulars. claim the page so there is a second shop.
the layout and the regulars are what you are keeping.
05 / keeping it aroundone shop’s worth. the page stops serving 24 hours after you publish, with a 7-day recovery window — and your section order goes with it.
claim it and the shop layout you spent five minutes describing is there every week. that is the whole return on this recipe.
- keep it around
- the section order and the regulars are the value, and both die with an expired page.
- custom url
- you will open this in a car park, in a hurry, without wanting to search for it.
- stable updates
- shops rearrange. update the section order at the same address instead of rebuilding.
questions.
06 / questionscan two of us add to the same list?
no — each browser has its own copy, so items added on one phone do not appear on the other. one phone has to own the list. that is a real limitation and it is better known before you are in different aisles.
does it work without signal in the shop?
yes, once the page has loaded. it is a single file with nothing to fetch, so ticking and adding work in the basement of any supermarket. open it before you go in, or add it to your home screen.
does it know prices?
no. there is no connection to any shop, no offers, no stock levels. it knows the layout you described and the items you typed, which is all it claims.
what happens after i shop?
you clear the list, and the sections and regulars stay. the prompt separates those explicitly, because a clear button that wipes your shop layout is the fastest way to abandon this page.