every run in one place.
running is already tracked by the watch. what the watch does badly is the part you actually reread: the week, the month, the same loop run twelve times and whether it is getting faster.
and the platform that holds it wants a feed, a subscription, and your run history as its own asset.
a log page is the small version. you type four things after a run, the page adds up the week, and nobody sees it. it lives at a url you chose and it will still open in five years.
the numbers, without the platform.
01 / what it isyour watch records the run. this records the training: what you did this week, how the same route is trending, and whether the easy runs are actually easy. it is the page you open on a sunday evening, not during the run.
it does not connect to anything. there is no watch integration, no gpx import, no api key — you type four numbers after a run, which takes about fifteen seconds and is the entire cost of owning your own log instead of renting one.
- a run entry that takes fifteen seconds: date, distance, time, how it felt
- named routes, so the same loop is comparable week to week
- automatic pace, and weekly and monthly mileage
- a countdown to a race, if you have one in the diary
- a plain list you can actually read back, not a dashboard
- export and import as json
- what it records
- date, distance, time, route, effort, and a note if you want one
- what it computes
- pace per run, weekly and monthly totals, and per-route history
- where that goes
- localStorage in one browser. nothing is uploaded and we cannot see it
- what it does not do
- sync with a watch, import gps files, or map anything
see one in action.
02 / exampleeight weeks of running — four named routes, weekly totals, and a race in the future
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 running log as a single web page.
Ask me first:
- Whether I run in kilometres or miles.
- The routes I run regularly and roughly how long each one is, if I have them.
- Whether I want to record effort or how it felt, and on what scale.
- Whether I am training for a race, and if so what and when.
Build from my answers. Do not invent routes, distances, paces, or a training plan.
WHAT IT DOES
- Adding a run is the fastest thing on the page: date (defaulting to today), distance, time, and optionally which named route and how it felt. Nothing else is required.
- Compute pace from distance and time, and display it in the units I use. Never make me enter pace.
- Weekly totals: distance, time, number of runs, with the current week at the top and previous weeks below it.
- A monthly total as well, because that is the number people actually quote.
- Per route: every time I have run it, with pace, in date order. This is how I see whether the same loop is getting faster.
- If I gave you a race: a countdown in days, and the weekly mileage since I started.
- Editing and deleting a run has to be possible without fighting the page. I will mistype a distance.
DESIGN
- A readable list, not a dashboard. Numbers in a monospace font so columns line up.
- Mobile-first for entry; it should also be worth opening on a laptop to read back the month.
- If you include a chart, keep it to one — weekly mileage — and label the axes. No sparkline without numbers next to it.
BE HONEST ON THE PAGE
- Say the data is stored in this browser only and does not sync.
- Do not claim any watch, strava, or gps integration. There is none and there cannot be one in a static page.
- Do not prescribe training, paces, or mileage increases.
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="running-log">
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
- the value of a log compounds — a year in, it is the only place your training exists. that makes the url the important part: claim the page so the address you have been typing every sunday keeps working.
a log gets more valuable every week, which cuts both ways.
05 / keeping it aroundfine for the first run, useless for the second: the page stops serving 24 hours after you publish it, with a 7-day recovery window behind that.
claim it and the page is permanent at a url you picked. a running log is one of the clearest cases in this library where the free tier genuinely is not enough.
- keep it around
- the point of a log is the history. an anonymous page expires in 24 hours, taking the habit with it.
- custom url
- you will type this address once a week for years. make it something you can type.
- stable updates
- a new route, a new race, a different chart — the page changes and the address does not.
questions.
06 / questionscan it pull runs off my watch?
no. a self-contained page has no integration with garmin, strava, apple or anything else, and nothing here will pretend otherwise. you type four numbers, which is the trade for a log nobody else holds.
what about maps?
out of scope on purpose — a map needs an external service, a key and a network request, and this page has none of those. named routes do the job people actually wanted, which is comparing the same loop over time.
is my training visible to anyone?
the page is public to anyone with the url, but what you type into it is not on the page — it is in your browser. so someone with the link sees an empty log, not yours. do not put anything identifying into the html itself if that matters to you.
can i keep years of runs in it?
yes; browser storage is measured in megabytes and a run is a few dozen bytes. the practical limit is the page staying readable, so ask for the history to collapse by month once there is a lot of it.