watch the trend, not the day.
daily weight is noisy and the noise is the problem. one number is meaningless, a week of numbers is a trend, and almost every app shows you the first while implying it is the second.
it is also data most people would rather not hand to a company, attached to an email address, forever.
so make the small version: a number a day, a trend line, no advice, nothing leaving your browser. an agent writes it in one message.
an average, mostly.
01 / what it isbody weight moves two or three pounds a day on water alone, which is why a single reading tells you nothing and a rolling average tells you almost everything. this page exists to show the second one clearly and the first one honestly.
it says nothing about what the number means. no bmi verdict, no calorie suggestion, no encouraging message when the line goes the way something assumed you wanted. you get the arithmetic and the chart; the interpretation is yours or your doctor’s.
- one number a day, entered in two taps
- a seven-day rolling average plotted over the raw readings
- change over the last week, month and quarter, stated as numbers
- your own goal, if you want one, and nothing if you do not
- a chart that is labelled and readable rather than decorative
- export and import as json
- what it records
- a date and a weight, in your units, once a day
- what it computes
- a rolling average and change over fixed windows. that is all
- where that goes
- localStorage in one browser. never uploaded, never visible to us
- what it is not
- medical software, and it says so on the page
see one in action.
02 / examplethree months of daily weigh-ins with a seven-day average over the top
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 body weight tracker as a single web page.
Ask me first:
- Whether I use kilograms, pounds, or stones and pounds.
- Whether I weigh daily or less often.
- Whether I want a goal weight shown, or would rather not have one on the page.
- How many days the rolling average should cover, if I have a preference. Default to seven.
Do not invent a goal, a target date, or a rate of change. Do not assume which direction I want the number to go.
WHAT IT DOES
- Entering today's weight is the first thing on the page and takes two taps and a number, with a numeric keypad on mobile.
- Plot every reading as points, with the rolling average as a line over the top. The line is the emphasised element; the points are lighter.
- The chart must be labelled: axis values, units, and dates. No unlabelled sparkline.
- Below the chart, state the change over the last 7, 30 and 90 days as plain numbers with their direction.
- Let me correct or delete a reading. I will mistype at some point.
- Missing days are missing, not zero. Never plot a gap as a drop.
- If I asked for a goal, show it as a line on the chart and as a difference in numbers. Do not project a date I will reach it.
DESIGN
- Quiet. This page should look like a measuring instrument, not a coach.
- One chart, readable on a phone, with the numbers repeated as text underneath for anyone who cannot read the chart.
- Neutral colours. Do not colour the trend green or red — the direction I want is not yours to assume.
BE HONEST ON THE PAGE
- State that data is stored in this browser only and is not sent anywhere.
- Include a short line saying this is not medical advice and the page only does arithmetic on what I enter.
- No BMI verdicts, no calorie recommendations, no motivational messages, no streaks.
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="weight-tracker">
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 is the page in the library people are most careful about, and rightly. what you type stays in your browser either way — but claim the page so it is at an address only you are likely to type, and keep anything identifying out of the html itself.
a trend needs weeks, and a page that expires does not have them.
05 / keeping it aroundfine for a first look. the page stops serving 24 hours after publishing, with a 7-day recovery window — and a trend line needs a month before it says anything at all.
claimed, the page is permanent and the url is yours. the numbers still live in your browser rather than on our servers; what an account buys you is that the page is still there to open.
- keep it around
- a rolling average needs weeks of data. an anonymous page does not last one.
- custom url
- a private-feeling address you chose, rather than a random id you would have to keep somewhere.
- stable updates
- change the chart, the window, the units — same url, and the readings in your browser are untouched.
questions.
06 / questionscan anyone with the link see my weight?
no. your readings are in your browser’s storage, not in the published file — someone opening the url gets an empty tracker. the only thing they see is whatever was baked into the html when it was built, so keep your name and details out of it.
does it calculate bmi or tell me what to do?
no, and the prompt tells it not to. it does arithmetic on the numbers you type and draws them. anything resembling a verdict belongs with someone who knows your situation.
what if i miss a few days?
the chart shows a gap, which is correct — a missed weigh-in is not a weight of zero and should not drag the average. the prompt makes that explicit because it is the most common way a hand-built chart goes wrong.
can i move my history to a new phone?
yes, through the export and import buttons. copy the json out on the old device and paste it in on the new one. there is no automatic sync, and there is not going to be.