htmlsharechecking
/ uses · fitness · a log that knows your program

your lifts, your numbers, one page.

the log you want at the gym is boring and specific: the exercise, the weight, the reps, and what you did last time so you know whether to add anything. everything else on the screen is in the way.

lifting apps give you the rest anyway — an account, a social feed, a subscription prompt between sets, and a program someone else designed. the part you needed is four columns.

so ask for the four columns. you describe your program and how you like to record it, an agent writes one page that does exactly that, and htmlshare gives it a url you can open with one thumb between sets.

what you make
a lifting log shaped like your own program
where the data lives
your browser, on the device you log from
what it costs
one message, then a url

a log, not a program.

01 / what it is

this page records what you lifted. it does not design your training, does not tell you to add 2.5kg, and does not have an opinion about your split — you already have a program, or a coach, or a spreadsheet you inherited from a friend. what you are missing is somewhere to write the numbers down that is faster than a notes app and quieter than an app store app.

because an agent writes it from your description, the page matches the way you train rather than the way a product manager assumed you train. amrap sets, rpe, tempo, drop sets, kilos, pounds, a warmup you never want to record — all of that is a sentence in the prompt rather than a feature request nobody will ever build.

  • your exercises, grouped into the sessions you actually train
  • weight × reps entry that takes two taps, not a form
  • last session’s numbers beside today’s, per exercise
  • a running best for each lift, and the date you hit it
  • plate maths, if you want it, so you stop doing arithmetic at the rack
  • export and import as json, because a browser is not a backup
what it records
exercise, weight, reps, and whatever else you asked for — sets, rpe, notes
where that goes
localStorage in the browser you use. not synced, not uploaded, not visible to us
moving it
the export button writes json you can import into the same page on another device
changing it
describe the change and republish over the same url — your home screen icon keeps working

see one in action.

02 / example
htmlshare.net/p/…
screen capture · silent loop
video coming soon

a log for a four-day upper/lower split, three weeks of sets already in it

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 prompt

a 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.

starting prompt · paste into your ai
Build me a weightlifting log as a single web page I can use at the gym on my phone.

Ask me first, briefly:
- What program I run and what the sessions are called (for example: "upper/lower, four days" or "push/pull/legs").
- The exercises in each session, in the order I do them.
- Whether I log in kilograms or pounds.
- Whether I want to record RPE, tempo, or notes, or just weight and reps.
- Whether I want plate maths for a barbell, and what plates I have.

Do not build until you have those answers. Do not invent exercises, weights, or a program I did not describe.

WHAT IT DOES

- Opens on the session I am most likely doing next, with every other session one tap away.
- For each exercise, shows my last session's numbers for that exercise directly beside today's inputs. This is the single most important thing on the page — I decide what to lift today by looking at what I lifted last time.
- Entering a set is two taps and a number. Weight and reps, big touch targets, a numeric keypad on mobile, and a button to repeat the previous set unchanged because that is what most sets are.
- Tracks a personal best per exercise — the heaviest set, the date, and the reps it was for — and says when today's entry beats it.
- Lets me add an exercise that is not in my program without editing anything.
- Shows a simple history per exercise: date, the working sets, nothing else.
- If I asked for plate maths: given a target weight and my bar, show the plates per side.

DESIGN

- Gym conditions: one hand, bad light, sweaty screen. Large type, large targets, high contrast, no hover-dependent controls.
- The current session should be readable at arm's length on a phone propped against a water bottle.
- Fast and plain. No animation between sets, nothing that reflows while I am typing.
- Dark by default is fine if it suits the design; respect the system preference either way.

BE HONEST ON THE PAGE

- Say, in small print somewhere visible, that data is stored in this browser only.
- Do not describe anything as synced, backed up, or cloud.
- Do not give training advice, recommend weights, or auto-progress my numbers. Record what I did.

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="weightlifting-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.
works as-is inclaudechatgptcodexcursorgrok
adapting it
give it your real program.the difference between this and a generic log is the exercise list. paste your actual sessions in — including the accessory work you always skip — and the page opens on the right screen instead of asking you to build it.
ask for the previous-session column first.if the agent gets creative and buries last week behind a history tab, say so immediately. everything else on the page is optional; that column is the reason to open it.
export before you change anything big.a rewrite republished over the same url is a new page with new storage keys. take the json export first, then import it into the new version.

give it a url.

04 / publishing it

how 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
a lifting log is opened two or three times a session, forever. that makes it the wrong page to leave anonymous: claim it, give it a slug you can type, and add it to your phone home screen once.

a training log has to outlive the week.

05 / keeping it around
anonymous
24h

fine for checking the page does what you wanted. it stops serving 24 hours after you publish it, with a 7-day recovery window behind that — and anything you logged into it was in your browser, not on the page, so a replacement page starts empty.

keep it around
an anonymous page is gone in 24 hours. a training log you have to rebuild every day is not a training log.
custom url
a url you can type from memory is the difference between opening the log at the gym and not bothering.
stable updates
programs change. you want the page to change at the same address, so the icon on your home screen still points at it.

questions.

06 / questions
will my numbers still be there tomorrow?

yes — same browser, same device, as long as you do not clear site data. the page saves as you enter. what it will not do is appear on your laptop or a second phone: each browser has its own copy, which is why the prompt asks for an export button.

can i use it without signal in the gym basement?

once the page has loaded, yes. it is one html file with nothing to fetch at runtime, so logging works offline. adding it to your home screen makes that first load one tap instead of a search.

does it tell me what to lift?

no, and the prompt specifically tells it not to. it shows you what you lifted last time and records what you lift today. progression is your program’s job or your coach’s, not a web page’s.

what if i want to change the exercises later?

say what changed and republish to the same url. export your history first if the change is big — a rewritten page may not read the old storage, and the export is the only thing that carries your numbers across.