only the units you use.
generic converters have every unit ever defined, which means using one is mostly navigating a menu to find the two you wanted.
in practice everybody has three or four conversions they do repeatedly — a recipe in cups, a bolt in fractional inches, a temperature, a currency at a rate they have decided on.
a page with exactly those on one screen, no dropdowns, is faster than any converter online and takes a message to make.
the two units, already on screen.
01 / what it isthe speed advantage here is entirely about not navigating. a converter with four rows visible is faster than one with a search box, because the interaction is typing a number rather than finding the right pair first.
it also lets you do the conversions generic tools refuse to: grams to cups depends on what you are measuring, and a converter that knows your six baking ingredients is genuinely more useful than one that knows every unit in the si system.
- your conversions, each in its own row, all on screen
- both directions at once — type either side
- the precision that suits each one
- awkward units done properly, like fractional inches
- ingredient-specific volume conversions, if you cook
- what it converts
- the pairs you named, and nothing else
- what it stores
- nothing
- precision
- set per conversion, since a temperature and a machining dimension want different answers
- rates
- any currency rate is one you typed. nothing is fetched or live
see one in action.
02 / examplefour conversions on one screen — grams to cups for three ingredients, celsius to fahrenheit, mm to fractional inches
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 unit converter as a single web page, with only the conversions I actually use.
Ask me first:
- Which conversions I want. Push me for specifics — not "weight" but "grams to ounces".
- Whether any of them are ingredient-specific, such as grams to cups for particular baking ingredients.
- What precision each one needs, and whether any should show fractions rather than decimals.
- Whether any involve a rate I set myself, such as a currency.
Only include the conversions I name. Do not add a general unit picker and do not include categories I did not ask for.
WHAT IT DOES
- Each conversion is its own row, all visible at once. No dropdowns, no category selection, no search.
- Each row converts in both directions: typing in either field updates the other.
- Precision per conversion, as I specified. A temperature to one decimal and a machining dimension to three are different requirements.
- Where I asked for fractions — fractional inches, for example — show the nearest useful fraction as well as the decimal.
- Ingredient-specific volume conversions use the density for that specific ingredient, and label which ingredient each row is for.
- If a conversion uses a rate I set, put the rate on screen as an editable field with the date I set it, so it is never mistaken for a live figure.
DESIGN
- One screen, no scrolling if the number of conversions allows.
- Large numeric inputs with a numeric keypad on mobile.
- Monospace for numbers so they do not jump around as they update.
BE HONEST ON THE PAGE
- Say that any currency or custom rate is one I entered and is not live.
- Where a conversion is approximate — cups of flour, most obviously — say so rather than implying three decimal places of accuracy.
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="unit-converter">
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 competes with typing the conversion into a search engine, so it only wins if it is one tap away. claim it and put it on your home screen or it will not get used.
it has to be faster than searching.
05 / keeping it aroundfine to check the conversions came out right. it stops serving after 24 hours, with a 7-day recovery window.
claimed and on your home screen, it beats searching. that is the only bar this page has to clear.
- custom url
- this has to be reachable faster than a search box or there is no point to it.
- keep it around
- a tool that expires nightly loses to the search box immediately.
- stable updates
- add a fifth conversion later without moving the icon on your phone.
questions.
06 / questionswhy not use a search engine?
for one conversion, do. this wins when you do the same four repeatedly, when they are on screen together, or when they are ones a generic tool gets wrong — like volume conversions that depend on the ingredient.
can it convert currency?
only at a rate you type in, shown on screen with the date you set it. the page makes no network requests, so a live rate is impossible and pretending otherwise would be the worst thing it could do.
are cup conversions accurate?
they are approximate by nature — a cup of flour varies with how it was packed. the prompt asks the page to say so rather than implying precision it cannot have.
does it work offline?
yes, once loaded. nothing is fetched at runtime, which is also why the rates cannot be live.